View
432
Download
4
Embed Size (px)
DESCRIPTION
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.
Citation preview
1 2012 Fall SIW
A Comparison of
Simulation and
Operational Architectures
Angelo CORSARO, Ph.D.
PrismTech [email protected]
Dan GREGORY THALES
Jose-Maria LOPEZ-RODRIGUEZ NADS
Jose-Ramon MARTINEZ NADS
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