PARTIAL : The module has some dependent objects to be updated.
ALL_VEHICLES : The module requires all vehicle objects to be updated.
ALL_CEMOBJECTS : The module requires all CEM objects to be updated.
ALL_OBJECTS : The module requires all other objects to be updated.
There are two types of dependent object lists, the Pre-Dependent Object List and the Post-Dependent Object List. The State Updater obtains these lists from the respective objects before the execution of the time step. When an object, say Object A, is executed, the objects in the pre-dependency list are executed BEFORE Object A while those in the post-dependency list are executed AFTER Object A. The pre-dependency and post-dependency lists are evaluated by the State Updater before the execution of the particular time step.
Computer Implementation
The RFS part of the model is implemented in C++ under the Windows NT operating system. It is implemented as a single-thread, stand-alone application, with dynamically linked libraries (DLLs) for each of the agent classes, and is flexible enough to be expanded to be used along with another compatible application. The MIDAS-FlightCrew and MIDAS-Controller agent models (using the Air-MIDAS human performance model) are implemented in LISP under the IRIX operating system. The RFS and MIDAS parts of the system “talk” and work together through the High-Level Architecture standard (HLA) Run-Time Interface (RTI), developed by the US Department of Defense (DOD).
At its update times, an HLANetworking agent developed by Georgia Tech queries all appropriate agents in the simulation for the necessary interface data, builds federates, and transmits them between MIDAS and RFS. The HLANetworking agent's behind-the-scenes operation makes it transparent to other RFS agents. It operates by calling public methods of the agents or their respective interfaces.
Since the RFSPilot class and the RFSController class are “wrappers” for their MIDAS counterparts, certain “hooks” had to be added to accommodate the HLANetworking agent. Thus, each time AircraftOnRoute updates itself, it sends to RFSPilot a package of data relevant to its position, speed, and next waypoint coordinates. These data are stored in a manner easily accessible to the HLANetworking agent, which in turn updates MIDAS-FlightCrew with that information.
When the controls are to be handed off to MIDAS-FlightCrew, the aircraft’s call sign – also stored by RFSPilot – is passed to MIDAS-FlightCrew as a flag. The decision to pass the controls is made by RFSPilot or can be made by any other agent having access to RFSPilot’s base class (BasePilotObject) and RFSPilot’s interface. In turn, the switch activating the passing of the call sign to MIDAS-FllightCrew is easily accessible to the HLANetworking agent.
The HLANetworking agent provides the linkage between the RFS simulation and the HLA RunTimeInterface, collecting data from RFSPilot, AircraftOnRoute, and RFSController and relaying commands to them. Its counterpart on the MIDAS side is a Java DataStreamEchoClient program, which resides on the same Windows machine as RFS and RTI (Figure IV-5).
The following is excerpted from the Georgia Tech documentation of the HLA networking object (Kokan, 2001):
HLA is not a piece of software; it is simply a way of thinking about how different simulations should communicate with each other through a network. HLA provides a set of ground rules for the interface between different simulations within a distributed simulation. The RTI is a piece of software that implements this interface specification.
Each instance of RFS is known as a federate. A federation is the distributed simulation comprised of these federates. The configuration of the federation is specified by the fed-file. A fed-file is a type of configuration file read by the RTI that provides the necessary federation information for the RTI to properly configure the federation to handle communications and data passing between federates.
中國航空網 www.k6050.com
航空翻譯 www.aviation.cn
本文鏈接地址：DEVELOPMENT OF FAST-TIME SIMULATION TECHNIQUES(31)
