This whitepaper presents a comparison between simulation and operational architectures. Presented at the Simulation Interoperability Standards Organization (SISO) 2012 Fall Simulation Interoperability Workshop in Orlando, FL, USA. The paper is co-authored with Thales and Prismtech.

1. A Comparison of
Simulation and
Operational Architectures
Angelo CORSARO, Ph.D. Jose-Maria LOPEZ-RODRIGUEZ
PrismTech NADS
angelo.corsaro@prismtech.com jmlrodriguez@nexteleng.es
Dan GREGORY Jose-Ramon MARTINEZ
THALES NADS
dan.gregory@thalesgroup.com jrmartinez@nexteleng.es
2012 Fall SIW 1

2. Agenda
■ Context
■ Standards in Operational Systems
■ DDS and HLA Compared
■ Applicability to LVCAR
■ Concluding Remarks
2

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
4

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
5

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
7

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
8

9. DDS in Brief
DDS is mandated/recommended by an increasing number of
administrations
■ 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

10. DDS in Defense and
Aerospace
Integrated Modular Vetronics Training & Simulation Systems Naval Combat Systems
Air Traffic Control & Management Unmanned Air Vehicles Aerospace Applications
23

11. DDS in Commercial
Applications
Agricultural Vehicle Systems Large Scale SCADA Systems Smart Cities
Train Control Systems Complex Medical Devices High Frequency Auto-Trading
24

12. DDS and HLA
Compared
12

13. DDS and HLA Goals
DDS HLA
■ Foster interoperability ■ Foster interoperability
and portability of and portability of
Distributed Distributed Simulation
Operational Systems Systems
■ Address functional ■ Address functional
and non-functional requirements and
requirements of (some) non functional
Operational Systems requirements of
Simulation Systems
16

14. Standard Scope
DDS HLA
■ DDS and HLA define standardized ways of describing application Data.
17

15. Standardization
History
18

16. Standardization
History
18

17. Similarities and
[DDS/HLA ]
Differences
DDS HLA
API Standard Yes Yes
Wire Protocol No
Yes
Standard (essentially underspecified)
Data Modeling Yes (IDL, XML, XSD,
Yes (OMT, XML)
Standard UML)
Static Declaration of FOM
Discovery Fully Dynamic Dynamic Matching
Pub/Sub
Implementation
Architectural Style Fully Distributed SIW Dependent
2012 Fall 21
(Most implementation have a centralized broker)

18. Similarities and
[DDS/HLA ]
Differences DDS HLA
Subscription Per Topic with Content Per Object Attribute
Model Filters and Queries Per Interaction
2 QoS Policies
QoS 22 QoS Policies
(Reliability and Ordering)
‣ No dependency on ‣ Dependency on
Coupling global knowledge globally defined FOM
‣ Time decoupling ‣ Time coupling
Time Sophisticated time
Basic Timestamping
Management management service
2012 Fall SIW 22

19. DDS and HLA
Fundamentals
25

20. Data Distribution
Service
For Real-Time Systems
DDS provides a Topic-Based
Publish/Subscribe abstraction based
on:
■ Topics: data distribution subject’s
■ DataWriters: data producers
■ DataReaders: data consumers
20

21. Data Distribution
Service
For Real-Time Systems
■ 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
21

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.
Federate A Federate B ... Federate K
Federation Object Model
<FOM>
<Shared object classes>
<Shared interaction classes>
<More>
</FOM>
RTI (Run-Time Infrastructure)
22

23. DDS Topics
“Circle”, “Square”, “Triangle”, ...
■ A Topic defines a class of
streams Name
■ A Topic has associated a
Topic
unique name, a user defined
Typ
S
Qo
e
extensible type and a set of DURABILITY
QoS policies ,
ShapeType
DEADLINE,
■ QoS Policies capture the PRIORITY,
…
Topic non-functional struct ShapeType {
invariants @Key string color;
long x;
■ Topics can be discovered or long y;
long shapesize;
locally defined };
23

24. HLA Objects
■ HLA Objects identify
a class of instances
(objects
whose attributes can (class Shape
(attribute color reliable timestamp ShapeSpace)
be individually (attribute x best_effort timestamp ShapeSpace)
(attribute y best_effort timestamp ShapeSpace)
published/subscribe )
(attribute shapesize reliable timestamp ShapeSpace)
d )
■ QoS are controlled at
an attribute-level
Object attributes can be bound to spaces and dimensions to
organize/partition the data distribution
24

25. HLA Interactions
■ HLA Interactions are
used to model (interactions
consumable events (class ShapeCollision reliable timestamp ShapeSpace
(attribute x)
(attribute y)
■ Interactions are )
)
published/subscribed
as atomically
■ QoS is attached with
the interaction
25

