TTank-automotive & AArmaments COMCOMmandUNCLASSIFIED

10 June 2003

Robert KlingElectronic Architecture Team

Email: klingr@tacom.army.mil

Phone: (586) 574-5144Fax (586) 574-5008

U.S. Army Tank-Automotive RD&E Center (TARDEC)Vetronics Technology Area

(AMSTA-TR-R, Mailstop 264)Warren, MI 48397-5000

CORBA and HLA: Enabling Future Network-Centric Vehicle Systems?

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

BackgroundIncreased 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

PlatformArchitecture

C4ISRArchitecture

Modelingand

Simulation Architecture

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

SupportUtilities

Federate

Federate

Federate

Run-Time Infrastructure

Federation ManagementObject ManagementTime Management

Declaration ManagementOwnership ManagementData Distribution Management

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

IDLStub

IDLSkeleton

Object Request Broker

Request

ClientClientObject

ImplementationObject

Implementation

IDLStub

IDLSkeleton

Object Request Broker

Request

ClientClientObject

ImplementationObject

Implementation

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.

Vehicle

A-K

itA

-KitEmbedded

Simulation B-K

itB

-Kit

Embedded ComputerPC-based Computer

Virtual Scene

Distributed Simulation

VirtualBattlespace

HLA TCP/IP

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.

EmbeddedSimulation

VehicleVirtual

Battlespace

HLA RTI

RT CORBA ORB

Virtual Scene

Figure: Proposed Integrated Architecture

16

Heterogeneous HLA/CORBA-based System Example

• Transitions to the operational or training states can only occur from the initialization state (right).

Initialization

Operational Training

Power-OffPower-On

Figure: Example Vehicle States

CORBA Object

Bind()

Sensor

AzimuthElevation

Set Azimuth()

• An integrated CORBA/HLA-based architecture could consist of application objects inheriting from a CORBA object as shown.

Figure: Diagram Example,Class Diagram

Flexible, non-intrusive, transparent, embedded simulation capability

17

Heterogeneous HLA/CORBA-based System Example

Operational Sensor

Simulated Sensor

Station Manager

Bind( ) Bind( )

Lethality

Set Azimuth( ) Set Azimuth( )

Called during operational state

Called during training state

Figure: Example Vehicle States

•Can also specify the interface to the application objects in a way that hides the actual middleware.

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 Overview5 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 Overview5 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.