OMG DDS Tutorial - Part I

OpenSplice DDS
Delivering Performance, Openness, and Freedom

Angelo Corsaro, Ph.D.
Product Strategy & Marketing Manager

OMG DDS Tutorial - Part I
OMG RTESS and DDS SIG Co-Chair
angelo.corsaro@prismtech.com

Motivating Forces
The Standard
Agenda

Architectural Principles
Programming Model
Concluding Remarks

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
Centric Systems Joint Forces
Joint Forces
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


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


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!


DDS vs. Client-Server
Server
Client/Server
Server
Client ‣ Tight Coupling (4W)
Client ‣ Complex Deployment
Server
‣ Inherently One-to-One
Server
‣ Fragile to Fault

Client

Client


Counting the “W’s” of Coupling
Server Client/Server
Server
Client
‣ Tight Coupling (4W)
Client
‣ Complex Deployment
Server ‣ Inherently One-to-One
Server ‣ Fragile to Fault

Client

Client Subscriber
Publisher

DDS Subscriber
‣ Loosely Coupled (1W) Publisher
‣ Plug & Play
‣ Inherently Many-to-Many Subscriber

‣ Fault Resilient
Publisher
Subscriber


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

Data Local Reconstruction Layer (DLRL)

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



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

2 20 61 2 19 60
DataReader
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
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



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

2 20 61 2 19 60
DataReader
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
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

Domain Participant

Domain

QoS Model
‣ QoS-Policies are used to control relevant
properties of OpenSplice DDS entities, Type Matching
QoS matching
such as: QoS QoS QoS QoS QoS QoS QoS

‣ Temporal Properties
‣ Priority
Topic

Name
Publisher Subscriber

‣ Durability ... DataWriter writes Type reads DataReader
...
...
‣ Availability DomainParticipant writes Type reads DataReader DomainParticipant
DataWriter
‣ ... Name

‣ Some QoS-Policies are matched based on
Topic

QoS QoS QoS
a Request vs. Offered Model thus QoS-
enforcement

‣ Publications and Subscriptions match only if the declared vs. requested QoS are compatible
‣ e.g., it is not possible to match a publisher which delivers data unreliably with a subscriber which requires reliability

Sample QoS Policies
QoS Policy Applicability RxO Modiﬁable Type Matching
QoS matching
DURABILITY T, DR, DW Y N Data Availability QoS QoS QoS QoS QoS QoS QoS

DURABILITY SERVICE T, DW N N
Topic
Name

LIFESPAN T, DW - Y ... DataWriter writes Type reads DataReader
...

T, DR, DW N N ...
HISTORY
DomainParticipant DataWriter writes Type reads DataReader DomainParticipant
PRESENTATION P, S Y N Data Delivery Name
Topic
RELIABILITY T, DR, DW Y N
PARTITION P, S N Y QoS QoS QoS

DESTINATION ORDER T, DR, DW Y N

OWNERSHIP T, DR, DW Y N ‣ Rich set of QoS allow to configure
OWNERSHIP DW - Y
STRENGTH several different aspects of data
DEADLINE T, DR, DW Y Y Data Timeliness availability, delivery and timeliness
LATENCY BUDGET T, DR, DW Y Y

TRANSPORT PRIORITY T, DW - Y
‣ QoS can be used to control and
optimize network as well as
TIME BASED FILTER DR - Y Resources
computing resource
RESOURCE LIMITS T, DR, DW N N

USER_DATA DP, DR, DW N Y Conﬁguration
TOPIC_DATA T N Y
GROUP_DATA P, S N Y


Mapping QoS Which properties does QoS controls?

TimeBasedFilter Deadline History

Data Data
Throughput Lifespan Durability
Latency Availability

Ownership
LatencyBudget TransportPriority Ownership
Strength

Control over Latency/Throughput tradeoff
Control over data queueing
Control over data latency
Control over data persistency
Control over data priority
Control over data sources hot-swap

Reliability
OpenSplice DDS provides programmatic
Destination
QoS-driven support for configuring the most
Presentation Data Delivery
Order important properties of data distribution!
Control over data distribution reliability
Control over data ordering
Control over presentation


TimeBasedFilter Deadline

Data
Throughput
Latency

LatencyBudget TransportPriority

Data Timeliness
QoS Policy Applicability RxO Modifiable
DEADLINE T, DR, DW Y Y
LATENCY T, DR, DW Y Y
Data
BUDGET
Timeliness
TRANSPORT T, DW - Y
PRIORITY


Deadline You can’t be later than...

The DEADLINE QoS policy allows to define the maximum inter-arrival time between data samples

QoS Policy Applicability RxO Modifiable QoS matching
DEADLINE T, DR, DW Y Y
QoS QoS QoS

‣ DataWriter indicates that the application QoS Topic
Name
QoS

commits to write a new value at least once

DataWriter writes Type reads DataReader

Publisher ... Subscriber
every deadline period ... ...

‣ writes Type reads DataReader
DataReaders are notified by the DDS when DataWriter

Name

the DEADLINE QoS contract is violated Topic

QoS QoS QoS

QoS matching

Deadline Deadline Deadline Deadline Deadline

Deadline Violation

Latency Budget I need to get there in at most...

The LATENCY_BUDGET QoS policy specifies the maximum acceptable delay from the time the data is written
until the data is inserted in the receiver's application-cache
LATENCY T, DR, DW Y Y
BUDGET
‣ The default value of the duration is zero indicating that the delay
should be minimized QoS matching

‣ This policy is a hint to the DDS, not something that must be QoS QoS QoS

monitored or enforced. QoS Topic QoS
Name


... ...


Name
TBuff Latency Budget = Latency = TBuff +T1+T2+T3 Topic

