T ank-automotive & A rmaments COM mand

1. CORBA and HLA: Enabling Future Network-Centric Vehicle Systems? Robert Kling Electronic Architecture Team Email: klingr@tacom.army.mil Phone: (586) 574-5144 Fax (586) 574-5008 U.S. Army Tank-Automotive RD&E Center (TARDEC) Vetronics Technology Area (AMSTA-TR-R, Mailstop 264) Warren, MI 48397-5000 10 June 2003 UNCLASSIFIED Tank-automotive &ArmamentsCOMmand

2. Agenda • Background • High-level Architecture Overview • CORBA Overview • CORBA/HLA Relationship • Suitability of HLA in Future Ground Vehicles • Suitability of CORBA in Future Ground Vehicles • Heterogeneous HLA/CORBA-based System Example • Summary and Conclusions

3. Background Increased emphasis on simulation-based acquisition and network-centric warfare within the objective force has posed key challenges within the embedded ground vehicle community. • Difficult to rapidly transition outputs from the simulation phase of a program to the vehicle design and integration phase because of varied architectures, levels of fidelity, and design methodologies. • Dynamic nature of network-centric warfare further strains legacy architectures, as they cannot handle the new and often dynamic operational requirements. • Two technologies currently under consideration to address problems: • Common Object Request Broker Architecture (CORBA) family of services. • High-Level Architecture (HLA). Objective: Evaluate the suitability of both CORBA and HLA for use in ground combat vehicles, as both stand-alone technologies and in conjunction with one another.

4. Background • Transformation within Army catalyzed by the Convergence of 3 architectures: • Platform Architecture (vehicle computers, weapons, mobility, crew stations, electronics). • C4ISR Architecture (sensors, battlefield C2, situational awareness). • Modeling & Simulation Architecture (computer-based and embedded training, mission rehearsal, terrain registration). • Obstacles to convergence: • Architectures based on distinct domains. • Current approach: “bolt-on.” More elegant solution instead reconciles distinct middlewares.

5. High-level Architecture Overview • HLA - Component-based software architecture developed by DoD to provide low-cost, high-capability simulation architecture. • Federation of individual simulations, or “federates.” e.g. cockpit simulator, fighting force. • RTI (runtime infrastructure). • A FOM (federation object model) that facilitates data exchange between federates in federation. • Architecture specification consists of 3 components: • Ten Rules” that define relationships among federation components. • Object model template (OMT) which specifies the form in which simulation elements are described. • Interface specification that describes the way simulations interact during execution. Defines access to RTI services as an API (C++, Ada 95, and Java).

6. High-level Architecture Overview Figure: HLA Architecture

7. CORBA Overview • The Common Object Request Broker Architecture (CORBA) is an open, vendor-independent architecture and infrastructure that computer applications use to work together over networks regardless of properties beneath the applications: • computer • operating system • programming language • network that either application may be running on • OMG (object management group), produces and maintains the CORBA standard. • Related OMG standards: • data distribution service • real-time notification service • reliable ordered multicast protocol

8. CORBA Overview • CORBA applications are composed of objects. • For each object type, developers define an interface using the OMG Interface Definition Language (IDL). • The interface is the syntax part of the contract that the server object offers to the clients that invoke it. Any client that wants to invoke an operation on the object must use this IDL interface to specify the operation it wants to perform, and to marshal the arguments that it sends. • When the invocation reaches the target object, the object request broker (ORB) uses the same interface definition to unmarshal the arguments so that the object can perform the requested operation with them. • The ORB then uses the interface definition to marshal the results for their trip back, and to unmarshal them when they reach their destination. 

9. CORBA Overview Figure: CORBA Architecture

10. CORBA/HLA Relationship • Developers can use CORBA IDL to specify the interface between federates and the RTI. • OMG specified the RTI in IDL , and has standardized this interface as their Facility for Distributed Simulation Systems. • CORBA-based applications can instantiate RTI objects as CORBA objects and incorporate them into their system. • ORB is a good candidate technology for implementing an HLA RTI, and ORB-based implementations of both RTIs and federates currently exist.

