1 2012 Fall SIW

A Comparison of

Simulation and

Operational Architectures

Angelo CORSARO, Ph.D.

PrismTech angelo.corsaro@prismtech.com

Dan GREGORY THALES

dan.gregory@thalesgroup.com

Jose-Maria LOPEZ-RODRIGUEZ NADS

jmlrodriguez@nexteleng.es

Jose-Ramon MARTINEZ NADS

jrmartinez@nexteleng.es

2

Agenda

■ Context

■ Standards in Operational Systems

■ DDS and HLA Compared

■ Applicability to LVCAR

■ Concluding Remarks

3

Context

3

4

Converging Needs

■ Defense Operational and Simulation Systems are increasingly exposing converging needs, such as

‣ Interoperability

‣ Dependability and Security

‣ Scalability, Performance and QoS

‣ Plug and Play Connectivity

5

Converging

Technologies

■ As noted recently by Gartner there is a convergence between technologies used in Operational and Information Systems

■ A similar convergence is emerging in Operational and Simulation Systems

6

Standards in

Operational

Systems

6

7

Standards in Operational

Systems

■ Operational Systems are converging toward the following standards

‣ OMG DDS for high performance data distribution

‣ Web Services (not only W3C) for coordination

This presentation will focus on DDS and its difference and

similarities with HLA

8

DDS in Brief

■ Introduced in 2004 to address the Data Distribution challenges faced by a wide class of Defense and Aerospace Applications

■ Key requirement for the standard were to deliver very high and predictable performance while scaling from embedded to ultra-large-scale deployments

DDS in Brief

■ US DoD

‣ US Navy: Open Architecture for NavalCMS

‣ DISR/DISA: Net-centric Systems

‣ UAS Control Segment (UCS): Unmanned Aircraft Systems

■ EU ATM

‣ EUROCAE: Air Traffic Control Center Operational Interoperability

■ UK MoD:

‣ Generic Vehicle Architecture: Open Interoperable architecture for next generation vehicles

9 Ministry of Defence

DDS is mandated/recommended by an increasing number of

administrations

23

DDS in Defense and

Aerospace

Integrated Modular Vetronics Training & Simulation Systems Naval Combat Systems

Air Traffic Control & Management Unmanned Air Vehicles Aerospace Applications

24

DDS in Commercial

Applications

Agricultural Vehicle Systems

Train Control Systems Complex Medical Devices

Smart Cities Large Scale SCADA Systems

High Frequency Auto-Trading

12

DDS and HLA

Compared

12

16

DDS and HLA Goals DDS HLA

■ Foster interoperability and portability of Distributed Operational Systems

■ Address functional and non-functional requirements of Operational Systems

■ Foster interoperability and portability of Distributed Simulation Systems

■ Address functional requirements and (some) non functional requirements of Simulation Systems

17

Standard Scope

DDS HLA

■ DDS and HLA define standardized ways of describing application Data.

18

Standardization

History

18

Standardization

History

21 2012 Fall SIW

Similarities and

Differences

[DDS/HLA ]

DDS HLA

API Standard Yes Yes

Wire Protocol

Standard Yes

No (essentially underspecified)

Data Modeling

Standard

Yes (IDL, XML, XSD,

UML) Yes (OMT, XML)

Discovery Fully Dynamic Static Declaration of FOM

Dynamic Matching

Pub/Sub

Architectural Style Fully Distributed Implementation

Dependent (Most implementation have a centralized broker)

22 2012 Fall SIW

Similarities and

Differences

[DDS/HLA ]

DDS HLA

Subscription

Model

Per Topic with Content

Filters and Queries

Per Object Attribute

Per Interaction

QoS 22 QoS Policies 2 QoS Policies

(Reliability and Ordering)

Coupling ‣ No dependency on

global knowledge

‣ Time decoupling

‣ Dependency on

globally defined FOM

‣ Time coupling

Time

Management Basic Timestamping

Sophisticated time

management service

25

DDS and HLA

Fundamentals

20

Data Distribution

Service

■ Topics: data distribution subject’s

■ DataWriters: data producers

■ DataReaders: data consumers

For Real-Time Systems

DDS provides a Topic-Based Publish/Subscribe abstraction based on:

21

Data Distribution

Service

■ DataWriters and DataReaders are automatically and dynamically matched by the DDS Dynamic Discovery

■ A rich set of QoS allows the control existential, temporal, and spatial properties of data

For Real-Time Systems

22

HLA Federation