QoS QoS QoS

QoS matching
T3
T1

T2


Transport Priority VIP Data, stay clear!

TRANSPORT T, DW - Y QoS matching
PRIORITY
QoS QoS QoS

QoS Topic QoS
The TRANSPORT_PRIORITY QoS policy

Name

is a hint to the infrastructure as to how Publisher

Subscriber
... ... ...
to set the priority of the underlying
Type reads DataReader
transport used to send the data. DataWriter writes

Name
Topic

QoS QoS QoS

QoS matching


History

Data
Lifespan Durability
Availability

Ownership
Ownership
Strength

Data Availability
DURABILITY T, DR, DW Y N
DURABILITY T, DW N N
SERVICE Data
Availability
LIFESPAN T, DW - Y
HISTORY T, DR, DW N N


Durability
The DURABILITY QoS controls the data availability w.r.t. late joiners, specifically the DDS provides
the following variants:

‣ Volatile. No need to keep data instances DURABILITY
SERVICE
T, DW N N

for late joining data readers
‣ Transient Local. Data instance availability

QoS matching

for late joining data reader is tied to the QoS QoS QoS

data writer availability QoS Topic QoS

‣ Transient. Data instance availability
Name


outlives the data writer Publisher ... ... ... Subscriber

‣ Persistent. Data instance availability DataWriter writes Type reads DataReader

outlives system restarts Topic
Name

QoS QoS QoS

QoS matching

The DURABILITY_SERVICE QoS provide control over configuration of the service that implements the transient and
persistent durability features

Lifespan For how long will this data be available?

‣ The LIFESPAN QoS policy
LIFESPAN T, DW - Y

allows to control what happens
to stale data QoS matching

‣ It specifies the validity interval QoS QoS QoS

for data written by the QoS Topic
Name
QoS

DataWriter DataWriter writes Type reads DataReader

‣
...
The default validity interval is ...
infinite Name
Topic

QoS QoS QoS

QoS matching


History How many data samples should I keep?

The HISTORY QoS policy controls whether the DDS should deliver only the most recent value, attempt to deliver
all intermediate values, or do something in between. The policy can be configured to provide the following
semantics:

‣ Keep Last. The DDS will only attempt to QoS Policy
HISTORY
Applicability
T, DR, DW
RxO
N
Modifiable
N
keep the most recent “depth” samples of

each instance of data identified by its key QoS matching

‣ Keep All. The DDS will attempt to keep all QoS QoS QoS
the samples of each instance of data
identified by its key. QoS Topic
Name
QoS

‣ On the DataWriter Samples are kept until DataWriter writes Type reads DataReader

delivered to all known subscribers Publisher ... ... ... Subscriber

‣ On the DataReader side samples are kept DataWriter writes Type reads DataReader

until the application “takes” them Topic
Name

QoS QoS QoS

QoS matching


Reliability

Destination
Presentation Data Delivery
Order

Data Delivery
PRESENTATION P, S Y N
PARTITION P, S N Y
DESTINATION T, DR, DW Y N Data Delivery
ORDER
OWNERSHIP T, DR, DW Y N
OWNERSHIP DW - Y
STRENGTH


Reliability
The RELIABILITY QoS indicate the level of guarantee offered by the DDS in delivering data
to subscribers. Possible variants are:

‣ Reliable. In steady-state the RELIABILITY T, DR, DW Y N

middleware guarantees that all

samples in the DataWriter history will QoS matching

eventually be delivered to all the QoS QoS QoS

DataReader
QoS Topic QoS

‣ Best Effort. Indicates that it is DataWriter writes Type
Name

reads DataReader
acceptable to not retry propagation of Publisher ... Subscriber
... ...
any samples

Name
Topic

QoS QoS QoS

QoS matching


Ownership Who owns the data?

The OWNERSHIP QoS specifies whether it is allowed for multiple DataWriters to write the
same instance of the data and if so, how these modifications should be arbitrated. Possible
choices are:
‣ Shared. Multiple writers are allowed to QoS Policy Applicability RxO Modifiable
update the same instance and all the OWNERSHIP T, DR, DW Y N

updates are made available to the reader
QoS matching

‣ Exclusive. Indicates that each instance can QoS QoS QoS

only be owned by one DataWriter, but the
Topic
owner of an instance can change QoS
Name
QoS

dynamically -- due to liveliness changes DataWriter writes Type reads DataReader

...
‣ The selection of the owner is controlled by
DataWriter writes
...
Type reads DataReader
the setting of the OWNERSHIP_STRENGTH Name

QoS policy Topic

QoS QoS QoS

QoS matching


Ownership Strength How strong are you?

The OWNERSHIP_STRENGTH Specifies the value of the “strength” used to arbitrate among
DataWriters that attempt to modify the same data instance
‣ Data instance are identified QoS matching
by the couple (Topic, Key)
QoS QoS QoS

‣ The policy applies only if the

OWNERSHIP is EXCLUSIVE QoS Topic
Name
QoS


... ...
OWNERSHIP DW - Y DataWriter writes Type reads DataReader
STRENGTH
Name
Topic

QoS QoS QoS

QoS matching


Ownership @ Work
‣ A Topic can have Shared or Exclusive Ownership
‣ Exclusively owned Topics can be modified by a single writer
‣ Writer strength is used to coordinate replicated writers

StockQuote
symbol: "MSFT"
StockQuote
StockQuote
name: "Microsoft Corp."
StockQuote
symbol: "GOOG"
symbol: "GOOG"
exchange: "NASD""GOOG"
symbol:
name: "Google Inc."
quote: 33.73
name: "Google Inc."
name: "Google Inc."
exchange: "NASD"
exchange: "NASD"
exchange: "NASD"
StockQuote
StockQuote
StockQuote
quote: 663.97

