OMG DDS: The Data Distribution Service for Real-Time Systems

OpenSplice DDS
Delivering Performance, Openness, and Freedom

Angelo Corsaro, Ph.D.
OMG DDS: The Data Distribution
Product Strategy Manager
OMG RTESS and DDS SIG Co-Chair
angelo.corsaro@prismtech.com

Service for Real-Time Systems

Motivating Forces
The Standard
Agenda

Architectural Principles
Programming Model
Future Directions

The Need for Data Distribution
Time Scale Geographical Scale

Proprietary Information - Distribution without Expressed Written Permission is Prohibited.
Parallelism Determinism Throughput, Availability Scalability, Persistence, Security

Systemic Real-Time Near Real-Time Fault-
Data Complex Information
Signal Information Tolerant Information
Processing Processing Management
Processing Processing
Data Distribution

Parallel Systems Distributed Systems
© 2009, PrismTech. All Rights Reserved

Data Exchange / Distribution
‣ Network Centric Architectures are emerging as a key trend for next generation military and civil
system of systems
‣ Efficient, scalable and QoS-enabled data dissemination is an enabling technology for Network
Joint Forces
Joint Forces
Centric Systems Global Info Grid
Global Info Grid

Adapted from “The Future of AWACS”,
by LtCol Joe Chapa

The Right Information => To the Right People => At the Right Time

Addressing Data Distribution Challenges
DDS is standard designed to address the data-distribution challenges across
The OMG DDS Standard a wide class of Defense and Aerospace Applications
‣ 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 its
ability to deliver very high performance while
seamlessly scaling from embedded to ultra-
large-scale deployments
‣ Today recommended by key administration
worldwide and widely adopted across
several different application domains, such
as, Automated Trading, Simulations, SCADA,
Telemetry, etc.


The OMG Data Distribution Service (DDS)

DDS v1.2 API Standard
‣ Language Independent, OS and HW architecture Application

independent Object/Relational Mapping

‣ DCPS. Standard API for Data-Centric, Topic- Data Local Reconstruction Layer (DLRL)

Based, Real-Time Publish/Subscribe

Content
‣
Ownership Durability
DLRL. Standard API for creating Object Views out Subscription

of collection of Topics Minimum Proﬁle

Data Centric Publish/Subscribe (DCPS)
DDSI/RTPS v2.1 Wire Protocol Standard
‣ Standard wire protocol allowing interoperability
Real-Time Publish/Subscribe Protocol

DDS Interoperability Wire Protocol
between different implementations of the DDS
standard UDP/IP

‣ Interoperability demonstrated among key DDS
vendors in March 2009

OMG DDS Recommendations is churning…
! The infrastructure evolution cycle
– New -> Emerging -> Standard -> Commodity
– Middleware is emerging as
Mandated/Recommended by key Administrations OS declines
! …DDS is maturing…
‣ US Navy: Open Architecture focus
– OMG
– Wire spec

– Tools
‣ DISR/DISA: Net-centric Systems
– Enterprise integration
– Multiple products fielded
‣ EuroControl: Air Traffic Control Center Operational
– Deployed applications!
Interoperability
! …and adoption is on the rise
– Navy for VSI
‣ QinetiQ: Recommending DDS
– DISR
– FCS/SoSCOE
– Many significant applications

OMG DDS Adoptions
Adopted by Most Challenging International Programs

‣ US FCS/SOSCOE

‣ European Next Generation Flight Data Processor

‣ US ZUMWALT [DDG(1000)]

‣ VTID adopting DDS for the architectural demonstrator


OMG DDS Applicability
Adapted from NSWC-DD Open Architecture Documentation
Communication Technologies Standards

Web SVCs The DDS is the
only technology
that spans across
Java RTSJ the board.

JMS It guarantees
exceptional real-
time behavior,
CORBA RT-CORBA while providing
unparalleled level
OMG Data Distribution Service (DDS)
of throughput !

MPI
Message Passing Interface

