Data Type
Data.
In our simulation, we have two ATCChannels, one for each of the sectors. At every moment in time, a channel can only handle one message. If a new message is coming while another message is being sent, the incoming message will have to be re-sent. That is not done automatically in the ATCChannel agent; rather, the sender of the message (pilot or controller), upon receipt of the notice that the data could not be sent, is programmed to re-send the message one second later.
Figure IV-3 illustrates how RFSController handles messages. An incoming message is analyzed to see whether it is the controller’s own message; if not, it is translated. In the course of translation, it is determined whether the message’s addressee is the controller (in which case it is "correct" for the controller to pay attention to it). The outgoing message is prepared by RFSController and is sent at the end of its next time step. If the message cannot be sent, RFSController will re-send it one second later.
Figure IV-3 Message Handling by Air Traffic Controller Agents
For AircraftOnRoute, communicating messages is more complicated, as we are dealing with the aircraft and RFSPilot acting together, where the RFSPilot delegates some communication functions to its corresponding AircraftOnRoute agent. Figure IV-4 illustrates message handling within AircraftOnRoute. An incoming message is received by AircraftOnRoute, which analyzes it to determine whether it is its own message. If it is not, it is received by the BasePilotObject and then translated by RFSPilot. The reason for this is to make the system flexible enough to work with or without the intelligent pilot agent (MIDAS-FlightCrew), since with one, the translation will be easily switched over to be handled by it. This way, the BasePilotObject stores the packet.
An outgoing message is prepared by AircraftOnRoute’s AircraftMessages object based on the request from any agent that has a pointer to ACOnRouteInterface or a pointer to this AircraftOnRoute object, in our case, RFSPilot. Similarly to RFSController, if the system is presently unable to send the message, AircraftOnRoute re-sends it with a one-second delay.
Figure IV-4 Message Handling by AircraftOnRoute Agent
Resynchronization
There are three ways of running a simulation, and our RFS-based model allows any one of the three to be used.
1. Uniform time step – all objects are updated simultaneously in equally spaced, timed intervals, independently of when it is best to update them.
2. Event step – the simulation is event driven; all objects are updated simultaneously, as in the first type of simulation, but the time step is variable, based on the update time of the object that is “first in line” with an event. All objects are in a sorted list (stack) of updateable objects.
3. Asynchronous simulation with resynchronization – the following is an excerpt from the Georgia Tech documentation of asynchronous simulation with resynchronization (Lee, 2001):
This method of simulation allows all objects to be updated independently based on their own update times until resynchronization is needed. Some of these objects might require some or all of the other objects to be updated along with it. This is known as resynchronization. Therefore, asynchronous simulation with resynchronization requires all objects to have their own dependent object lists and return the pointers to the lists with the desired type of resynchronization.
Types of Resynchronization
NONE : The module doesn’t have any dependent objects to be updated.
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：DEVELOPMENT OF FAST-TIME SIMULATION TECHNIQUES(30)