W1
quote: 663.97"AAPL"
symbol: "AAPL"
quote: 663.97
symbol: "AAPL"
symbol:
name: "Apple Inc."
name: "Apple Inc."
name: "Apple Inc."
exchange: "NASD"
exchange: "NASD"
exchange: "NASD"

R1
quote: 165.37
quote: 165.37
quote: 165.37

STRENGTH=3

StockQuote
symbol: "AAPL"
StockQuote Inc."
name: "Apple
symbol: "GOOG""NASD"
exchange:
name: quote: 165.37
"Google Inc."
StockQuote "NASD"
exchange:
symbol: "MSFT"
quote: 663.97
exchange: "NASD"
quote: 33.73

W1’ R2
STRENGTH=2 StockQuote
symbol: "AAPL"
StockQuote Inc."
name: "Apple
symbol: "GOOG""NASD"
exchange:
name: quote: 165.37
"Google Inc."
StockQuote "NASD"
exchange:
symbol: "MSFT"
quote: 663.97
exchange: "NASD"
quote: 33.73

W2’’ R3

STRENGTH=1


Managing Hot-Swap
‣ A Topic can have Shared or Exclusive Ownership
‣ Exclusively owned Topics can be modified by a single writer
‣ Writer strength is used to coordinate replicated writers

StockQuote

R1
symbol: "AAPL"
name: "Apple Inc."
exchange: "NASD"
quote: 165.37

StockQuote
symbol: "GOOG"
name: "Google Inc."
exchange: "NASD"
quote: 663.97

StockQuote
symbol: "GOOG"
name: "Google Inc."
exchange: "NASD"
quote: 663.97

StockQuote
symbol: "AAPL"
name: "Apple Inc."
exchange: "NASD"
R2
quote: 165.37

StockQuote
StockQuote
StockQuote StockQuote
symbol: "MSFT"
symbol: "MSFT"
symbol: "MSFT" symbol: "GOOG"
exchange: "NASD"
exchange: "NASD" name: "Google Inc."
exchange: "NASD"
quote: 33.73
quote: 33.73
quote: 33.73 exchange: "NASD"
quote: 663.97

StockQuote

R3
symbol: "AAPL"

W2’’
name: "Apple Inc."
exchange: "NASD"
quote: 165.37

STRENGTH=1


OpenSplice DDS

Shared Global Data Space

Shared Global Data Space
Coordination Model
‣ DDS applications are asynchronous and communicate by reading/writing from/to
a Global Data Space
‣ DDS applications communicate by simply addressing items in the Global Data

Space and without any direct knowledge of the parties involved in the production/
consumption of data
Consistency Model
‣ The Shared Global Data Space implemented by DDS, can be configured to
supports at most the “Eventual Consistency Model”
‣ Under an Eventual Consistency Model we are guaranteed that eventually all
application in the system will have a consistent view of the “world”s


Eventual Consistency & R/W Caches
DataReader

DataReader 1 1

2 1 DataWriter
1 1
3 1

2 1 1 2
Topic
DataReader 1 2 2 3
3 1
DataReader Cache 2 2 2 3 3 1
Topic
1 1
DataReader Cache 2 Topic
1
DDS DataWriter Cache
3 1

Topic
DataReader Cache

Under an Eventual Consistency Model, DDS guarantees that all matched
Reader Caches will eventually be identical of the respective Writer Cache

QoS Impacting the Consistency Model
The DDS Consistency Model is a property that can be associated to Topics or further refined by
Reader/Writers. The property is controlled by the following QoS Policies:
‣ DURABILITY
‣ VOLATILE | TRANSIENT_LOCAL | TRANSIENT | PERSISTENT
‣ LIFESPAN

‣ RELIABILITY
‣ RELIABLE | BEST_EFFORT
‣ DESTINATION ORDER
‣ SOURCE_TIMESTAMP | DESTINATION_TIMESTAMP
QoS Policy Applicability RxO Modiﬁable
LIFESPAN T, DW - Y
DESTINATION ORDER T, DR, DW Y N


QoS Impacting the Consistency Model

DURABILITY RELIABILITY DESTINATION_ORDER LIFESPAN
Eventual Consistency VOLATILE RELIABLE SOURCE_TIMESTAMP INF.
(No Crash / Recovery)
Eventual Consistency TRANSIENT_LOCAL RELIABLE SOURCE_TIMESTAMP INF.

(Reader Crash / Recovery)
Eventual Consistency TRANSIENT RELIABLE SOURCE_TIMESTAMP INF.
(Crash/Recovery)
Eventual Consistency PERSISTENT RELIABLE SOURCE_TIMESTAMP INF.
(Crash/Recovery)
Weak Consistency ANY ANY DESTINATION_TIMESTAMP ANY
Weak Consistency ANY BEST_EFFORT ANY ANY
Weak Consistency ANY ANY ANY N


Eventual Consistency @ WorK
Eventual Consistency (Reader TRANSIENT_LOCAL RELIABLE SOURCE_TIMESTAMP INF.
Crash / Recovery)
{A}
{B}
(Crash/Recovery)
Weak Consistency ANY ANY ANY N {J}

S = {A, D}

S1
P = {A, B} B
B

P1 m
S= {A, B, J}
BA A
A F

S2
J
D C
P = {D, C, J}

P2 K
E

S = {A}

S4

Eventual Consistency @ Work
Eventual Consistency (Reader TRANSIENT_LOCAL RELIABLE SOURCE_TIMESTAMP INF.
Crash / Recovery)
{A}
{B}
(Crash/Recovery)
Weak Consistency ANY ANY ANY N {J}

