RTI is given by some 150 communication and/or utility calls, packaged as 6 main management services: Federation Management, Object Management, Declaration Management, Ownership Management, Time Management, Data Distribution Management, and one general purpose utility service.
Our design is based on 9 CORBA interfaces, including 6 Managers, 2 Ambassadors and RTIKernel. Since each Manager is mapped to an independent CORBA object, we can easily provide minimal support for distributed management by simply placing individual managers on different hosts.
The communication between simulation objects and the RTI bus is done through the RTIambassador interface. The communication between RTI bus and the simulation objects is done by their FederateAmbassador interfaces. Simulation developer writes/extends FederateAmbassador objects and uses RTIambassador object obtained from the RTI bus.
RTIKernel object knows handles of all manager objects and it creates RTIambassador object upon the federate request. Simulation obtains the RTIambassador object from the RTIKernel and from now on all interactions with the RTI bus are handled through the RTIambassador object. RTI bus calls back (asynchronously) the FederateAmbassador object provided by the simulation and the federate receives this way the interactions/attribute updates coming from the RTI bus.
RTIKernel object is responsible for the life cycle of the Federation Execution. It creates/destroys them. RTIKernel object supports all the FederationManagement interface but except for the life cycle operations, it forwards them to the appropriate FederationExecutive object. In this point of view, RTIKernel provides the necessary factory role for the Federation Executions, therefore Naming Service capability might be good support for this object.
RTIKernel object creates a different FederationExecutive for each execution and this object keeps track of all federates that joined this Federation. For each federate, FederationExecutive defines a FederateInfo object which keeps the current time etc. information about that particular federate. Each FederateInfo object keeps its EventQueue(one for TSO and one for RO). RTI schedules an events to these queues as an answer to each request. These events are nothing but the representation of callback messages from RTI to the simulation. Whenever simulation wants to advance its time, these queues are handled and appropriate messages causes necessary callbacks on the FederateAmbassador object of simulation. FederationExecutive is also provides the other Manager objects defined for this federation execution.
Object Manager is responsible for creating and registering objects/interactions related to simulation. Federates register the simulated object instances with the Object Manager. Whenever a new registration/destroy occurs, the corresponding event is broadcast to all federates in this federation execution.
Declaration Manager is responsible for the subscribe/publish services for each object and its attributes. For each object class, a special object class record is defined which keeps track of all the instances of this class created by federates in this federation execution. This object also keeps a seperate broadcasting queue for each attribute of the target object so that each federate can selectively subscribe, publish and update suitable subsets of the object attributes.
Each attribute is currently owned by only one federate who is authorized for updating this attribute value. All such value changes are reflected via RTI in all other federates. Ownership Management offers services for transferring,maintaining and querying the attribute ownership information.
TimeManager is responsible for time services. It provides necessary time services defined in the RTI 1.3 Spec. We are currently working on implementing the Time Management service which offers support for logical time handling, and the Data Distribution Management which offers advanced publish/subscribe services via routing spaces or multi-dimensional regions in the attribute value space.
C++ RTI API Library for Unix & Windows NT Environments
Our implementation includes two base user-level distributed objects: RTI Ambassador and Federate Ambassador, built on top of a set of system-level objects such as RTI Kernel, Federation Execution or Event Queues (including both time-stamp- and receive-order models). RTI Ambassador is further decomposed into a set of management objects, maintained by the Federation Execution object, and including: Object Management, Declaration Management, Ownership Management, Time Management and Data Distribution Management. To be able to run C++ RTI demo examples, we developed a C++ library which: a) provides RTI C++ programming interface; and b) it is packaged as a CORBA C++ service and, as such, it can easily cross the language boundaries to access Java CORBA objects that comprise our Java RTI. Our C++ DMSO/CORBA glue library uses public domain OmniORB2.5 as a C++ Object Request Broker to connect RTI Kernel object running in Java based ORB. RTI Ambassador glue/proxy object forwards all method calls to its CORBA peer and Federate Ambassador, defined as another CORBA object running on the client side, forwards all received callbacks to its C++ peer.
Future Improvements
Using Common CORBA Services
For example, we intend to use the CORBA Naming Service to provide uniform mapping between the HLA object names and handles, and we plan to use CORBA Event and Notification Services to support all RTI broadcast/multicast mechanisms. This approach will assure quality of service, scalability and fault-tolerance in the RTI domain by simply inheriting and reusing these features, already present in the CORBA model.
Using XML Format for fed definition file
DIF format can be expressed with XML syntax.
Improvements in ObjectManager
Current design does not properly handle object hierarchies therefore it has to be fixed so that it can support this feature.
Improvements in FederationManager
Current design does not support restore/save messages.
Improvements in DeclarationManager
Improvements in OwnershipManager
Improvements in TimeManager
Improvements in DataDistributionManager
Current design does not calculates the intersections efficiently.
Improvements in Event Queue Management
Prepared by | : | H. Timucin Ozdemir |
Date | : | July 01, 1998 |