How can contexts be built for analysing

Flight Gear Context Modeler

 

 

 

Overview

 

            There is a simple way of making flight contexts by using the Flight Gear Context Modeler. This tool is also written in Java language. It has a command line environment that is based on a command interpretor. This takes each string written by the user and analyse it. As soon as it finds out that the string matches a pattern of a known command, the certain processing steps are followed so as to complete the task. An image of the Context Modeler:

 

 

Each command has a pattern and can contain input parameter strings in the body. The user can write a whole flight context and after that the context can be saved on the disk under a certain name. At the moment of giving a command, there are done some validations especially for the accuracy of the boolean expresions so as to point to existing flight paramenters or to have a correct mathematical syntax.

 

 

The implementation of a simple interpretor

 

            The checking of input strings is done by searching the propper words in the given order. The procedure is implemented through a set of “if” Java instructions and can be easily expanded in order to accept more commands.

            At the start of the Flight Gear Context Modeler the program has in its memory the set of possible parameters that can be received in the future at the moment of analysing by the Flight Gear Client. So for the commands that involve mathematical boolean expresions the consistency of the parameters is checked. For instance, if a logical expresion is given, such as:

 

(velocities/airspeed-kt/ <=0.543 && controls/magnetos/==2)

 

the system is checking if there is any parameters with these names. By simply checking the names of the parameters at this moment it can be assumed that there will be no problems at the moment of analysing when the expresion is parsed to determine its logical value.

The interpretor accepts a set of operators so as to be able to enter complex logical expresions. There is also the possibility to use parantheses to make more exact specifications.

The implemented operators are:

 

>=

Greated than

<=

Less than

>

Greater than

<

Less than

==

Equal to

!=

Different to

&&

Logical AND

||

Logical OR

 

The only type describng the parameter values is related to double type. This means that every data value received at the moment of analyse by the Flight Gear Client is treated as a double. All kind of checking also regards this type. Because the Flight Gear Simulator program has some parameters of other kind than double, a simple trick is made.

The parameter list contains parameter of double type, boolean type and there is also one parameter of string of chars type. It is so assumed that the data related to the boolean parameters are set between two double values: 0 (for false value) and 1 (for true value) in the positive logic. For instance it can be written such a expresion:

(controls/brakes/==1)

to specify a rule for checking if the brakes are set.

 

The assumption related with the data type does not takes any problems because within the Flight Gear Client there is a module attached to the thread that receives parameter values from the Flight Gear Data Server. This module check if the received parameter value is related to a boolean parameter. If so it automatically converts the value “true” to double value 1 and “false” to double 0 value.

There is also done another validation for the right part of a simple rule by checking if the atom is related to a number representation.

 

Once an boolean expression is parsed and broken into atoms, it is automatically made the expression corresponding tree and after that the data are stored into a stack from the Polish Reversed Expression. This is the way the rule is stored in the context file.

 

It must be noticed that the Context Modeler command interface is case sensitive, so there is difference between upper and lower letters.

 

The flight context

 

The analyse of the data is focused on the contept of context. A context is so the definition of all flight situations, procedures and also for the rules that decide if a flight procedure is accomplished. For instance let’s envisage the Start Up situation. Related with this situation there are some specific flight procedures that must be accomplished by the pilot in the cockpit, such as:

-         Set ignition switch to Left

-         Set ignition switch to Right

-         Set ignition switch to Both

-         Set the mixture to 100%

-         Start the engine

-         Remove brakes

-         Start the engine

Each flight procedure has attached a logical expression that is evaluated as true when the procedure is accomplished by the pilot. So, for example it can be defined the flight procedure “Set ignition switch to Left”  that would be evaluated as true when parameter controls/magnetos/ is equal to 1.

For the flight procedure “Set the mixture to 100%”  the definition would be:

 

controls/mixture/==1

 

For the check of the start of the engine [Start the engine], it can be easily tested with an expression such as:

engines/engine/running==1

 

It can be defined an unlimited number of flight steps/procedures to accomplish.The prediction system is written so as to notify the next the most probable flight step/procedure to be the first step that is evaluated as false. Since this, having the list of steps for one flight situation the user must the logical expressions in such a way so as to provide a continuity for the system based on a logical order of steps in the hierarchy. This can be easily done by using combined constraints that check also the previous steps and gives a logical value that is combined to the current ones for the step. The Flight Gear Context Modeler can generate diagrams through its module of Diagram Builder. To activate this, the user must type “diagram” or click on the “Diagram” button. He can do this even from the the start to work on a new or already made context. The modification, addings or deletions of items in one context can be done having the Diagram module running in the same time. Once the user has done a modification, for instance has added a new situation or a new direction to an existing one, the Diagram module automatically updates the diagram to show the current context having the modifications taken into account.