Non Real-Time Soft Real-Time Hard Real-Time Extreme Real-Time


Some DDS Use Cases
Defense
‣ Combat Management Systems
‣ Flycatcher system
‣ Unmanned Vehicles (Air + Land)
‣ Tactical Links

‣ Radar Processing
‣ Submarine Systems
‣ Future Combat Systems
‣ Simulation
SCADA/Utilities
‣ Industrial Automation
‣ Power Grids
‣ Rocket Launch Systems

Some DDS Use Cases
Transportation
‣ Air Traffic Management/Control
‣ Metropolitan Traffic Management
‣ Underground Metropolitan Transportation

Financial Services
‣ Automated Trading Firms
‣ Compliance Systems
‣ Market Data Platforms


Leading DDS Implementations

‣ Full Implementation of the OMG DDS Standard (DCPS+DLRL + DDSI)
‣ DCPS + DDSI available as Open Source at http://www.opensplice.org
‣ Developed and Commercially supported by PrismTech

‣ Implementation of the OMG DDS Standard (DCPS + DDSI)
‣ Developed and Commercially supported by RTI

‣ Partial Implementation of the OMG DDS Standard (Subset of DCPS)
‣ Available as Open Source at http://www.opendds.com
‣ Developed and Commercially supported by OCI


OpenSplice DDS

DDS vs AMQP

Scope of Standardization
AMQP OMG DDS
Application
Application
Object/Relational Mapping Object Relational Mapping
Standard API

Data Local Reconstruction Layer (DLRL)

DDS v1.2
Content
Subscription
API (?) Minimum Proﬁle
Pub/Sub Standard API


DDSI v2.1
AMQP v0.10

Advanced Message Queuing Protocol Real-Time Publish/Subscribe Protocol
Wire Protocol Standard
Interoperability Wire Protocol DDS Interoperability Wire Protocol

(TCP, SCTP, UDP)/IP UDP/IP


Architectural Style

AMQP OMG DDS
Subscriber Subscriber
Publisher Publisher

Broker Broker

Publisher
Broker Subscriber
Publisher
Broker Subscriber

Broker
Broker

Publisher Publisher
Subscriber Subscriber


Key Differences in Summary
AMQP DDS
‣ Brokered Communication ‣ Peer-to-Peer Communication
Architecture Architecture

‣ Wire Protocol Standard ‣ Wire Protocol + API Standard

‣ Interoperability across AMQP ‣ Interoperability across DDS implementations
implementations
‣ Application Portability across DDS
Implementation

‣ Header Based Routing ‣ Content-Based Filtering/Quering

‣ Not geared for High-Performance ‣ Designed bottom-up for maximum
performance and determinism


OpenSplice DDS

Loosely Coupled
Technology

Counting the “W’s” of Coupling
Request
Client Server The “4Ws” of Client/Server
Reply ‣ Who+Where: Space Coupling
‣ What: Structural Coupling
Client/Server ‣ When: Time Coupling
CORBA, COM+, Java RMI, .Net Remoting, Web SVCs

Subscriber
Publisher

Subscriber A Single “W” for DDS
Publisher ‣ What: Structural Coupling
Subscriber

Publisher
DDS Subscriber DDS features dynamic discovery
and full time decoupling!


OpenSplice DDS

High Performance/Availability
Pub/Sub

High Performance Pub/Sub
The right data, at the right place, at the right time
‣ Fully distributed, Peer-to-Peer -- All the Time.
Communication
‣ No Single Point of Failure Publisher
Subscriber

‣ No Single Point of Bottleneck

‣ Multicast-enabled Brokers Subscriber
‣ High performance and highly Publisher

scalable
‣ High availability Publisher
‣hot-swap
Subscriber

‣hot-hot architecture

OpenSplice DDS

Application

Ownership
Object/Relational Mapping


Durability
Content
Data-Centric
Pub/Sub
Subscription

Minimum Proﬁle




UDP/IP