■ An HLA Federation is a collection of Federates (essentially HLA applications) sharing a common Federation Object Model (FOM)

■ Each Federate can publish/subscribe a subset Objects Attributes and Interactions defined by the Federation FOM.

RTI (Run-Time Infrastructure)

Federate A Federate B Federate K ...

Federation Object Model

<FOM>

<Shared object classes>

<Shared interaction classes>

<More>

</FOM>

23

DDS Topics

■ A Topic defines a class of streams

■ A Topic has associated a unique name, a user defined extensible type and a set of QoS policies

■ QoS Policies capture the Topic non-functional invariants

■ Topics can be discovered or locally defined

DURABILITY

,

DEADLINE,

PRIORITY,

…

“Circle”, “Square”, “Triangle”, ...

ShapeType

struct ShapeType {

@Key string color;

long x;

long y;

long shapesize;

};

TopicType

Name

QoS

24

HLA Objects

■ HLA Objects identify a class of instances whose attributes can be individually published/subscribed

■ QoS are controlled at an attribute-level

(objects

(class Shape

(attribute color reliable timestamp ShapeSpace)

(attribute x best_effort timestamp ShapeSpace)

(attribute y best_effort timestamp ShapeSpace)

(attribute shapesize reliable timestamp ShapeSpace)

)

)

Object attributes can be bound to spaces and dimensions to

organize/partition the data distribution

25

HLA Interactions

■ HLA Interactions are used to model consumable events

■ Interactions are published/subscribed as atomically

■ QoS is attached with the interaction

(interactions

(class ShapeCollision reliable timestamp ShapeSpace

(attribute x)

(attribute y)

)

)

33 2012 Fall SIW

DDS HLA

Polymorphism

■ HLA provides supports for traditional subtype polymorphism as supported in declarative nominal type systems

■ HLA supports only single inheritance

■ This means that a subscription for a type X matches a publication for a type Y iff Y <: X

■ DDS is equipped with a structural type system where subtype relationships are deduced based on type properties as opposed to syntactical declaration

■ This means that a subscription for a type X matches a publication for a type Y iff Y <: X (the subtype property is antisymmetric, reflexive, and transitive)

34 2012 Fall SIW

DDS HLA

Polymorphism

☐ Point3D <: Point

☐ GPoint <: Point3D

☐ Point3D <: Point

35

Anatomy of a DDS

Application

Ta

Tb

Tc

Tx

Ty

T1

T1 T3

36

37 2012 Fall SIW

Data Selection

DDS HLA

• Pub/Sub granularity are attributes for Object and the whole class for an Interaction

• Data can be organized in Spaces and Dimensions

■ Pub/Sub granularity is the Topic

■ Data can be organized into Partitions. Partitions matching is based on regular expression

■ Content Filters and Queries can be used to select the data that is received

42

Domain

Reader/Writers for User Defined for Types

Session

Reader/Writer for application defined Topic Types

42

[DDS C++ API 2010]

auto dp = DomainParticipant(domainId);

// Create a Topic

auto topic = Topic<ShapeType>(dp, “Circle”) // Create a Publisher / Subscriber

auto pub = Publisher(dp)

auto sub = Subscriber(dp)

// Create a DataWriter/DataWriter

auto writer = DataWriter<ShapeType>(pub, topic);

auto reader = DataReader<ShapeType>(sub, topic);

31

Anatomy of a DDS

Application

42

Domain

Reader/Writers for User Defined for Types

Session

Reader/Writer for application defined Topic Types

42

[DDS C++ API 2010]

auto dp = DomainParticipant(domainId);

// Create a Topic

auto topic = Topic<ShapeType>(dp, “Circle”) // Create a Publisher / Subscriber

auto pub = Publisher(dp)

auto sub = Subscriber(dp)

32

// Write data

writer.write(ShapeType(“RED”, 131, 107, 89));

// But you can also write like this...

writer << ShapeType(“RED”, 131, 107, 89);

// Read new data (loaned)

auto data = reader.read();

Anatomy of a DDS

Application

44 2012 Fall SIW

Anatomy of an HLA

Application using namespace std;

int main( int argc, char *argv[] )