S = {A, D}

S1
B
B
A
m
S= {A, B, J}
A F

S2
J
J
D
D C BA
P = {D, C, J} S= {A, B, D, J}

P2 K
E S3
J
S = {A}

S4
© 2009, PrismTech. All Rights Reserved A

Design Guidelines
‣ For all (non-periodic) Topics for which an eventually consistent model is required use the
following QoS settings:


(Crash / Recovery)

‣ For information produced periodically, with a period P, where P is small enough to be
acceptable as a consistency convergence delay, the following QoS settings will provide an
approximation of the eventual consistency:

Eventual Consistency VOLATILE BEST_EFFORT SOURCE_TIMESTAMP INF.
(Crash / Recovery)


OpenSplice DDS

Topic Used in next section.
Getting the Data
struct Counter {
int cID;
int count;
Read Semantics
};
#pragma keylist Counter cID

Reading Samples
‣ Read iterates over the
available sample instances
1 1 1 2 1 3 1 4
‣ Samples are not removed
2 1 2 2 2 3
from the local cache as
DataReader

3 4 3 5
result of a read
3 1 3 2 3 3
‣ Read samples can be read
Topic again, by accessing the
Samples Read Samples not Read cache with the proper
options (more later)
DataReader Cache


Reading Samples
‣ Read iterates over the
1 1 1 2 1 3 1 4
‣ Samples are not removed
2 1 2 2 2 3
from the local cache as
DataReader

3 1 3 2 3 3 3 4 3 5
result of a read
‣ Read samples can be read
Topic
again, by accessing the
Samples Read Samples not Read cache with the proper
options (more later)
DataReader Cache


Sample, Instance and View States
History Depth = 2

‣ DataReaders are provided with data samples ane
state information allowing to detect relevant
transitions in the life-cycle of data as well as data
writers
DataReader

SampleInfo ‣ Sample State (READ | NOT_READ): Determines
wether a sample has already been read by this
1 1 1 2
DataWriter or not.
2 2 2 3
‣ Instance State (ALIVE, NOT_ALIVE, DISPOSED).
3 1
Determines wether (1) writer exist for the specific
Samples instance, or (2) no matched writers are currently
Topic available, or (3) the instance has been disposed

DataReader Cache
‣ View State (NEW, NOT_NEW). Determines wether
this is the first sample of a new (or re-born) instance

Anatomy of a Read

DDS::ReturnCode_t read(
TSeq& samples,

DDS::SampleInfoSeq& info,
long max_samples,
DDS::SampleStateMask samples_state,
DDS::ViewStateMask views_state,
DDS::InstanceStateMask instances_state)


Reading Data
Example 1 Example 2

TSeq samples; TSeq samples(N);
SampleInfoSeq info; SampleInfoSeq info(N);

reader->read(samples, reader->read(samples,
info, info,
DDS::LENGTH_UNLIMITED, N,

DDS::NOT_READ_SAMPLE_STATE, DDS::NOT_READ_SAMPLE_STATE,
DDS::ANY_VIEW_STATE, DDS::ANY_VIEW_STATE,
DDS::ANY_INSTANCE_STATE); DDS::ANY_INSTANCE_STATE);

// Do something // Do something

reader->return_loan(samples, info); Example 3

reader->read(samples,
info,
N,
DDS::NOT_READ_SAMPLE_STATE,
DDS::NEW_VIEW_STATE,
DDS::ALIVE_INSTANCE_STATE);


OpenSplice DDS

Getting the Data
struct Counter {
int cID;
int count;
Take Semantics
};

Taking Samples
‣ Take iterates over the
1 1 1 2 1 3 1 4
‣ Taken Samples are
2 1 2 2 2 3
removed from the local
DataReader

3 4 3 5
cache as result of a take
3 1 3 2 3 3
‣
Topic

Samples not Taken

DataReader Cache


Taking Samples
1 2 1 3 1 4
2 2 2 3
DataReader

3 2 3 3 3 4 3 5

Topic

Samples not Taken

DataReader Cache


Taking Samples
1 3 1 4
2 3
DataReader

3 3 3 4 3 5

Topic

Samples not Taken

DataReader Cache


Anatomy of a take

DDS::ReturnCode_t take(
TSeq& samples,

DDS::SampleInfoSeq& info,
long max_samples,
DDS::SampleStateMask samples_state,
DDS::ViewStateMask views_state,
DDS::InstanceStateMask instances_state)


OpenSplice DDS

Writing Data
struct Counter {
int cID;
int count;
};

Writing Samples

‣ Samples are written in the
local cache
‣ Writer control the creation 1 1 DataWriter
of instances Topic

‣ The DDS ensures that the
local caches for the
matched DataReader will be Last Sample Written
eventually consistent with
that of the Data Writer DataWriter Cache


Writing Samples

local cache
‣ Writer control the creation 1 1 1 2 DataWriter
of instances Topic



Writing Samples

local cache
‣ Writer control the creation 1 2 1 3 DataWriter
of instances Topic



Anatomy of a write

DDS::ReturnCode_t write(const T& sample,

InstanceHandle_t handle);


Writing Data

writer->write(sample, DDS::HANDLE_NIL);

InstanceHandle_t handle = writer->register_instance(sample);
// ...
writer->write(sample, handle);


OpenSplice DDS

Managing Data
History
struct Counter {
int cID;
int count;
};

How many samples?
History Depth = 1 (DDS Default)

‣ The History QoS Controls the
1 1
number of samples-per-
DataReader 2 1
instance that will be stored by
3 1
the middleware on behalf of a
Topic Reader

