Transcript CORBA and HLA: Enabling Future Network-Centric Vehicle Systems? Robert Kling Electronic Architecture Team Email: [email protected] Phone: (586) 574-5144 Fax (586) 574-5008 U.S.

CORBA and HLA: Enabling Future Network-Centric Vehicle
Systems?
Robert Kling
Electronic Architecture Team
Email: [email protected]
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 & Armaments COMmand
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
2
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.
3
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:
C4ISR
Architecture
Platform
Architecture
Modeling
and
Simulation
Architecture
– Architectures based on distinct domains.
• Current approach: “bolt-on.”
More elegant solution instead reconciles distinct middlewares.
4
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).
5
High-level Architecture Overview
Federate
Support
Utilities
Federate
Federate
Run-Time Infrastructure
Federation Management
Object Management
Time Management
Declaration Management
Ownership Management
Data Distribution Management
Figure: HLA Architecture
6
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
7
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.
8
CORBA Overview
Client
Client
Object
Object
Implementation
Implementation
IDL
Stub
IDL
Skeleton
Request
Object Request Broker
Figure: CORBA Architecture
9
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.
10
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.
11
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.
12
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.
Embedded
Simulation
Distributed Simulation
PC-based Computer
HLA
A-Kit
Virtual
Battlespace
B-Kit
Virtual Scene
Vehicle
Embedded Computer
TCP/IP
Figure: Embedded Simulation System
13
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)
14
Heterogeneous HLA/CORBA-based System
Example
How to harmonize these 3
architectures?
Virtual Scene
Solution: Use real-time CORBA and
related emerging specifications (realVirtual
time notification and data
Battlespace
distribution), as the distributed
communications middleware for all
vetronics, C4ISR, and embedded
simulation applications.
Embedded
Simulation
Vehicle
HLA RTI
Benefits: Efficient and maintainable
coupling between the operational
vehicle software and the embedded
simulation capabilities.
RT CORBA ORB
Figure: Proposed Integrated Architecture
15
Heterogeneous HLA/CORBA-based System
Example
• Transitions to the operational or
training states can only occur from
the initialization state (right).
Power-On
• An integrated CORBA/HLA-based
architecture could consist of
application objects inheriting from a
CORBA object as shown.
Power-Off
Initialization
Operational
Training
Figure: Example Vehicle States
Figure: Diagram Example,
Class Diagram
Flexible, non-intrusive, transparent, embedded simulation capability
16
Heterogeneous HLA/CORBA-based System
Example
•Can also specify the interface to the application objects in a way that hides
the actual middleware.
Stati on
Manager
Called durin g
operational state
Bind( )
Bind( )
Operational
Sensor
Simulated
Sensor
Set Azimuth( )
Called during
training state
Set Azimuth( )
Lethality
Figure: Example Vehicle States
17
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.
18
Backup Slides
19
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.
20
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.
21