Data-Centric Pub/Sub
‣ Data-Centric Features are built-in and
don’t rely on an external DBMS
‣ Providing thus performance, scalability,
and availability
‣ Distributed Relational Data Model Subscriber
Publisher DBMS
‣ Local Queries B

‣ Continuous Queries / Content Based

m

Subscriptions A F

Subscriber
‣ Windows
Publisher J
D C

‣ Object/Relational Mapping K
E

‣ Support for a subset of SQL-92
Publisher
Subscriber

Perfect Blend of Data-Centric and Real-Time
Publish/Subscribe Technologies

“Visualizing” Data-Centric Pub/Sub
Subscriber
Publisher B D J

D C
E K
A
B

A B

m
Subscriber
D C
Publisher A F

J
J A F
D C
K

A F K
E

Subscriber
Publisher D
J

D K
E

E

Organizing Information

‣ All DDS communication is Domain
Partition

happens within a Domain
‣ Domain can divided into Publisher
Subscriber

Partitions

B

‣ Topics are published and m

subscribed across on or A F

Subscriber
more Partitions Publisher J
D C

K
E

Publisher
Subscriber


Topics and Data-Centric Pub/Sub
‣ Topics. Unit of information exchanged between
Publisher and Subscribers. Topic

‣ Data Types. Type associated to a Topic must be
a structured type expressed in IDL struct TempSensor {
long tID;
Topic Type float temp;
‣ Topic Instances. Key values in a datatype

float humidity;
uniquely identify a Topic Instance (like rows in };
table) #pragma keylist TempSensor tID

TempSensor
‣ Content Awareness. SQL Expressions can be tID temp humidity

used to do content-aware subscriptions, Instances
1 21 62
2 27 78
queries, joins, and correlate topic instances 3 25.5 72.3

y
idit idit
y ity SELECT * FROM TempSensor t
um Samples mid
h um hu
62 h
65 63 WHERE t.temp > 25
p p
tem tem
p tem
21 22
tID 23 tID tID temp humidity
tID
1 1
1 2 27 78
3 25.5 72.3
t1 t2 t3 Time

Distributed Relational Information Modeling

‣ Topic Keys can be used to identify instances as well as relationships
‣ Relationships can be navigated by relying on a subset of SQL 92
‣ One-to-many relationships can be captured using foreign keys
‣ Many-to-many relationships need to be modeled using a topics

‣ Keys can be represented by an arbitrary number of Topic fields

TempSensor Room
Floor
tID: int rID: int fID: int
temp: float width: float level: int
humidity: float height: float open: int
rID: int length: float
fID: int


Data Centric Publish/Subscribe
Publishers Subscribers
TempSensor TempSensor
tID temp humidity tID temp humidity
1 18 60 1 18 60
2 22 75
3 21 71

struct TempSensor {
TempSensor int tID;
float temp; TempSensor
tID temp humidity
float humidity; tID temp humidity
2 22 75 };
2 22 75
#pragma keylist TempSensor tID
3 21 71

SELECT * FROM TempSensor t
WHERE s.temp > 20
s.t
TempSensor ID
==
tID temp humidity
Fully Distributed Global 1 TempSensor
3 21 71 Data Space tID temp humidity
1 18 60


Data Centric Publish/Subscribe
Publishers Subscribers
TempSensor TempSensor
tID temp humidity tID temp humidity
1 21 62 1 21 62
2 22 75
3 21 71

struct TempSensor {
TempSensor int tID;
float temp; TempSensor
tID temp humidity
float humidity;
2 22 75 tID temp humidity
};
#pragma keylist TempSensor tID 1 21 62
2 22 75
3 21 71

SELECT * FROM TempSensor t
s.t WHERE s.temp > 20
TempSensor ID
==
tID temp humidity
Fully Distributed Global 1
TempSensor
3 21 71 Data Space
tID temp humidity
1 21 62


Processing Content & Structure Complex Event Processing...