11. Suitability of HLA in Future Ground Vehicles • HLA is a good candidate technology for large-scale distributed simulations. Limitations: • Not many implementations geared towards real-time operating systems, such as Wind River’s VxWorks. • HLA doesn’t specify timeliness criteria; bad for RT. • Not interoperable across languages or RTI implementations.

12. Suitability of CORBA in Future Ground Vehicles CORBA is increasingly gaining acceptance in military domains for several reasons: • Includes QoS • Predictable response times • Small footprint • Real-time performance • Emphasis on interface over implementations  well-defined architectures maintainable and supportable over the vehicle life cycle Limitations: • Only uses client/server paradigm. • OMG currently addressing this situation • Lack of suitable asynchronous notification mechanism. OMG currently addressing this situation.

13. Heterogeneous HLA/CORBA-based System Example: Background • Will present a sample system that incorporates an HLA/CORBA based architecture to cohesively integrate a disparate M&S component into a ground vehicle weapon system platform. • Below is the current system design employed with the ARMY R&D community that interfaces an embedded training capability to a ground vehicle WS. Figure: Embedded Simulation System

14. Heterogeneous HLA/CORBA-based System Example: Background Objective: Provide a robust, extensible, standards-based embedded simulation capability that minimally impacts the operational characteristics of the vehicle and is consistent with the rest of the vetronics architecture. • To meet that goal, the simulation infrastructure must: • support real-time QoS • be interoperable across languages and implementations • be available on many different platforms • be able to seamlessly share data with operational vehicle applications, in order to minimize the impact to the rest of the system • Contradicts current system design approach of integrating three distinct architectures (vetronics, C4ISR, and simulation). • Each of these usually uses different middleware products for distributed communication. • RT OE (Vetronics) • CORBA (C4ISR) • A-kit/B-kit (embedded sim)

15. Heterogeneous HLA/CORBA-based System Example How to harmonize these 3 architectures? Solution: Use real-time CORBA and related emerging specifications (real-time notification and data distribution), as the distributed communications middleware for all vetronics, C4ISR, and embedded simulation applications. Benefits: Efficient and maintainable coupling between the operational vehicle software and the embedded simulation capabilities. Figure: Proposed Integrated Architecture

16. Heterogeneous HLA/CORBA-based System Example • An integrated CORBA/HLA-based architecture could consist of application objects inheriting from a CORBA object as shown. • Transitions to the operational or training states can only occur from the initialization state (right). Figure: Example Vehicle States Figure: Diagram Example, Class Diagram Flexible, non-intrusive, transparent, embedded simulation capability

17. Heterogeneous HLA/CORBA-based System Example • Can also specify the interface to the application objects in a way that hides the actual middleware. Figure: Example Vehicle States

18. Summary and Conclusions • Observed open standards based architecture that seamlessly integrates embedded simulation capabilities into a real-time embedded ground vehicle system. • Only CORBA is mature enough for use in ground combat vehicles. • HLA, has drawbacks in the areas of real-time computing, interoperability, and platform availability. • CORBA-based HLA run-time infrastructures, however, can alleviate shortcomings. • Further work to validate the architecture approach. • This validation can be accomplished in multiple stages: (1) CORBA-based vehicle software and (2) a non-CORBA, workstation-based RTI implementation. • Would both ensure that the architecture approach is sound and would start to mature the application object interfaces.

19. Backup Slides

20. High-level Architecture Overview 5 Federation Rules: 1) Federation shall have FOM in object model template (OMT) format. 2) All representation of objects shall be in the federates and not the RTI. 3) During federation execution, all exchange of FOM data shall be via the RTI. 4) “” all federates shall interact with the RTI in accordance with the interface specification. 5) “” an attribute of an instance of an object may be owned by only one federate at a given time.

21. High-level Architecture Overview 5 Federate Rules: 1) Federates shall have a SOM in OMT format. 2)Federates shall be able to update/reflect attributes and send/receive data in accordance with their SOM 3) Federates shall be able to transfer/accept attribute ownership in accordance with their SOM 4) Federates shall be able to vary the conditions under which they provide attribute updates in accordance with their SOM; and 5) Federates shall be able to manage the local time in a way which will allow them to coordinate data exchange with other members of the federation.