A comparison of Simulation and Operational Architectures


Published on

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.

Published in: Business, Technology
1 Comment
1 Like
  • Hi smc516. Thanks for your interest in our papers. Do you need some help?
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

A comparison of Simulation and Operational Architectures

  1. 1. A Comparison of Simulation andOperational 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. 2. Agenda■ Context■ Standards in Operational Systems■ DDS and HLA Compared■ Applicability to LVCAR■ Concluding Remarks 2
  3. 3. Context 3
  4. 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. 5. ConvergingTechnologies■ 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. 6. Standards inOperational Systems 6
  7. 7. Standards in OperationalSystems■ Operational Systems are converging toward the following standards ‣ OMG DDS for high performance data distribution ‣ Web Services (not only W3C) for coordinationThis presentation will focus on DDS and its difference andsimilarities with HLA 7
  8. 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. 9. DDS in BriefDDS is mandated/recommended by an increasing number ofadministrations■ 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. 10. DDS in Defense andAerospace Integrated Modular Vetronics Training & Simulation Systems Naval Combat SystemsAir Traffic Control & Management Unmanned Air Vehicles Aerospace Applications 23
  11. 11. DDS in CommercialApplications Agricultural Vehicle Systems Large Scale SCADA Systems Smart Cities Train Control Systems Complex Medical Devices High Frequency Auto-Trading 24
  12. 12. DDS and HLA Compared 12
  13. 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. 14. Standard Scope DDS HLA ■ DDS and HLA define standardized ways of describing application Data. 17
  15. 15. StandardizationHistory 18
  16. 16. StandardizationHistory 18
  17. 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. 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. 19. DDS and HLAFundamentals 25
  20. 20. Data DistributionServiceFor Real-Time SystemsDDS provides a Topic-BasedPublish/Subscribe abstraction basedon: ■ Topics: data distribution subject’s■ DataWriters: data producers■ DataReaders: data consumers 20
  21. 21. Data DistributionServiceFor 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. 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. 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. 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-levelObject attributes can be bound to spaces and dimensions toorganize/partition the data distribution 24
  25. 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. 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. 27. Polymorphism DDS HLA ☐ Point3D <: Point ☐ Point3D <: Point ☐ GPoint <: Point3D 2012 Fall SIW 34
  28. 28. Anatomy of a DDSApplication T1 T1 T3 Tx Ty Tb Ta Tc 35
  29. 29. 36
  30. 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. 31. Anatomy of a DDSApplication[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. 32. Anatomy of a DDSApplication[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. 33. Anatomy of an HLAApplication using namespace std; int main( int argc, char *argv[] ) { // 1. create the RTIambassador that we are going to work withFederation 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. 34. QoS 34
  35. 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. 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. 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. 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. 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. 40. Applicability to Simulation 40
  41. 41. Why are we thinking in DDS forSimulation? Many simulation architectures without a “glue” 1
  42. 42. that allows to reduce the cost of distributedsimulation Figure from Coolahan and Allen , M&S Journal 2012 Spring 2
  43. 43. Because many are asking for some“glue” in distributed simulationBased on proposal of Saunders (2010 I/ITSEC) to use CSI for convergence 3
  44. 44. We think that DDS has a lot to offer thesimulation 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. 45. Summing Up 60
  46. 46. ConcludingRemarks■ 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. 47. Get Involved / LearnMore■ 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. 48. 62