‣ Local Queries DDS provides some of the most useful features
found in Complex Event Processing platforms!
‣ Continuous Queries (Content-based Subscriptions)
‣ Topics Joins & Projections
‣ Events windows (via History QoS)

tID temp humidity S1
3 21.5 72.3
tID temp humidity {iID = 1}
2 20 78
tID temp humidity
1 21 62
S2
P {temp > 21 | humidity > 75}

S3
{ temp <16 }


Processing Content & Structure Complex Event Processing...

‣ Local Queries DDS provides some of the most useful features
found in Complex Event Processing platforms!
‣ Continuous Queries (Content-based Subscriptions)
‣ Topics Joins & Projections
‣ Events windows (via History QoS)

tID temp humidity
1 21 62

S1
{iID = 1} tID temp humidity
2 20 78
3 21.5 72.3

S2
P {temp > 21 | humidity > 75}

S3
{ temp <16 }


OpenSplice DDS

Application

Ownership


Durability
Content
Object-Oriented
Pub/Sub
Subscription

Minimum Proﬁle




UDP/IP

TempSensor
temp: float
humidity: float

‣ Automatically bridges the
getTemp()
getHumidity() * Room Floor
1 width: float level: int
Object/Relational Impedance height: float
length: float *
open: int
1 climate: int
Conditioner
Mismatch temp: float
humidity: float
1 climate: int
set_climate();
set_status()
set_climate()
*

‣ Arbitrary object setTemp() get_level()

setHumidity()
setFanLevel()
reconstructions start()
stop()
‣ Automatic Relationships pause():

Management TConditioner
cID: int TTempSernsor

‣ Inheritance
temp: float tID: int
humidity: float temp: float
fan_level: int TRoom humidity: float

‣ Local Operations status: int
rID: int
rID: int
width: float
height: float
rID: int

‣ Local/Distributed State length: float
fID: int
TFloor
fID: int
level: int
open: int


Object/Relational Mapping Unleashing the power of Objects...

Object Oriented
Canvas
OO Relational handle: Handle

‣ Middleware can automatically Flight
RadarTrack
manage the generation and FlightView call_sign: string
x: float
image: string route: list
association between the refresh_rate: int * origin: string
y: float
* z: float
* 1
Object-Oriented Model and the visible: bool dest: string
radar_id: string
Relational Model uid: GUID aircraft: string
operationOne()
display() operationX()
operationTwo()

operationY()

FlightViewTopic FlightViewAssociation
FlightTopic Relational
call_sign: string
image: string call_sign: string
route: list RadarTrackTopic
refresh_rate: int uid: GUID
origin: string x: float
visible: bool handle: Handle
dest: string y: float
uid: GUID
aircraft: string z: float
radar_id: string radar_id: string

Relational OO
‣ The Relational Model can be mapped to an Object Oriented model
‣ The mapping is under control of the architect


Multiple Object/Relational Mappings
Canvas
FastFlightView
image: string
handle: Handle
DLRL

DLRL
refresh_rate: int
visible: bool Flight
uid: GUID RadarTrack
FlightView call_sign: string
x: float x: float
image: string route: list
y: float y: float
refresh_rate: int * * origin: string 1 * z: float
z: float
visible: bool dest: string
call_sign: string radar_id: string
uid: GUID aircraft: string
display() operationOne()

display() operationX()
operationTwo()
operationY()

FlightViewTopic FlightViewAssociation
FlightTopic DCPS
call_sign: string
image: string call_sign: string
route: list RadarTrackTopic
refresh_rate: int uid: GUID
origin: string x: float
visible: bool handle: Handle
dest: string y: float
uid: GUID
aircraft: string z: float
radar_id: string radar_id: string

Multiple Mappings
‣ Different Object/Relatioal Mappings (ORM) can be used for different subsystems
‣ The state is shared across all the local reconstruction (ORMs)


An Example
High-End 3D Visualization Primary Radar

RadarTrack
x: float
y: float
z: float
radar_id: string
operationOne()
operationTwo()