For instance, using the Context Modeler to make a simple flight context that has just two situations, On the ground and On air, the following must be typed:

new situation [On_the_ground]

new situation [On_air]

add direction [On_air] when [velocities/airspeed-kt/<=50] on [On_the_ground]

add direction [On_the_ground] when [velocities/airspeed-kt/<=50] on [On_air]

                        set initial [On_the_ground]

            The context can be saved as a file on the disk by typing “save context” or clicking the “Save context” button.

            This simple flight context specify that the flight can be analysed through just two situations, the plane being on the air or on the ground. The directions indicate when the situation changes through the boolean expression specified. When the user enter the Diagram module, the following image is showed:

 

 

            If moves the mouse over the rectangle of one situation, the information for that situation is showed. Moreover, all the situations that are directions-targets for the pointed one, are coloured in red to notice that.For one situation there are also onother kind of elements, the directions. One direction define a way to change the situation. For example suppose that the pilot is in the “Start-Up” situation. He accomplish the steps defined for the situation. From here he can go ahead by starting the engine and switching to “Taxing” or he can go back to “Hold Short”. To the given context example, some steps can be added to the situations so as to give the Flight Gear Client the chance to make predictions over the flight maneuvers. Once the context has been saved on the disk, it can be further loaded from the Flight Gear program that will make analyses over the data it receives from the Flight Gear Data Server, taking into account the set of situations, steps and directions defined.

 

Each direction has so a constraint. The Flight Gear Client evaluates the expression and if the result is true it means that the situation has been changed and this is notified.   A context can have an unlimited number of situations. There must be a situation that is defined as initial. The alanyser must know so that the situation coresponds to the real situation of the flight.

 

The procedure of saving or loading context files form the disk is made possible by Java serialise mechanism. A save command determines the save of the entire memory class to disk through a special object data flow. The same with the loading process.

When the file will be loaded from the Flight Gear Client analyser, the data consisting to the memory object are loaded and the initial state for all the additional classes is rebuilt automatically.

 

The list of available commands:

 

new situation [situation name]

The command creates a new situation in the memory. The name is described by the parameter between brackets.

 

add step [step name] when [boolean expression]  on [situation name]

The command creates a new flight procedure/step for one given situation. So the step name, shuch as “Remove brakes“ is specified, the boolean expression that defines the moment of firing the rule and also the situation name is pointing to an existent situation.

 

change step [step name] when [boolean expresion]  on [situation name]

The command allow any changings in the rule body. So, for one situation, one flight procedures it can be set another boolean expression.

 

add direction [direction name] when [boolean expresion]  on [situation name]

The command creates a new flight direction for one given situation. The end situation name, shuch as “Start Up “ is specified, the boolean expression that defines the moment of changing the situation and also the situation name is pointing to an existent situation. The direction name parameter must also relate to one of the existing situations.

 

show situation [situation name]

The command displays one already defined situation.

 

show step [step name] on [situation name]

The command displays the step [step name] attached to one already defined situation.

 

show direction [direction name] on [situation name]

The command displays one already defined direction from one existing situation.

 

show all

The command displays all situations from the memory with all steps and directions.

 

clear memory

The command determines the deletion of the memory. If any situation at the moment, it is erased by the command.

 

delete all

The command determines the deletion of the memory. If any situation at the moment, it is erased by the command.

 

delete step [step name] on [situation name]

The command deletes the specified step attached to a certain situation.

 

delete direction [direction name] on [situation name]

The command deletes the specified step attached to a certain situation.

 

delete situation [situation name]

The command deletes the specified situation.

 

set initial to [situation name]

The command set the initial situation. The parameter specify simply the name of the situation.

 

save context

The command save the already made context on the disk under a given name that is defined by use of a standard “save” control.

 

load context

The command loads an already made context from the disk with a given name that is defined by use of a standard “load” control.

 

diagram

The command switches to the module of diagram generation. A new window is showed and all links between situations are displayed.

 

clear screen

The command clear the TextArea controll that is used as a command terminal for the Context Modeler.

 

exit

Exit the program of Flight Gear Simulator.

 

For each command there are some validation for the situations and steps. For instance, it cannot be saved a context until an initial situation is specified. If the situation/step/direction does not exists it is noticed with a message. The client analyser makes the checks to each step and direction for every situation as soon as new data are received from the Flight Gear Data Server. It is so determined the next probable step and the completion for each step from the current situation.

Almost every message has also a “speeched” message.

 

            Back to the index