26. Polymorphism
DDS HLA
■ DDS is equipped with a ■ HLA provides supports for
structural type system where traditional subtype polymorphism
subtype relationships are as supported in declarative
deduced based on type nominal type systems
properties as opposed to
■ HLA supports only single
syntactical declaration
inheritance
■ This means that a
■ This means that a subscription for
subscription for a type X
a type X matches a publication for
matches a publication for a
a type Y iff Y <: X
type Y iff Y <: X (the subtype
property is antisymmetric,
reflexive, and transitive)
2012 Fall SIW 33

27. Polymorphism
DDS HLA
☐ Point3D <: Point ☐ Point3D <: Point
☐ GPoint <: Point3D
2012 Fall SIW 34

28. Anatomy of a DDS
Application
T1
T1 T3
Tx
Ty
Tb
Ta
Tc
35

29. 36

30. Data Selection
DDS HLA
■ Pub/Sub granularity is • Pub/Sub granularity are
the Topic attributes for Object and
the whole class for an
■ Data can be organized
Interaction
into Partitions. Partitions
matching is based on • Data can be organized in
regular expression Spaces and Dimensions
■ Content Filters and
Queries can be used to
select the data that is
received
2012 Fall SIW 37

31. Anatomy of a DDS
Application
[DDS C++ API 2010]
Domain
auto dp = DomainParticipant(domainId);
Session
// Create a Topic
auto topic = Topic<ShapeType>(dp, “Circle”)
// Create a Publisher / Subscriber
auto pub = Publisher(dp)
auto sub = Subscriber(dp)
Reader/Writers for User Defined for Types
Reader/Writer for
// Create a DataWriter/DataWriter application defined
auto writer = DataWriter<ShapeType>(pub, topic); Topic Types
auto reader = DataReader<ShapeType>(sub, topic);
42 31

32. Anatomy of a DDS
Application
[DDS C++ API 2010]
Domain
auto dp = DomainParticipant(domainId);
Session
// Create a Topic
auto topic = Topic<ShapeType>(dp, “Circle”)
// Create a Publisher / Subscriber
auto pub = Publisher(dp)
auto sub = Subscriber(dp)
Reader/Writers for User Defined for Types
Reader/Writer for
// Write data application defined
writer.write(ShapeType(“RED”, 131, 107, 89)); Topic Types
// But you can also write like this...
writer << ShapeType(“RED”, 131, 107, 89);
// Read new data (loaned)
auto data = reader.read();
42 32

33. 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
Federation RTI::RTIambassador* rtiamb = 0;
rtiamb = new RTI::RTIambassador();
// 2. create the federation execution
rtiamb->createFederationExecution( "exampleFederation", "testfom.fed" );
cout << "Created federation" << endl;
Federate // 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; 2012 Fall SIW 44
}

34. QoS
34

35. 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 46

36. 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
TOPIC_DATA T N Y Configuration
GROUP_DATA P, S N Y
DURABILITY T, DR, DW Y N
DURABILITY T, DW N N Data
SERVICE Availability
HISTORY T, DR, DW N N
PRESENTATION P, S Y N
RELIABILITY T, DR, DW Y N
PARTITION P, S N Y Data Delivery
DESTINATION T, DR, DW Y N
ORDER
LIFESPAN T, DW N 2012 Fall SIWY

37. 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
LATENCY T, DR, DW Y Y
BUDGET Temporal/Impor
TRANSPORT T, DW N Y tance
PRIORITY Characteristics
TIME BASED DR N Y
FILTER
OWNERSHIP T, DR, DW Y N
OWNERSHIP DW N Y Replication
STRENGTH
LIVELINESS T, DR, DW Y N Fault-Detection
2012 Fall SIW

38. 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
2012 Fall SIW 52

39. Time Management
DDS HLA
☐ Along with automatic ☐ HLA provides support for:
time-stamping based on ☐ Event Driven Simulation
real-time, DDS provides
☐ Time Stepped Simulation
an API for time-stamping
☐ Parallel Discrete-Event
messages
Simulation
☐ Wall-clock-time Simulation
☐ This API can be used to
implement logical clocks
☐ The HLA Time Service
provides primitives to
coordinate and control the
advancement of time
2012 Fall SIW 53

40. Applicability to
Simulation
40

41. Why are we thinking in DDS for
Simulation?
Many simulation architectures without a “glue”
1

42. that allows to reduce the cost of distributed
simulation
Figure from Coolahan and Allen , M&S Journal 2012 Spring
2

43. Because many are asking for some
“glue” in distributed simulation
Based on proposal of Saunders (2010 I/ITSEC) to use CSI for convergence
3

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

45. Summing Up
60

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
46

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
47

48. 62