The analyse
techniques.The Flight Gear Client.
Overview
The client program is designed to connect to the Flight Gear Data Server and to get the values for the parameters every at certain moments in time. Having these values and the coresponding list of parameters names it can load a already made context as a file on the disk. The context file loads into memory of the program all the definitions for all situations and for each situation having all steps to make and direction to follow. Every step and direction as well has a logical expression that let the analyser system to know when that step or direction was fired. If it was related to a direction, the system switches to that new situation and automatically loads the sets of steps and directions available, as have been defined by the user at the moment of context developing using the other program, Flight Gear Context Modeler.
There is a situation that is set as initial also at the moment of context developing. In this way the analyser will know that that situation is the one it must be loaded at the beginning of the analyse. As stated, every time this program gets a new package of the parameters values, the checking routine is run in order to see which boolean expression is true given the new data. If the flight situation has been changed, in addition to the loading and displaying the new situation, a speeched message is given to the computer’s speakers. This is done using the “text-to-speech” technology.
After all the checkings has been done, the analyser-predictor is looking for the first step - flight procedure that has evaluated as false. This means that that step is the most probable to be followed by the pilot for the next moment. In the previous image the most probable next flight procedure would be “Set ignition switch to Both”. The system makes a “text-to-speech” just if the previous most probable step to follow was not the same with the current one. In this way the next probable step is stated just on the first time and not every time the system gets new data till other step would be the next most probable.
Loading
an already developed fly context
The procedure is done simply by
clicking the “Load context” button. If the user tries to specify
a file that is not a context file made by the Flight Gear Context Modeler, the
system will notice that and nothing will happen.
Hidden connections
In this section it will be presented the internal non-standard protocal on which the comunication between the Flight Gear Data Server and Flight Gear Clients rely on. As already discussed, The comunication is done by initiating and using a TCP/IP stable connection. On both sides there are two kinds of data streams: income stream and outcome stream. Through whese data streams any values can pass. For a good understanding of the java comunication procedures it would be great to read some basic documentation ( www.sun.com or other sites ) In the case of ICE project the comuncation is based on packages. So every time a part, server or client require something for the other or want to provide something, it build a package and send it to the output data stream. On the other part the receiving module ( that is a Java thread ) will get the package and will know how to deal with the useful data because the same protocol is known by the both sides. A package contains two major things: a code that is in fact a byte value and the useful data. Every comunication requirement and providing has well defined code.For instance, on terms of Java language, the following are used:
static
public final byte BB_CERE=80;
static
public final byte BB_START=81;
static
public final byte BB_DATA=82;
static
public final byte BB_END=83;
static
public final byte IESIRE=90;
static
public final byte DATE=100;
static
public final byte SET_TIMER=110;
static
public final byte END_SET=111;
static
public final byte EXIT=112;
static
public final byte BAD_LINK=113;
static
public final byte INIT_P=114;
static
public final byte PARAM=115;
static
public final byte END_P=116;
At the beginning of one connection, the Client sends to the Data Server the frequency on which it wants to have the parameters values package. For it, a package with the code SET_TIMER and having the useful data containing the frequency expressed in milliseconds is send to the Data Server. The Server will get the parameter value and will set it on the thread of that client. Every connection stands for a new instance of a client java class. Such a class deals wich the comunication between the two parts. At the same time at the beginning, the Data Server sends to the client the list of the parameters it is getting from the Flight Gear Simulator. For this it sends firstly a package having the code INIT_P. When the client receives that, it’ll know to set the value for the number of parameters variable to zero. Next, the server will send for each parameter it gets from the server a package having the code PARAM and the useful information the parameter name. For each package received, the client will increase the number of parameters and complete its parameter list.When the server finished to send all the parameters, it’ll send a final package having the code END_P and no specific useful information. After this initial step the server has an instance of the java class client that has its own thread receiving data from the Flight Gear Client. In addition to this there is one more thread running that send packages of parameter value for each parameter to the Client. For each parameter the sent package contain the code DATE and the useful information the value of the parameter that has the index the index in the sending order. After it finishes to send all the list of parameters values, a package having the code END_SET and no specific useful information is sent to the Client. When the client receives this final package it’ll set the index parameter to zero to point to the correct parameter for the next time it receives the packages set. When the client exit directly or disconnect from the Flight Gear Data Server a package having the code IESIRE is sent to the server. When that, the server stop the threads of that client and remove the instance from its list of valid clients.
The blackboard
The blackboard system is implemented into the server context but as a distinct module. It consists in a main thread that get the parameters values from the Server memory and stores the values into its memory. The memory is set to be alble to store a certain number of time moments in parameter values. For example it is set to have the parameters history for ten consecutive time moments. Each time the server gets the full set of parameters values from the Flight Gear Simulator, the blackboard system makes a translation on its parameter matrix and add the new values for the parameters on the final column. When a client wants to have the history values for one parameter, it sends a package to the server, having the code BB_CERE and no specific useful information. When the server gets it, it sends back a package having the code BB_START and also no specific useful information. This is for calibration on the side of client. The client gets the package and waits for the history values list of the requested parameter. The server will now send a full row of data from the history matrix in its memory to the client, for each cell/data from the matrix a distinct package. A package has the code BB_DATA and so the parameter value for a certain time moment as a useful information. After the server has sent all the history, it sends a final package having the code BB_END. The client receives every package and use the useful information as it desire. This stage of the project imply that no histroy is used for parameters. The important thing is that the blackboard system is fully implemented.
For exemplification it was integrated a blackboard module on the Flight Gear Client to show the the blackboard system is available on the project. The user must click on the “Request” button and the client sends the request to the Flight Gear Data Server in the way it was described above.
For any question related to the implementation please send me an email.