‣ Keep Last K. The History QoS
can be set so to always have
History Depth = 5
the latest K samples
1 1 1 2 1 3 1 4 1 5 ‣ Keep All. The History QoS can
2 1 2 2 2 3 2 4 2 5
be set so keep all samples
DataReader 3 3 3 4
produced by the writer and not
3 1 3 2 3 5
yet taken, until resource limits
Topic are not reached


History in Action

History Depth = 1 History Depth = 1
(DDS Default) (DDS Default)
Network
1 1 1 2

DataReader 2 1 1 2 2 3
DataWriter

3 1 2 2 2 3 3 1

Topic Topic

DataReader Cache DataWriter Cache

Note: The Reliability QoS controls wether data is sent reliably, or best-effort, from the
DataWriter to matched DataReaders


History in Action

Network
1 2 1 2

DataReader 2 2 2 3
DataWriter

3 1 2 3 3 1

Topic Topic




History in Action

Network
1 2 1 2

DataReader 2 3 2 3
DataWriter

3 1 3 1

Topic Topic




History in Action

(DDS Default)
Network
1 1 1 2

DataWriter

3 1 2 2 2 3 3 1

Topic Topic




History in Action

(DDS Default)
Network
1 1 1 2 1 2

DataWriter

3 1 2 3 3 1

Topic Topic




History in Action

(DDS Default)
Network
1 1 1 2 1 2

DataWriter

3 1 3 1

Topic Topic




OpenSplice DDS

Application / DDS
Coordination
struct Counter {
int cID;
int count;
};

Application / DDS Coordination
DDS provides three main mechanism for exchanging information with the application

‣ Polling. The application polls from time to time for new data or status changes. The
interval might depend on the kind of applications as well as data

‣ WaitSets. The application registers a WaitSet with DDS and waits (i.e. is suspended)
until one of the specified events has happened.

‣ Listeners. The application registers a listener with a specific DDS entity to be notified
when relevant events occur, such as state changes or


OpenSplice DDS

Putting it All Together
Writing a DDS Application

Steps for Writing a DDS Application
Writing a DDS application can be decomposed in the following few simple steps:
‣ Step#1: Define Topics
‣ Step #2: Identify QoS representing key non-functional invariants for your system
‣ Transport Priority
‣ Deadline
‣ Durability

‣ Step #3: Define Topics / Partition Mapping
‣ Step #4: Identify Topic Readers/Writers
‣ Step #5: Define QoS requirements for Readers/Writers
‣ History
‣ Latency Budget
‣ Auto-Dispose
‣ Transport Priority
‣ Deadline
‣ Step #6: Code-it in your favorite programming language

Making the Hello DDS World
Step #1: Topic definition
‣ We are going to define a simple key-less topic that will carry the name to greet.
module swatch {

struct hello {
string<256> name;
};
#pragma keylist hello

};


Step #2: Topic QoS
‣ Reliability QoS: RELIABLE
‣ Durability QoS: TRANSIENT

module swatch {

struct hello {
string<256> name;
};
#pragma keylist hello

};


Step #3: Topics/Partitions Mapping
‣ swatch::hello will be mapped into the default-partition (thus no action to take)


Step #4: Readers/Writers
‣ A Generic DataReader that will read the topic swatch:: hello
‣ We’ll be able to run as many of this as we want
‣ A Generic DataWriter that will read the topic swatch:: hello

‣ We’ll be able to run as many of this as we want


‣ Step #5: Define QoS requirements for Readers/Writers
‣ Writer:
‣ Inherit TopicQoS, and
‣ No-Auto Dispose

‣ History QoS: Keep Last N
‣ Reader
‣ Inherit TopicQoS, and
‣ History QoS: Keep Last N


Hello World in a Conceptual Picture

1 1 1 1

2 2 2
2

3 3
DataReader

DataWriter

SampleInfo SampleInfo
Network
1 1 1 2 1 1 1 2

2 2 2 2 2 3
2 3

3 1 3 1

Samples Samples

swatch::hello swatch::hello



Visualizing the Strucutre...

Subscriber Default Partition Publisher

Domain Participant

Domain

Step #6: Coding

How many lines of code is going to take
this example?


SIMple Dds == SIMD!
‣ Today we’ll write our DDS application using SIMD
‣ SIMD is a C++ library that takes advantage of C++ Template Meta-
Programming to:
‣ Vastly Improve Productivity
SIMD

‣ Simplify Usage
‣ Automate Resource Management (All DDS Entities are Garbage Collected via Ref-Counting)
‣ Zero Overhead


Hello-pub.cpp (Default QoS)

int main(int argc, char* argv[]) { swatch::hello sample;
if (!parse_args(argc, argv)) std::stringstream ss;
return 1;
for (int i = 0; i < N; ++i) {
// -- init the SIMD runtime ss << i;

simd::Runtime::init(); std::string tmp = ss.str() + "." + message;
ss.str("");
// -- create the DDS Topic sample.name = DDS::string_dup(tmp.c_str());
simd::Topic<swatch::hello> helloTopic("helloTopic"); std::cout << "<<= " << sample.name << std::endl;
writer.write(sample);
// -- create the DDS DataWriter usleep(period*1000);
simd::DataWriter<swatch::hello> writer(helloTopic, }
dwqos); std::cout << "[done]" << std::endl;
return 0; }

Only 3-lines of DDS-Speciﬁc Code Business Logic


