Upload
prismtech
View
312
Download
3
Tags:
Embed Size (px)
Citation preview
Angelo Corsaro, PhDChief Technology Officer
Data Distribution Service The
Tutorial
DDS is a standard technology for ubiquitous, interoperable, secure, platform independent, and real-time data sharing across network connected devices
DDS in131 Characters
Cop
yrig
ht P
rism
Tech
, 201
5
John Deere’s machinery uses DDS for internal communication as well as for vehicle-to-vehicle coordination
Telemetry Data is constantly sent to a Cloud for preventive maintenance
In this use case VORTEX enables fog computing as well as cloud computing
John Deere Autonomous FarmingSmart farming
Cop
yrig
ht P
rism
Tech
, 201
5
Smart grids and power generation
European air traffic control
DDS is the standard recommended by Eurocontrol/Eurocae for Pan-European
flight data sharing
Cop
yrig
ht P
rism
Tech
, 201
5
DDS provides a Distributed Data Space abstraction where applications can autonomously and asynchronously read and write data enjoying spatial and temporal decoupling
Its built-in dynamic discovery isolates applications from network topology and connectivity details
DDS’ Data Space is completely decentralised
High Level Abstraction
DDS Global Data Space
...
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
Conceptual Model
DDS Global Data Space
...
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
Conceptual Model Actual Implementation
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
TopicDQoS
TopicDQoS
TopicAQoS
DDS Global Data Space
...
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
The communication between the DataWriter and matching DataReaders can be peer-‐to-‐peer exploiting UDP/IP (Unicast and Multicast)or TCP/IP
Data Writer
Data Writer
Data Writer
Data Reader
Data Reader
Data Reader
Data Writer
TopicAQoS
TopicBQoS
TopicCQoS
TopicDQoS
TopicDQoS
TopicDQoS
TopicAQoS
The communication between the DataWriter and matching DataReaders can be “brokered” but still exploiting UDP/IP (Unicast and Multicast)or TCP/IP
Cop
yrig
ht P
rism
Tech
, 201
4DDS is independent from the
- Programming language,
- Operating System
- HW architecture
Platform Independent
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Domain
• DDS data lives within a domain
• A domain is identified with a non negative integer, such as 1, 3, 31
• The number 0 identifies the default domain
• A domain represent an impassable communication plane DDS Domain
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Partitions• Partitions are the mechanism provided by DDS to
organise information within a domain
• Access to partitions is controlled through QoS Policies
• Partitions are defined as strings:• “system:telemetry”
• “system:log”
• “data:row-‐2:col-‐3”
• Partitions addressed by name or regular expressions:• ”system:telemetry”
• “data:row-‐2:col-‐*”Partitions
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Topic
• A Topic defines a domain-wide information’s class
• A Topic is defined by means of a (name, type, qos) tuple, where
• name: identifies the topic within the domain
• type: is the programming language type associated with the topic. Types are extensible and evolvable
• qos: is a collection of policies that express the non-functional properties of this topic, e.g. reliability, persistence, etc.
TopicType
Name
QoS
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Topic and Instances• As explained in the previous slide a topic defines a class/type of information
• Topics can be defined as Singleton or can have multiple Instances
• Topic Instances are identified by means of the topic key
• A Topic Key is identified by a tuple of attributes -- like in databases
• Remarks:
• A Singleton topic has a single domain-wide instance
• A “regular” Topic can have as many instances as the number of different key values, e.g., if the key is an 8-bit character then the topic can have 256 different instances
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Active Floor
• Assume we are building an active floor
• This active floor is made by a matrix of pressure sensors used to detects position, and indirectly movement
• This information is then used by the application that uses the active floor for positioning or entertainment
Cell: (i,j)
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Active Floor
• The generic active cell can be modeled with a topic that has an instance for each value of (i,j). The topic type can be defined as:
• Each cell is now distinguishable and associated with a topic instance
Cell: (i,j)
struct TCell { short row; short column; float pressure; // in kPa }; #pragma keylist TCell row column
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Active Floor
• How can we know when something is on the cell?
• The detection can be based on the difference between the atmospheric pressure, say P0, and the pressure sensed by the cell
• We can model this as a Singleton Topic ReferencePressure defined by the type:
Cell: (i,j)
struct TReferencePressure { float pressure; // in kPa float precision; }; #pragma keylist TReferencePressure
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Active Floor
• Each sensor has associated a topic instance identified by the (row,column) coordinate -- the instance key
• Each instance produces a stream of pressure values that in DDS terms are called samples
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
struct TCell { short row; short column; float pressure; // in kPa }; #pragma keylist Cell row column
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Active Floors on a Building
• Let’s assume now that we have a building that uses active floors to detect presence and movement
• How can we organize the out data model?
0 1 2 3
0
1
2
3
4
Pressure
time
Pressure
time
Pressure
time
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Active Floors on a Building
• The first thing to do is to introduce the third dimension to our cell:
struct TCell { short row; short column; short floor; float pressure; // in kPa }; #pragma keylist TCell row column floor
0 1 2 3
0
1
2
3
4
Pressure
time
Pressure
time
Pressure
time
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Active Floors on a Building
• As we move from a single floor to a building we need to add some more structure to our data
• We can now use:
• A Domain for each Building
• A Partition for each Floor
• A Partition for reference value, i.e. Partition
• A Partition for the configuration information, e.g. how many floors, how many rows/cols per floor
0 1 2 3
0
1
2
3
4
Pressure
time
Pressure
time
Pressure
time
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Active Floors on a Building
• Thus the resulting structure is:
• Floor Partitions:• “building:f-‐1”
• “building:f-‐2”
• ...
• Reference Values Partition:• “building:refvals”
• Configuration Partition:• “building:config”
0 1 2 3
0
1
2
3
4
Pressure
time
Pressure
time
Pressure
time
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataWriter
• A DataWriter (DW) is a strongly typed entity used to produce samples for one or more instances of a Topic, with a given QoS
• Conceptually, the DataWriter QoS should be the same as the Topic QoS or more stringent
• However, DDS does enforce a specific relationship between the Topic and DataWriter QoS
DWTypeTopic
QoS
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataWriter
• The DataWriter controls the life-cycle of Topic Instances and allows to:
• Define a new topic instance
• Write samples for a topic instance
• Dispose the topic instance
DWTypeTopic
QoS
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• A DataReader (DR) is a strongly typed entity used to access and/or consume samples for a Topic, with a given QoS
• Conceptually, the DataReader QoS should be the same as the Topic QoS or less stringent
• However, DDS does enforce a specific relationship between the Topic and DataReader QoS
DRTypeTopic
QoS
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• Depending on its QoS a DataReader may provide access to:
• last sample
• last n samples
• all samples produced since the DataReader was created
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• Depending on its QoS a DataReader may provide access to:
• last sample
• last n samples
• all samples produced since the DataReader was created
n=3
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• Depending on its QoS a DataReader may provide access to:
• last sample
• last n samples
• all samples produced since the DataReader was created
n=3
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• Depending on its QoS a DataReader may provide access to:
• last sample
• last n samples
• all samples produced since the DataReader was created
n=3
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• Depending on its QoS a DataReader may provide access to:
• last sample
• last n samples
• all samples produced since the DataReader was created
n=3
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• Depending on its QoS a DataReader may provide access to:
• last sample
• last n samples
• all samples produced since the DataReader was created
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
n=3
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• Depending on its QoS a DataReader may provide access to:
• last sample
• last n samples
• all samples produced since the DataReader was created
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
n=3
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• Depending on its QoS a DataReader may provide access to:
• last sample
• last n samples
• all samples produced since the DataReader was created
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
n=3
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• Samples are stored in the DataReader Cache
• Samples can be read or taken from the cache
• Samples taken are evicted from the cache
• Samples read remain in the cache and are simply market as read
• The cache content can be selected based on content or state. More on this later...
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
Cop
yrig
ht P
rism
Tech
, 201
5
Anatomy of a DDS Application
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DomainParticipant
• The DomainParticipant is the programming entity that gives access to a DDS domain
• A DomainParticipant is created as follows:
// ISO C++ DDS API int domain_id = 18; auto dp = DomainParticipant(domain_id);
// Java 5 DDS API int domain_id = 18; DomainParticipantFactory dpf = DomainParticipantFactory.getInstance(env)
DomainParticipant dp = dpf.createParticipant(domainId);
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Topic
• Given a DomainParticipant we can define (or discover) Topics within a domain. This can be done as follows:
• As this declaration does not explicitly provide QoS for the Topic, the default QoS will be used
// ISO C++ DDS API auto topic = Topic<TCell>(dp, “Cell”);
// Java 5 DDS API Topic<TCell> topic = dp.createTopic(“Cell”, TCell.class);
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Publisher/Subscriber
• Publisher/Subscriber, through the Partitions they are associated with, define the scope of a write/read operation
• Partitions association is done through the Partition QoS Policy
• This association can be defined as a list of string as well as a list of regular expressions
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Publisher/Subscriber
• Definition of a Publisher/Subscriber in the default partition:
• Definition of a Publisher/Subscriber with Partition settings
// ISO C++ DDS API auto pub = Publisher(dp);
// ISO C++ DDS API auto pub_qos = dp.default_publisher_qos() << Partition(”af:telemetry”); auto pub = Publisher(dp, pub_qos);
// ISO C++ DDS API auto sub = Subscriber(dp);
// ISO C++ DDS API auto sub_qos = dp.default_subscriber_qos() << Partition(”af:telemetry”); auto sub = Subscriber(dp, sub_qos);
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Publisher/Subscriber
• Definition of a Publisher/Subscriber in the default partition:
• Definition of a Publisher/Subscriber with Partition settings
// Java 5 DDS API Publisher pub = dp.createPublisher();
// Java 5 DDS API PublisherQos pubQoS = dp.getDefaultPublisherQos() .with(pf.Partition(”af:telemetry”));
Publisher pub = dp.createPublisher(pubQoS);
// Java 5 DDS API Subscriber sub = dp.createSubscriber();
// Java 5 DDS API SubscriberQos subQoS = dp.getDefaultSubscriberQos() .with(pf.Partition(”af:telemetry”));
Subscriber sub = dp.createSubscriber(subQoS);
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataWriter
• A DataWriter with default QoS can be declared as follows:
// ISO C++ DDS API auto dw = DataWriter<TCell>(pub, topic); // Write the cell c(1,1) using `writer` TCell c11 = {1, 1, 15}; dw.write(c11); // Write the cell c(1,2) using the `operator <<` TCell c12 = {1, 2, 5}; dw << c12;
// Java 5 DDS API DataWriter<TCell> dw = pub.createDataWriter<TCell>(topic); TCell c11 = new TCell(1, 2, 15); dw.write(c11);
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
DataReader
• A DataReader with default QoS can be declared as follows:
// ISO C++ DDS API auto dr = DataReader<TCell>(sub, topic); // Read Samples auto samples = dr.read(); // Do something with it std::for_each(samples.begin(), samples.end(), do_something);
// Java 5 DDS API DataReader<TCell> dr = sub.createDataReader<TCell>(topic);
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Reading Samples
• Samples can be read from the Data Reader History Cache
• The action of reading a sample is non-destructive. Samples are not removed from the cache
DataReader Cache
DataReader
...
DataReader Cache
DataReader
... read
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Taking Samples
• Samples can be taken from the Data Reader History Cache
• The action of taking a sample is destructive. Samples are removed from the cache
DataReader Cache
DataReader
...
DataReader Cache
DataReader
... take
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Sample Selectors
• DDS provides some very flexible mechanisms for selecting the samples to be read/take:
• Content
• Status
• These mechanisms are composable
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Filters and Queries• DDS Filters allow to control what gets
into a DataReader cache
• DDS Queries allow to control what gets out of a DataReader cache
• Filters are defined by means of ContentFilteredTopics
• Queries operate in conjunction with read operations
• Filters and Queries are expressed as SQL where clauses
DataReader Cache
DataReader
...... ... ...
Filter
Query
Application
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Filters
// == ISO C++ DDS API
// Create a Topicauto topic = Topic<ShapeType>(dp, “Circle”);
// Define filter expression and parameters auto filter = Filter(“x < 100 AND y < 200”);
// Define content filtered topic auto cftopic = ContentFilteredTopic<ShapeType>(“CFCircle”, topic, filter)
// Create a DataReader for the content-filtered Topic auto dr = DataReader<ShapeType>(sub,cftopic)
struct ShapeType { string color; long x; long y; long shapesize; }; #pragma keylist ShapeType color
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Filters
// == Java 5DDS API ==
final PolicyFactory pf = runtime.policyFactory(); final DataReaderQos drqos = sub.getDefaultDataReaderQos() .withPolicy ( pf.ContentFilter() .withFilter( new JavaScriptFilter<ShapeType>("data.x > data.y")) );
final DataReader<ShapeType> dr = sub.createDataReader(shape, drqos);
struct ShapeType { string color; long x; long y; long shapesize; }; #pragma keylist ShapeType color
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Query
// == ISO C++ DDS API ==
// Define filter expression and parameters auto dr = DataReader<ShapeType>(sub, topic) val query = Query(dr, “x < 100 AND y < 200”);
dr.select() .content(query) .read();
struct ShapeType { string color; long x; long y; long shapesize; }; #pragma keylist ShapeType color
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Query
// == Java 5 DDS API ==
Filter<ShapeType> filter = new JavaScriptFilter<ShapeType>("data.x > data.y"))
dr.select() .content(filter) .read();
struct ShapeType { string color; long x; long y; long shapesize; }; #pragma keylist ShapeType color
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Instances
• DDS provides a very efficient way of reading data belonging to a specific Topic Instance
• Obviously, one could use queries to match the key’s value, but this is not as efficient as the special purpose instance selector
// == ISO C++ DDS API ==
auto handle = dr.lookup_instance(ShapeType(“RED”, 0, 0, 0));
auto data = dr.select() .instance(handle) .read();
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Sample, Instance, and View State
• The samples included in the DataReader cache have associated some meta-information which, among other things, describes the status of the sample and its associated stream/instance
• The Sample State (READ, NOT_READ) allows to distinguish between new samples and samples that have already been read
• The View State (NEW, NOT_NEW) allows to distinguish a new instance from an existing one
• The Instance State (ALIVE, NOT_ALIVE_DISPOSED, NOT_ALIVE_NO_WRITERS) allows to track the life-cycle transitions of the instance to which a sample belongs
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
State Selector in Action
// == ISO C++ DDS API ==
// Read only new samples auto data = dr.read()
// Read any samples from live instances auto data = dr.select() .state(DataState::any_data()) .read();
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
State Selector in Action
// == Java 5 DDS API ==
// Read only new samples Iterator<Sample<ShapeType>> data = dr.read()
// Read any samples from live instances Iterator<Sample<ShapeType>> data = dr.select() .dataState(sub.createDataState().withAnySampleState()) .read();
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
// == ISO C++ DDS API ==
auto data = dr.select() .content(query) .state(data_state) .instance(handle) .read();
Putting all Together
• Selectors can be composed in a flexible and expressive manner
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Interaction ModelsPolling
•The application proactively polls for data availability as well as special events, such as a deadline being missed, etc. Notice that all DDS API calls, exclusion made for wait operations, are non-blocking
Synchronous Notification
•The application synchronously waits for some conditions to be verified, e.g., data availability, instance lifecycle change, etc.
Asynchronous Notification•The application registers the interest to be asynchronously notified when specific
condition are satisfied, e.g. data available, a publication matched, etc.
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Synchronous Notifications
• DDS provides a mechanism known as WaitSet to synchronously wait for a condition
• Condition can predicate on:
• communication statuses
• data availability
• data availability with specific content
• user-triggered conditions
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
WaitSet// == Java 5 DDS API ==
// Create the waitset WaitSet ws = runtime.createWaitSet();
Subscriber.DataState ds = sub.createDataState();
// Create the condition Condition c = dr.createReadCondition( ds.withAnyViewState() .with(InstanceState.ALIVE) .with(SampleState.NOT_READ));
// Attach the condition ws.attachCondition(c);
// Wait for the condition ws.wait();
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Asynchronous Notifications
• DDS provides a mechanism known as Listeners for asynchronous notification of a given condition
• Listener interest can predicate on:
• communication statuses
• data availability
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Listener Declaration// == ISO C++ DDS API ==
class ShapeListener : public dds::sub::NoOpDataReaderListener<ShapeType> { public: ShapeListener() {}
virtual void on_data_available(dds::sub::DataReader<ShapeType>& dr) { auto samples = dr.read(); std::for_each(samples.begin(), samples.end(), [](const dds::sub::Sample<ShapeType>& sample) { if (sample.info().valid()) // Check if sample contains valid data std::cout << sample.data() << std::endl; }); }
virtual void on_liveliness_changed(dds::sub::DataReader<ShapeType>& the_reader, const dds::core::status::LivelinessChangedStatus& status) { std::cout << ">> Liveliness Changed! " << std::endl; } };
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Listener Registration
// == ISO C++ DDS API ==
auto l = new ShapeListener();
// Create a “nothing” status mask StatusMask mask = StatusMask::none();
// Add the statuses we are interested in. mask << StatusMask::data_available() << StatusMask::liveliness_changed() << StatusMask::liveliness_lost();
// Register the listener with the associated mask dr.listener(l, mask);
Cop
yrig
ht P
rism
Tech
, 201
5
For data to flow from a DataWriter (DW) to one or many DataReader (DR) a few conditions have to apply:
The DR and DW domain participants have to be in the same domain
The partition expression of the DR’s Subscriber and the DW’s Publisher should match (in terms of regular expression match)
The QoS Policies offered by the DW should exceed or match those requested by the DR
Quality of ServiceDomain
Participant
DURABILITY
OWENERSHIP
DEADLINE
LATENCY BUDGET
LIVELINESS
RELIABILITY
DEST. ORDER
Publisher
DataWriter
PARTITION
DataReader
Subscriber
DomainParticipant
offered QoS
Topicwrites reads
Domain Idjoins joins
produces-in consumes-from
RxO QoS Policies
requested QoS
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
QoS DSL
• The ISO C++ and Java 5 APIs provide DSL for dealing with QoS Policies configuration
• The DSL uses language specific idioms, such as fluid interfaces, as well as specific features of the languages
• Policies as well as Entity QoS are immutable — this allows for better safety and object sharing
• Policies are treated as algebraic data types and the DSL provide constructors of each of the cases
• A QoS Provider can now be used to retrieve QoS settings from external sources, e.g. a file, an HTTP server, DDS durability
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
C++ QoS Policy DSL
// == ISO C++ DDS API ==
DataWriterQos dwqos = pub.default_datawriter_qos() << History.KeepLast(10) << Durability.Transient();
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Data Delivery
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Reliability QoS Policy
The Reliability Policy controls the level of guarantee offered by the DDS in delivering data to subscribers
•Reliable. In steady-state, and with no data writer crashes, guarantees that all samples in the DataWriter history will eventually be delivered to all the DataReader
•Best Effort. Indicates that it is acceptable not to retry propagation of samples
QoS Policy Applicability RxO Modifiable
RELIABILITY T, DR, DW Y N
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Data Availability
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
History QoS PolicyThe DataWriter HISTORY QoS Policy controls
the amount of data that can be made available to late joining DataReaders under TRANSIENT_LOCAL Durability
The DataReader HISTORY QoS Policy controls how many samples will be kept on the reader cache
•Keep Last. DDS will keep the most recent “depth” samples of each instance of data identified by its key
•Keep All. The DDS keep all the samples of each instance of data identified by its key -- up to reaching some configurable resource limits
QoS Policy Applicability RxO ModifiableHISTORY T, DR, DW N N
0 1 2 3
0
1
2
3
4
Pressure time
Pressure time
Pressure time
KeepLast(3)
KeepLast(1)
KeepAll
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Durability QoS PolicyThe 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 for late joining data readers
• Transient Local. Data instance availability for late joining data reader is tied to the data writer availability
• Transient. Data instance availability outlives the data writer
• Persistent. Data instance availability outlives system restarts
QoS Policy Applicability RxO ModifiableDURABILITY T, DR, DW Y N
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Data Writer
Data Reader
TopicAQoS
Volatile Durability
• No Time Decoupling
• Readers get only data produced after they joined the Global Data Space
1
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Volatile Durability
• No Time Decoupling
• Readers get only data produced after they joined the Global Data Space
Data Writer
Data Reader
TopicAQoS
Data Reader
1
Late Joiner
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Volatile Durability
• No Time Decoupling
• Readers get only data produced after they joined the Global Data Space
Data Writer
Data Reader
TopicAQoS
Data Reader
1
Late Joiner
22
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Data Writer
Data Reader
TopicAQoS
Transient Local Durability
• Some Time Decoupling
• Data availability is tied to the availability of the data writer and the history settings
11
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Transient Local Durability
• Some Time Decoupling
• Data availability is tied to the availability of the data writer and the history settings
Data Writer
Data Reader
TopicAQoS
Data Reader
1
Late Joiner
11
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Data Writer
Data Reader
TopicAQoS
Data Reader
2
Transient-Local Durability
• Some Time Decoupling
• Data availability is tied to the availability of the data writer and the history settings
1
2
1
12
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Data Writer
Data Reader
TopicAQoS
Transient Durability
• Time Decoupling
• Data availability is tied to the availability of the durability service
1
1
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Data Writer
Data Reader
TopicAQoS
Data Reader
1
Transient Durability
• Time Decoupling
• Data availability is tied to the availability of the durability service
1
Late Joiner
1
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Data Writer
Data Reader
TopicAQoS
Data Reader
2
Transient Durability
• Time Decoupling
• Data availability is tied to the availability of the durability service
1
2
1
1
2
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Data Reader
TopicAQoS
Data Reader
Transient Durability
• Time Decoupling
• Data availability is tied to the availability of the durability service
1
1
2
2
12
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.
Transient Durability
• Time Decoupling
• Data availability is tied to the availability of the durability service
1
Late Joiner
1
Data Reader
TopicAQoS
Data Reader
Data Reader
2
2
12 12
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Soft State
• In distributed systems you often need to model soft-state -- a state that is periodically updated
• Examples are the reading of a sensor (e.g. Temperature Sensor), the position of a vehicle, etc.
• The QoS combination to model Soft-State is the following:
Reliability => BestEffort Durability => Volatile History => KeepLast(n) [with n = 1 in most of the cases] Deadline => updatePeriod LatencyBudget => updatePeriod/3 [rule of thumb] DestinationOrder => SourceTimestamp [if multiple writers per instance]
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Hard State
• In distributed systems you often need to model hard-state -- a state that is sporadically updated and that often has temporal persistence requirements
• Examples are system configuration, a price estimate, etc.
• The QoS combination to model Hard-State is the following:
Reliability => Reliable Durability => Transient | Persistent History => KeepLast(n) [with n = 1 in most of the cases] DestinationOrder => SourceTimestamp [if multiple writers per instance]
Cop
yrig
ht 2
013,
Pris
mTe
ch –
All
Rig
hts
Res
erve
d.C
opyr
ight
201
3, P
rism
Tech
– A
ll R
ight
s R
eser
ved.
Events
• In distributed systems you often need to model events -- the occurrence of something noteworthy for our system
• Examples are a collision alert, the temperature beyond a given threshold, etc.
• The QoS combination to model Events is the following:
Reliability => Reliable Durability => any [depends on system requirements] History => KeepAll [on both DataWriter and DataReader!] DestinationOrder => SourceTimestamp
Cop
yrig
ht P
rism
Tech
, 201
5
State Writer
template <typename T> class StateWriter { public: StateWriter(const std::string& name, int retain = 1, bool persistent = false, int domainId = 0);
void write(const T& data);};
Cop
yrig
ht P
rism
Tech
, 201
5
State Readertemplate <typename T> class StateReader { public: StateReader(const std::string& name, bool persistent = false, int domainId = 0); Maybe<T> get(const T& key);
dds::sub::LoanedSamples<T> get();
std::function<void(StateReader<T>&)> on_change() const;
void on_change(std::function<void(StateReader<T>)> f);};
Cop
yrig
ht P
rism
Tech
, 201
5
StateVector Readertemplate <typename T> class StateVectorReader { public: StateVectorReader(const std::string& name, int retain, bool persistent = false, int domainId = 0);
Maybe<dds::sub::LoanedSamples<T>>
get(const T& key);
dds::sub::LoanedSamples<T> get();
Cop
yrig
ht P
rism
Tech
, 201
5
StateStreamtemplate <typename T> class StateStream { public: StateStream(const std::string& name, std::function<void(const T&)> fun, int retain = 1, bool persistent = false, int domainId = 0); : ~StateStream(); };
Cop
yrig
ht P
rism
Tech
, 201
5
Queue template <typename T> class Queue { public: Queue(const std::string name, int retain = 0, bool persistent = false, int domainId = 0)
void enqueue(const T& data); T peek(const dds::core::Duration timeout = dds::core::Duration::infinite()); T dequeue(const dds::core::Duration timeout = dds::core::Duration::infinite()); void ack(const T& data);};
Cop
yrig
ht P
rism
Tech
, 201
5
Enqueue
template <typename T> class Enqueue { public: Enqueue(const std::string name, int retain = 0, bool persistent = false, int domainId = 0);
void enqueue(const T& data);};
Cop
yrig
ht P
rism
Tech
, 201
5