FastFlightView RadarTrackTopic
x: float
image: string y: float
refresh_rate: int FlightViewTopic
image: string
z: float
radar_id: string
visible: bool refresh_rate: int
visible: bool
uid: GUID uid: GUID
x: float
y: float RadarTrackTopic
x: float
z: float y: float
z: float
display() RadarTrackTopic
x: float
y: float FlightTopic
call_sign: string
z: float route: list
radar_id: string origin: string
dest: string
aircraft: string
radar_id: string Flight
call_sign: string
route: list
RadarTrack
origin: string RadarTrackList
dest: string
aircraft: string
operationX()
operationY()

Flight Data Processor


An Example

RadarTrack
x: float
y: float
z: float
radar_id: string
operationOne()
operationTwo()

FastFlightView RadarTrackTopic
x: float
image: string y: float
z: float
image: string radar_id: string
visible: bool refresh_rate: int
visible: bool
uid: GUID uid: GUID
x: float
y: float RadarTrackTopic
x: float
z: float y: float
z: float
display() RadarTrackTopic
x: float
call_sign: string
z: float route: list
radar_id: string origin: string
dest: string
aircraft: string
radar_id: string Flight
call_sign: string
route: list
RadarTrack
dest: string
aircraft: string
operationX()
operationY()

Flight Data Processor


An Example

Secondary Radar

RadarTrack
x: float
y: float
z: float
radar_id: string RadarTrack
operationOne() x: float
operationTwo() y: float

z: float
radar_id: string
operationOne()
operationTwo()

FastFlightView RadarTrackTopic RadarTrackTopic
x: float x: float
image: string y: float y: float
image: string
z: float
radar_id: string
z: float
radar_id: string
visible: bool refresh_rate: int RadarTrackTopic
visible: bool x: float
uid: GUID uid: GUID y: float
x: float z: float
radar_id: string
y: float
RadarTrackTopic
z: float x: float
call_sign: string RadarTrackTopic y: float
x: float z: float
display() y: float radar_id: string
z: float FlightTopic
call_sign: string
radar_id: string route: list
origin: string
RadarTrack
dest: string Flight
aircraft: string call_sign: string
radar_id: string
route: list
dest: string
aircraft: string RadarTrack
operationX()
operationY()

Automatically Manage Flight Data Processor
Relationships


Custom Filter Example

Secondary Radar

RadarTrack
x: float
y: float
z: float
radar_id: string RadarTrack
operationOne() x: float
operationTwo() y: float

z: float
radar_id: string
operationOne()
operationTwo()

FastFlightView RadarTrackTopic RadarTrackTopic
x: float x: float
image: string y: float y: float
refresh_rate: int FlightViewTopic z: float z: float

SQL Filter
image: string radar_id: string radar_id: string
visible: bool refresh_rate: int RadarTrackTopic
uid: GUID visible: bool
uid: GUID
x: float
y: float
Custom Filter
x: float z: float
radar_id: string
y: float
z: float RadarTrackTopic
x: float
call_sign: string y: float
RadarTrackTopic z: float
display() x: float radar_id: string
call_sign: string
z: float
route: list
radar_id: string origin: string RadarTrack
Flight
dest: string
aircraft: string call_sign: string
Filter based on Region-of-interest radar_id: string route: list
dest: string
SQL Filter aircraft: string RadarTrack
Custom Filter operationX()
operationY()

Automatically Manage Flight Data Processor
Relationships


OpenSplice DDS

...Putting it all
Together

DCPS Application

Application
‣ The application works directly at the
DCPS level TConditioner
cID: int
temp: float
TTempSensor
tID: int
temp: float

humidity: float TRoom humidity: float

‣ When using OO Programming
fan_level: int rID: int rID: int
status: int width: float
rID: int height: float

Languages the Object/Relational length: float
fID: int
TFloor
fID: int
level: int

Impedance Mismatch has to be open: int

manually dealt Content

DDS v1.2
Subscription

Minimum Profile



DLRL Application
Application

TempSensor
temp: float