Hello-pub.cpp
int main(int argc, char* argv[]) {
if (!parse_args(argc, argv))
return 1;
swatch::hello sample;
// -- init the SIMD runtime
simd::Runtime::init(); std::stringstream ss;

simd::TopicQos tqos; for (int i = 0; i < N; ++i) {
ss << i;
tqos.set_reliable();

tqos.set_transient(); std::string tmp = ss.str() + "." + message;
ss.str("");
// -- create the DDS Topic sample.name = DDS::string_dup(tmp.c_str());
std::cout << "<<= " << sample.name << std::endl;
simd::Topic<swatch::hello> helloTopic("helloTopic",
tqos); writer.write(sample);
usleep(period*1000);
simd::DataWriterQos dwqos(tqos);
dwqos.set_keep_last(history_depth); }
std::cout << "[done]" << std::endl;
dwqos.set_auto_dispose(false);
return 0; }
// -- create the DDS DataWriter Business Logic
simd::DataWriter<swatch::hello> writer(helloTopic,
dwqos);


Hello-sub.cpp (Default QoS)

int main(int argc, char* argv[]) { swatch::helloSeq samples;
if (!parse_args(argc, argv)) DDS::SampleInfoSeq infos;
return 1;
while (true) {
// -- init the SIMD runtime reader.read(samples, infos);

simd::Runtime::init(); for (int i = 0; i < samples.length(); ++i) {
std::cout << "=>> " << samples[i].name
// -- create the DDS Topic << std::endl;
simd::Topic<swatch::hello> helloTopic("helloTopic"); }
if (samples.length() > 0)
// -- create the DDS DataReader std::cout << "--" << std::endl;
simd::DataReader<swatch::hello> reader(helloTopic); reader.return_loan(samples, infos);
usleep(period*1000);
}
return 0;}
Only 3-lines of DDS-Speciﬁc Code
Business Logic


