A comparison of Simulation and Operational Architectures
1 like•831 views
The document compares simulation and operational architectures, specifically focusing on the Data Distribution Service (DDS) and High-Level Architecture (HLA). It highlights the converging needs and technologies in defense operational and simulation systems, emphasizing interoperability, performance, and scalability. The conclusion suggests that while DDS offers high-performance data distribution infrastructure, it lacks certain features like time management, which can be addressed in future developments.
![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)](https://image.slidesharecdn.com/12f-siw-027slides-120917061108-phpapp01/85/A-comparison-of-Simulation-and-Operational-Architectures-17-320.jpg)
![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](https://image.slidesharecdn.com/12f-siw-027slides-120917061108-phpapp01/85/A-comparison-of-Simulation-and-Operational-Architectures-18-320.jpg)
![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](https://image.slidesharecdn.com/12f-siw-027slides-120917061108-phpapp01/85/A-comparison-of-Simulation-and-Operational-Architectures-31-320.jpg)
![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](https://image.slidesharecdn.com/12f-siw-027slides-120917061108-phpapp01/85/A-comparison-of-Simulation-and-Operational-Architectures-32-320.jpg)
![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
}](https://image.slidesharecdn.com/12f-siw-027slides-120917061108-phpapp01/85/A-comparison-of-Simulation-and-Operational-Architectures-33-320.jpg)
![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](https://image.slidesharecdn.com/12f-siw-027slides-120917061108-phpapp01/85/A-comparison-of-Simulation-and-Operational-Architectures-36-320.jpg)
![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](https://image.slidesharecdn.com/12f-siw-027slides-120917061108-phpapp01/85/A-comparison-of-Simulation-and-Operational-Architectures-37-320.jpg)
A comparison of Simulation and Operational Architectures
- 1. A Comparison of Simulation and Operational Architectures Angelo CORSARO, Ph.D. Jose-Maria LOPEZ-RODRIGUEZ PrismTech NADS [email protected] [email protected] Dan GREGORY Jose-Ramon MARTINEZ THALES NADS [email protected] [email protected] 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