{

// 1. create the RTIambassador that we are going to work with

RTI::RTIambassador* rtiamb = 0;

rtiamb = new RTI::RTIambassador();

// 2. create the federation execution

rtiamb->createFederationExecution( "exampleFederation", "testfom.fed" );

cout << "Created federation" << endl;

// 3. join the federation execution

RTI::FederateAmbassador* fedamb = new MyFedAmb();

rtiamb->joinFederationExecution( "myFederate", "exampleFederation", fedamb );

cout << "Joined federation" << endl;

// Pub/Sub...

// 4. resign from the federation execution

rtiamb->resignFederationExecution( RTI::DELETE_OBJECTS_AND_RELEASE_ATTRIBUTES );

cout << "Resigned from federation" << endl;

// 5. destroy the federation execution

rtiamb->destroyFederationExecution( "exampleFederation" );

cout << "Destroyed federation" << endl;

// 6. do some cleanup and exit

delete rtiamb;

return 0;

}

Federation

Federate

34

QoS

34

46 2012 Fall SIW

DDS QoS Model

■ QoS-Policies control local and end-to-end properties of DDS entities

■ Local properties controlled by QoS are related resource usage

■ End-to-end properties controlled by QoS are related to temporal and spatial aspects of data distribution

■ Some QoS-Policies are matched based on a Request vs. Offered Model thus QoS-enforcement

2012 Fall SIW

DDS QoS Policies [T: Topic] [DR: DataReader] [DW: DataWriter] [P: Publisher] [S: Subscriber] [DP: Domain Participant]

QoS Policy Applicability RxO Modifiable

USER_DATA DP, DR, DW N Y

Configuration TOPIC_DATA T N Y

GROUP_DATA P, S N Y

DURABILITY T, DR, DW Y N

Data

Availability

DURABILITY

SERVICE

T, DW N N

HISTORY T, DR, DW N N

PRESENTATION P, S Y N

Data Delivery

RELIABILITY T, DR, DW Y N

PARTITION P, S N Y

DESTINATION

ORDER

T, DR, DW Y N

LIFESPAN T, DW N Y

2012 Fall SIW

DDS QoS Policies [T: Topic] [DR: DataReader] [DW: DataWriter] [P: Publisher] [S: Subscriber] [DP: Domain Participant]

QoS Policy Applicability RxO Modifiable

DEADLINE T, DR, DW Y Y

Temporal/Impor

tance

Characteristics

LATENCY

BUDGET

T, DR, DW Y Y

TRANSPORT

PRIORITY

T, DW N Y

TIME BASED

FILTER

DR N Y

OWNERSHIP T, DR, DW Y N

Replication OWNERSHIP

STRENGTH

DW N Y

LIVELINESS T, DR, DW Y N Fault-Detection

52 2012 Fall SIW

HLA QoS Policies

■ HLA provides roughly only two policies, one for controlling the reliability and the other for controlling the ordering of data

■ HLA ties policies with data thus does not allow different producer/consumers to refine the QoS with which data is produced/consumed

53 2012 Fall SIW

Time Management DDS HLA

☐ HLA provides support for:

☐ Event Driven Simulation

☐ Time Stepped Simulation

☐ Parallel Discrete-Event

Simulation

☐ Wall-clock-time Simulation

☐ The HLA Time Service

provides primitives to

coordinate and control the

advancement of time

☐ Along with automatic

time-stamping based on

real-time, DDS provides

an API for time-stamping

messages

☐ This API can be used to

implement logical clocks

40

Applicability to

Simulation

40

Why are we thinking in DDS for

Simulation?

1

Many simulation architectures without a “glue”

that allows to reduce the cost of distributed

simulation

2

Figure from Coolahan and Allen , M&S Journal 2012 Spring

Because many are asking for some

“glue” in distributed simulation

3

Based on proposal of Saunders (2010 I/ITSEC) to use CSI for convergence

We think that DDS has a lot to offer the

simulation community

Glue?

Wire protocols for a layered approach?

Ideas for future evolutions of simulation standards e.g. quality of service?

The new LSA Study Group plans to identify (among other things) how we can leverage existing DCM.

4

60

Summing Up

46

Concluding

Remarks ■ DDS provides a very powerful and high-performance

infrastructure for data distribution

■ When compared to HLA, DDS stands out for its support for evolvability and dynamic systems/federations

■ On the down-side, DDS is a technology that was designed for Operational Systems, as such it does not provide mechanisms such as Time Management. However these mechanisms can easily be implemented over DDS

■ The role of DDS/DDSI in simulation interoperability should be investigated

47

Get Involved / Learn

More

■ LSA Study Group Kick Off Meeting

‣ Thursday, 8:00 - 12:00 in Forum West 1

■ DDS Intro

‣ Thursday, 8:30 - 9:30 in Forum West 1

62