Hello-sub.cpp
int main(int argc, char* argv[]) {
if (!parse_args(argc, argv))
return 1; swatch::helloSeq samples;
// -- init the SIMD runtime DDS::SampleInfoSeq infos;
simd::Runtime::init();
while (true) {
simd::TopicQos tqos; reader.read(samples, infos);

tqos.set_reliable(); for (int i = 0; i < samples.length(); ++i) {
tqos.set_transient(); std::cout << "=>> " << samples[i].name
<< std::endl;
// -- create the DDS Topic }
simd::Topic<swatch::hello> helloTopic("helloTopic", if (samples.length() > 0)
tqos); std::cout << "--" << std::endl;
simd::DataReaderQos drqos(tqos); reader.return_loan(samples, infos);
drqos.set_keep_last(history_depth); usleep(period*1000);
}
// -- create the DDS DataReader return 0;}
simd::DataReader<swatch::hello> reader(helloTopic,
drqos); Business Logic


OpenSplice DDS

Demo!

Concluding Remarks
State of the Art
‣ The OMG DDS Standard uniquely addresses some of
the key requirements for next generation Mission Application
Critical Systems
‣ The OMG DDS is one of the few middleware standard Object/Relational Mapping

defining both API as well as Wire-Protocol, thus

ensuring application portability and interworking Content
‣ The DDS Standard has been recommended/
Subscription

mandated by key administration throughout the world Minimum Proﬁle

as well as adopted by the most challenging Defense Data Centric Publish/Subscribe (DCPS)

programs Real-Time Publish/Subscribe Protocol
Looking Ahead DDS Interoperability Wire Protocol

‣ The DDS Standard is swiftly moving forward to expand UDP/IP
its applicability, simplify its use, and facilitate
integration


Online Resources

http://www.opensplice.com/ http://twitter.com/acorsaro/

emailto:opensplicedds@prismtech.com

http://bit.ly/1Sreg http://opensplice.blogspot.com

http://www.dds-forum.org

http://www.youtube.com/OpenSpliceTube http://portals.omg.org/dds


Data Access Pattern
Coordination Patterns
Backup

Topic Queues
Context
‣ One commonly used technique for implementing distributed real-time embedded systems is to
model applications as FSA, or DFSA (Distributed Finite State Automata)

Problem
‣ One or more DDS applications are implemented as a (D)FSA whose transitions depends on
the totally ordered history of updates for a specific topic
‣ How can we ensure that each application sees exactly the same set of updates in exactly the
same order?


Topic Queues
Assumptions
‣ Single writer exists per Topic Instance
Solution
‣ Represent the state transition events by means of DDS Topics

‣ Topic Instances can be used to identify specific FSA
‣ Ensure that application always use the Take Semantics for getting data.
‣ Ensure that these topics have the following QoS Settings
‣ DURABILITY: TRANSIENT | PERSISTENT
‣ HISTORY: KEEP_ALL
‣ RELIABILITY: RELIABLE
‣ DESTINATION_ORDER: SOURCE_TIMESTAMP


3
2
1
Topic Queues

1
1
1
DDS

Samples not Taken


3
2
1
Topic Queues

1
1
11

3
2

2
DDS

Samples not Taken


Topic Queues

DDS

1 1 1 2 1 3 1 4

2 1 2 2 2 3

3 1 3 2 3 3 3 4 3 5

Samples not Taken


Topic Queues

1

3
2
2

2
2
1

3
2
3

3
3
DDS
1

3

4

4
3

Samples not Taken
5


Topic K-Queues
Context
‣ One commonly used technique for implementing distributed real-time embedded systems is to
model applications as FSA, or DFSA (Distributed Finite State Automata)

Problem
‣ One or more DDS applications are implemented as a (D)FSA whose transitions depends on
the totally ordered history of updates for a specific topic
‣ How can we ensure that each application sees exactly the same set of updates in exactly the
same order?
‣ How can we ensure that misbehaving applications consume an unbounded amount of
memory?


Topic K-Queues
Assumptions
‣ Single writer exists per Topic Instance
Solution Note
‣ Represent the state transition events by means of DDS ‣ K can be dimensioned by considering
Topics the maximum burst of activity that
should be tolerated along with the
‣ Topic Instances can be used to identify specific FSA

average time between state transitions
‣ Ensure that application always use the Take Semantics for ‣ e.g., if I want to tolerate 12 sec of
getting data overload and state transition occur
‣ Ensure that these topics have the following QoS Settings every 4 sec then K=3
‣ HISTORY: KEEP_LAST with DEPTH set to K
‣ If a FSA looses a state transition “resets the state” by
some other means (e.g. DURABILITY SERVICE)


3
2
1

1
1
1
Topic K-Queues

DDS

Samples not Taken



3
2
1

1
1
1
1

3
2
Topic K-Queues

2

2
2
DDS

1
3

Samples not Taken



Topic K-Queues

DDS

1 2 1 3 1 4

2 1 2 2 2 3

3 1 3 2 3 3

Samples not Taken

- One FSA has missed a sample... but does not know it yet.


Topic K-Queues

DDS

1 3 1 4

2 2 2 3

3 2 3 3

Samples not Taken

- One FSA has missed a sample... but does not know it yet.
- It detects this and gets the sample from the DURABILITY SERVICE


Topic Caches

Problem
‣ Distributed applications often have to deal with “Hard State”, meaning state that is
conceptually shared among various elements.
‣ This “Hard State” often needs to be accesses very efficiently, likewise changes in state should

also consistently diffused in a timely manner


Topic Caches
Solution
‣ Represent the “Hard State” by means of DDS Topics
‣ Application should favor the use the Read Semantics for getting data.
‣ Ensure that these topics have the following QoS Settings

‣ HISTORY: KEEP_LAST
Note
‣ Notice that “Hard State” will be eventually consistent for all reader regardless of the number of writers
‣ This technique can be exploited for writing self-stabilizing applications


DataReader

DataReader

3
2
1
DataReader

1
1
1
3
2
1

3
2
1
1
1
1

1
1
1
Topic Caches

2
1

2
2

2
DDS

3

2
3
2
1

2
1
3
2

DataWriter DataWriter


DataReader

DataReader

3
2
1
DataReader

1
2
2
3
2
1

3
2
1
1
2
2

1
2
2
Topic Caches

2
DDS

3

2
3
2
1

2
1
3
2

DataWriter DataWriter


Topic Caches
DataReader
1 2

DataWriter
2 3

3 1
DDS 1 2

2 3

DataReader

1 2

2 3

3 1

DataWriter
3 1

2 2
DataReader

1 2

2 3

3 1 - Notice that one Data Writer has an inconsistent state when compared to the system state.
- This is not hard to cope with, and could be simply solved by matching a reader with the
writer (or using a Coordination Pattern)

Sequencer

Problem
‣ Often occurs in a distributed system that applications need to coordinate and take turn in
performing certain actions.
‣ However DDS does not provide built-in coordination / distributed synchronization

mechanisms. How can this be overcome?

Solution
‣ Define a Sequencer in your system that coordinates access to resources.


Sequencer

Detailed Solution
‣ Define in your system the following Topics:

struct TAccessRequest { struct TAccessGrant {

long resource_guid; long resource_guid;
long request_guid; long request_guid;
time_t timeout; time_t timeout;
}; };
#pragma keylist AccessRequestTopic resource_guid #pragma keylist AccessRequestTopic resrouce_guid

struct TReleaseAccessGrant {
long resource_guid;
long request_guid;
};
#pragma keylist AccessRequestTopic resrouce_guid


Sequencer
Detailed Solution
‣ Make TAccessRequest and TReleaseAccessGrant Topic-Queues (with
DESTINATION_ORDER set to RECEPTION_TIMESTAMP)
‣ Make TAccessGrant a Topic-Cache
‣ Use the following protocol to request/grant/release access

Sequencer (per instance to keep it simpler) Application

while (true) { bool granted = false;
take next sample from TAccessRequest write TAccessRequest
write TAccessGrant while (!granted) {
wait on TReleaseAccessGrant wait on TAccessGrant
} if TAccessGrant == myTAccessGrant
granted = true;
}
// Do Critical Section
write TReleaseAccessGrant

Sequencer @ Work
Sequencer
Reader
TAccessRequest TAccessGrant TReleaseAccessGrant
Writer

DDS
App-10 App-5

TAccessGrant TReleaseAccessGrant TAccessRequest TAccessGrant TReleaseAccessGrant
TAccessRequest


Sequencer @ Work
Sequencer
Reader
Writer

DDS
App-10 App-5

TAccessRequest

1 10
2 5


Sequencer @ Work
Sequencer
Reader
Writer
1 10

2 5

DDS
App-10 App-5

TAccessRequest

1 10
2 5


Sequencer @ Work
Sequencer
Reader
Writer
1 10

2 5

DDS
App-10 App-5

TAccessRequest
1 10
1 10
1 10
2 5
2 5 2 5


Sequencer @ Work
Sequencer
Reader
Writer
1 10

2 5

DDS
App-10 App-5

TAccessRequest
1 10
1 10
1 10 1 10
2 5
2 5 2 5


Sequencer @ Work
Sequencer
Reader
Writer
1 10 1 10

2 5

DDS
App-10 App-5

TAccessRequest
1 10
1 10
1 10 1 10
2 5
2 5 2 5


Sequencer @ Work
Sequencer
Reader
Writer
1 -1

2 5

DDS
App-10 App-5

TAccessRequest
1 10
1 10 1 5
1 10 1 10
2 5
2 5 2 5
3 10
3 5


Sequencer @ Work
Sequencer
Reader
Writer
1 5 1 -1

2 5

3 5 3 10

DDS
App-10 App-5

TAccessRequest
1 -1
1 -1 1 5
1 10 1 10
2 5
2 5 2 5
3 10
3 5


Sequencer @ Work
Sequencer
Reader
Writer
1 5

2 5

3 10 3 5

DDS
App-10 App-5

TAccessRequest
1 -1
1 -1 1 5
1 10 1 10
2 5
2 5 2 5
3 10
3 5


Sequencer @ Work
Sequencer
Reader
Writer
1 5

2 5

3 10 3 5

DDS
App-10 App-5

TAccessRequest
1 5
1 -1 1 5
1 10 1 10
2 5
2 5 2 5
3 10
3 5
3 5 3 5


Barriers

Problem
‣ Often occurs in a distributed system that applications need to reach a common step in
computation before proceeding.
‣ This is required for distributed application creating software pipelines, or even to ensure

proper state evolution of the distributed system.
‣ However DDS does not provide built-in coordination / distributed synchronization
mechanisms. How can this be overcome?

Solution
‣ Use Barriers in your system to coordinate application progress.


Barriers

Detailed Solution
‣ Define in your system the following Topics:

struct TBarrier { struct TBarrierCondition {
long computation_guid; long computation_guid;
long task_guid; long status;
long status; long cardinality;
}; };
#pragma keylist Barrier computation_guid task_guid #pragma keylist Barrier computation_guid


Barriers
Detailed Solution
‣ Make TBarrier and TBarrierCondition a Topic-Cache
‣ Use the following protocol to request/grant/release access
Application

// Do Computation

// Notify others
write Barrier

wait for BarrierCondition.cardinality
Barrier instances to have the proper
Barrier.status

// Barrier has been passed...
// Take next computational step


Barriers @ Work
App-7 Reader
Coordinator TBarrierCondition TBarrier
Writer
1 10 0xF1
TBarrierCondition 1 0xFF 3

1 7 0xF1
1 0xFF 3 TBarrier

1 5 0xF1
1 7 0xF1

App-10 DDS App-5
TBarrierCondition TBarrier TBarrierCondition TBarrier
1 10 0xF1 1 10 0xF1
1 0xFF 3 1 0xFF 3

1 7 0xF1 1 7 0xF1
TBarrier TBarrier
1 5 0xF1 1 5 0xF1
1 10 0xF1 1 5 0xF1

Barriers @ Work
App-7 Reader
Writer
1 10 0xF1

1 7 0xFF
1 0xFF 3 TBarrier

1 5 0xF1
1 7 0xFF

App-10 DDS App-5
1 10 0xF1 1 10 0xF1
1 0xFF 3 1 0xFF 3

1 7 0xF1 1 7 0xF1
TBarrier TBarrier
1 5 0xF1 1 5 0xF1
1 10 0xF1 1 5 0xF1

Barriers @ Work
App-7 Reader
Writer
1 10 0xF1

1 7 0xFF
1 0xFF 3 TBarrier

1 5 0xF1
1 7 0xFF

App-10 DDS App-5
1 10 0xF1 1 10 0xF1
1 0xFF 3 1 0xFF 3

1 7 0xFF 1 7 0xFF
TBarrier TBarrier
1 5 0xF1 1 5 0xF1
1 10 0xF1 1 5 0xF1

Barriers @ Work
App-7 Reader
Writer
1 10 0xF1

1 7 0xFF
1 0xFF 3 TBarrier

1 5 0xF1
1 7 0xFF

App-10 DDS App-5
1 10 0xF1 1 10 0xF1
1 0xFF 3 1 0xFF 3

1 7 0xFF 1 7 0xFF
TBarrier TBarrier
1 5 0xF1 1 5 0xFF
1 10 0xF1 1 5 0xFF

Barriers @ Work
App-7 Reader
Writer
1 10 0xF1

1 7 0xFF
1 0xFF 3 TBarrier

1 5 0xFF
1 7 0xFF

App-10 DDS App-5
1 10 0xF1 1 10 0xF1
1 0xFF 3 1 0xFF 3

1 7 0xFF 1 7 0xFF
TBarrier TBarrier
1 5 0xFF 1 5 0xFF
1 10 0xF1 1 5 0xFF

Barriers @ Work
App-7 Reader
Writer
1 10 0xF1

1 7 0xFF
1 0xFF 3 TBarrier

1 5 0xFF
1 7 0xFF

App-10 DDS App-5
1 10 0xFF 1 10 0xF1
1 0xFF 3 1 0xFF 3

1 7 0xFF 1 7 0xFF
TBarrier TBarrier
1 5 0xFF 1 5 0xFF
1 10 0xFF 1 5 0xFF

Barriers @ Work
App-7 Reader
Writer
1 10 0xFF

1 7 0xFF
1 0xFF 3 TBarrier

1 5 0xFF
1 7 0xFF

App-10 DDS App-5
1 10 0xFF 1 10 0xFF
1 0xFF 3 1 0xFF 3

1 7 0xFF 1 7 0xFF
TBarrier TBarrier
1 5 0xFF 1 5 0xFF
1 10 0xFF 1 5 0xFF

Leader Election
Problem
‣ Several distributed algorithms require some form of leader
‣ Problems requiring a leader, can be addressed using the Sequencer Pattern
‣ However, what if the sequencer crashes?

Solution
‣ Use the DDS OWNERSHIP_STRENGH as a mechanism to do leader election via DDS

Observation
‣ The basic Leader Election functionality provided by DDS can be used to easily replicate service
implementation such as those of the Sequencer
‣ If the leader is stateful, its state should be stored within DDS


OMG DDS Tutorial - Part I

In this document

More Related Content

What's hot

Viewers also liked

Similar to OMG DDS Tutorial - Part I

More from Angelo Corsaro

Recently uploaded

OMG DDS Tutorial - Part I