‣ The DLRL Layer is used to
humidity: float
getTemp()
width: float level: int
1
height: float open: int
1 climate: int

provide a Language Integrated
Conditioner length: float
*
temp: float climate: int set_status()
humidity: float 1 set_climate(); set_climate()
fan_level: int * set_temp() get_level()
set_humidity()

access to DDS data
status: int
setTemp()
setHumidity()
setFanLevel()

start()
stop()

‣ The Designer has great freedom
pause():

DDS v1.2
in deciding how Objects have to Data Local Reconstruction Layer (DLRL)

map to Topics TConditioner
cID: int
TTempSensor
tID: int
temp: float temp: float

‣ Different Object Reconstruction
fan_level: int rID: int rID: int
status: int width: float
rID: int height: float
length: float TFloor

can be created for different fID: int fID: int
level: int
open: int

applications Content

DDS v1.2
Subscription

Minimum Profile



Generic DDS Application
Application
TempSensor
temp: float
humidity: float
getTemp()
width: float level: int
1

‣ In the most general case, different
height: float open: int
Conditioner length: float 1 climate: int
*
temp: float climate: int set_status()
humidity: float 1 set_climate(); set_climate()
fan_level: int * set_temp() get_level()
set_humidity()

portion of the application might rely on
status: int
setTemp()
setHumidity()
setFanLevel()
start()

DLRL or DCPS depending on their stop()
pause():

specific needs Application


‣ DCPS access might be required for
TConditioner TTempSensor
cID: int tID: int
temp: float temp: float

accessing and tuning some specific fan_level: int
status: int
rID: int
rID: int
width: float
height: float
rID: int

length: float TFloor

QoS fID: int fID: int
level: int
open: int

Content

DDS v1.2
Subscription

Minimum Profile



OpenSplice DDS

QoS-Enabled
Pub/Sub

Communicating with Topics, Partitions and Domains

Topic
Topic
Topic
Samples
Samples
Instances Samples
Instances
Instances
121 62
1
21 62
1 22 62
1 22 62
1 23 63
1 23 63
DataReader
DataReader
1 21 62
2 20 61
1 22 62
2 19 60
1 23 63
DataReader DataWriter

2 20 61 2 19 60
DataReader
DataReader 2 20 61 2 19 60 DataWriter
DataWriter
DataReader 3 25 70
3 25 70
3 25 71
25
3 25 71
25
3 25 74
3 25 74
3 26 77
3 26 77
3 26 77
DataWriter
struct TempSensor { 3 25 70 3 25 71
25 3 25 74
int tID;
float temp;
float humidity;
};
#pragma keylist TempSensor tID


Communicating with Topics, Partitions and Domains

Topic
Topic
Topic
Samples
Samples
Instances Samples
Instances
Instances
121 62
1
21 62
1 22 62
1 22 62
1 23 63
1 23 63
DataReader
DataReader
1 21 62
2 20 61
1 22 62
2 19 60
1 23 63
DataReader DataWriter

2 20 61 2 19 60
DataReader
DataReader 2 20 61 2 19 60 DataWriter
DataWriter
DataReader 3 25 70
3 25 70
3 25 71
25
3 25 71
25
3 25 74
3 25 74
3 26 77
3 26 77
3 26 77
DataWriter
struct TempSensor { 3 25 70 3 25 71
25 3 25 74
int tID;
float temp;
Arrows };
float humidity;

show #pragma keylist TempSensor tID

structural
relationship
s, not data- Subscriber Publisher
ﬂows Partition


OMG DDS: The Data Distribution Service for Real-Time Systems

OMG DDS: The Data Distribution Service for Real-Time Systems

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a OMG DDS: The Data Distribution Service for Real-Time Systems

Similar a OMG DDS: The Data Distribution Service for Real-Time Systems (20)

Más de Angelo Corsaro

Más de Angelo Corsaro (20)

Último

Último (20)

OMG DDS: The Data Distribution Service for Real-Time Systems