DDS: The IoT Data Sharing Standard

DDS
The IoT Data Sharing Standard
Angelo
Corsaro,
PhD
Chief
Technology
Officer
PrismTech
OMG
DDS
Co-‐Chair
OMG
Architectural
Board
angelo.corsaro@prismtech.com

Copyright PrismTech, 2014
The DDS Standard
Introduced in 2004, DDS is an Object
Management Group (OMG) Standard for
efficient, secure and interoperable, platform-and
programming-language independent
data sharing
DDS standardises:
- Programming API
- Interoperable wire-protocol
- Extensible Type System
- Data Modeling
- Security Framework
- Remote Procedure Call
*
*
(*) Under Finalisation

Higher Level Abstraction
Provides a Distributed Data Space
abstraction where applications can
autonomously and asynchronously
read and write data
Its built-in dynamic discovery
isolates applications from network
topology and connectivity details
QoS
QoS
...
QoS
QoS
DDS Global Data Space
Data
Writer
Data
Writer
Data
Writer
Data
Reader
Data
Reader
Data
Reader
Data
Reader
Data
Writer
TopicA
TopicB
TopicC
TopicD

Data Centricity
DDS supports the definition of
Common Information Models. These
data models define the system’s
Lingua Franca
DDS types are extensible and
evolvable, thus allowing incremental
updates and upgrades

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.
QoS
QoS
QoS
QoS
Name
QoS
Topic
Type
...
TopicA
TopicB
TopicC
TopicD

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

Content Awareness
DDS “knows” about
application data types
and uses this
information provide
type-safety and content-based
routing
struct
TemperatureSensor
{
@key
long
sid;
float
temp;
float
hum;
}
sid temp hum
101 25.3 0.6
507 33.2 0.7
913 27,5 0.55
1307 26.2 0.67
“temp
>
25
OR
hum
>=
0.6”
sid temp hum
507 33.2 0.7
1307 26.2 0.67
Type
TempSensor

QoS Policies
DDS provides a rich set of QoS-Policies
to control local as well as
end-to-end properties of data
sharing
Some QoS-Policies are matched
based on a Request vs. Offered
(RxO) Model
DURABILITY
HISTORY
LIFESPAN
LIVELINESS
DEADLINE
LATENCY BUDGET
TRANSPORT PRIO
TIME-BASED FILTER
RESOURCE LIMITS
USER DATA
TOPIC DATA
GROUP DATA
OWENERSHIP
OWN. STRENGTH
DW LIFECYCLE
DR LIFECYCLE
ENTITY FACTORY
DEST. ORDER
PARTITION
PRESENTATION
RELIABILITY
RxO QoS Local QoS

QoS Model
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
Domain
Participant
joins joins
Domain Id
produces-in consumes-from
RxO QoS Policies
DURABILITY
DEST. ORDER
RELIABILITY
LATENCY BUDGET
DEADLINE
OWENERSHIP
LIVELINESS
Publisher
DataWriter
PARTITION
Domain
Participant
Subscriber
DataReader
offered
QoS
writes reads
Topic
requested
QoS

Data Delivery
Data Delivery QoS Policies provide
control over:
who delivers data
where data is delivered, and
how data is delivered
Reliability
Ownership Ownership
Presentation
Destination
Partition Order
Strength
Data Delivery

Data Availability
Data Availability QoS Policies provide
control over data availability with
respect to:
Temporal Decoupling (late Joiners)
Temporal Validity
History
Lifespan Data Availability Durability

Temporal Properties
Several policies provide control over
temporal properties, specifically:
Outbound Throughput
Inbound Throughput
Latency
TimeBasedFilter
[Inbound]
Throughput
[Outbound]
Deadline
Latency
TransportPriority
LatencyBudget

Cloud and Fog/Edge Computing
DDS supports both the
Cloud and the Fog
Computing Paradigm
DDS natively supports:
- Device-to-Device
Communication
- Device-to-Cloud
Communication
Device-to-Device
Communication
Fog Computing
Cloud Computing
Fog Computing
Cloud-to-Cloud
Communication
Fog Computing
Device-to-Cloud
Communication
Device-to-Device
Communication
Fog-to-Cloud
Communication

Support for fine grained
access control
Support for Symmetric and
Asymmetric Authentication
Standard Authentication,
Access Control, Crypto, and
Logging plug-in API
Security
Arthur Dent
Arthur Dent
Ford Prerfect
Zaphod Beeblebrox
Trillian
Marvin
A(r,w), B(r)
A(r,w), B(r,w), X(r)
*(r,w)
A(r,w), B(r,w), C(r,w)
*(r)
Ford Prerfect
Zaphod Beeblebrox
Trillian
Marvin
A
B
A,B
X
*
*
A,B,C
Identity Access Rights
Sessions are authenticated
and communication is
encrypted
Only the Topic included as
part of the access rights are
visible and accessible

Platform Independent
DDS is independent from the
- Programming language,
- Operating System
- HW architecture

Chatting in Scala
import dds._
import dds.prelude._
import dds.config.DefaultEntities._
object Chatter {
def main(args: Array[String]): Unit = {
val topic = Topic[Post]("Post")
val dw = DataWriter[Post](topic)
dw.write(new Post(“kydos”,”Using VORTEX.. It's pretty cool!”));
}
}

Chatting in Scala
import dds._
import dds.prelude._
import dds.config.DefaultEntities._
object ChatLog {
def main(args: Array[String]): Unit = {
val topic = Topic[Post]("Post")
val dr = DataReader[Post](topic)
dr listen {
case DataAvailable(_) => dr.read.foreach(println)
}
}
}

Chatting in C++
#include <dds.hpp>
int main(int, char**) {
DomainParticipant dp(0);
Topic<Post> topic(“Post”);
Publisher pub(dp);
DataWriter<Post> dw(dp, topic);
dw.write(Post(“kydos”,”Using VORTEX.. It's pretty cool!”));
dw << Post(“kydos”,”Using operator << to post!”);
return 0;
}

Chatting in C++
#include <dds.hpp>
int main(int, char**) {
DomainParticipant dp(0);
Topic<Post> topic(“Post”);
Subscriber sub(dp);
DataReader<Post> dr(dp, topic);
LambdaDataReaderListener<DataReader<Post>> lst;
lst.data_available = [](DataReader<Post>& dr) {
auto samples = data.read();
std::for_each(samples.begin(), samples.end(), [](Sample<Post>& sample) {
std::cout << sample.data() << std::endl;
}
}
dr.listener(lst);
return 0;
}

Advanced Message Queueing Protocol (AMQP)
Originally defined by the AMQP consortium as a
messaging standard addressing the Financial
and Enterprise market
AMQP is an OASIS standard that defines an
efficient, binary, peer-to-peer protocol for for
transporting messages between two processes
over a network. Above this, the messaging layer
defines an abstract message format, with
concrete standard encoding
https://www.oasis-open.org/committees/amqp/

Constrained Application Protocol (CoAP)
CoAP is an IETF RFC defining a transfer protocol for constrained
nodes and constrained (e.g., low-power, lossy) networks, e.g. 8-bit
micro-controllers with small amounts of ROM and RAM, connected
by Low-Power Wireless Personal Area Networks (6LoWPANs).
The protocol is designed for machine-to-machine (M2M) applications
such as smart energy and building automation.
CoAP provides a request/response interaction model between application endpoints,
supports built-in discovery of services and resources, and includes key concepts of the Web
such as URIs and Internet media types.
CoAP is designed to easily interface with HTTP for integration with the Web while meeting
specialised requirements such as multicast support, very low overhead, and simplicity for
constrained environments.

Message Queueing Telemetry Transport (MQTT)
MQTT was defined originally by IBM in
the mid 90’s as a lightweight protocol for
telemetry
MQTT supports a basic publish/subscribe
abstraction with three different level of
QoS
MQTT has recently gained much
attention as a potential candidate for
data sharing in the IoT

Qualitative Comparison
Transport Paradigm Scope Discovery
Content
Awareness
Data
Centricity
Security
Data
Prioritisation
Fault
Tolerance
AMQP TCP/IP
Point-to-
Point
Message
Exchange
D2D
D2C
C2C
No None Encoding TLS None Impl. Specific
CoAP UDP/IP
Request/
Reply
(REST)
D2D Yes None Encoding DTLS None Decentralised
DDS
UDP/IP
(unicast + mcast)
TCP/IP
Publish/
Subscribe
Request/
Reply
D2D
D2C
C2C
Yes
Content-
Based
Routing,
Queries
Encoding,
Declaration
TLS, DTLS,
DDS
Security
Tranport
Priorities
Decentralised
MQTT TCP/IP
Publish/
Subscribe
D2C No None Undefined TLS None
Broker is the
SPoF
[Ref: A Comparative Study of Data-Sharing Standards for the Internet of Things, Cutter Journal, Dec 2014
]

CIoT/IIoT Data Sharing Requirements
Efficient and scalable Data
Sharing is a key
requirement of practically
any IoT system
The degree of performance
and fault-tolerance
required by the data
sharing platform varies
across Consumer and
Industrial Internet on
Things applications
Fog Computing support is
key for IIoT
High Individual Data Rates
High Aggregated Data Volumes
Low Latency
Temporal Determinism
Device-2-Device (D2D) Comms
Device-2-Cloud (D2C) Comms
Cloud-2-Cloud (C2C) Comms
Bandwidth Efficiency
Fault-Tolerance
Transport-Level Security
Data-Level Security
CIoT IIoT
0,00 0,25 0,50 0,75 1,00
[Ref: A Comparative Study of Data-Sharing Standards for the Internet of Things, Cutter Journal, Dec 2014
]
Relative Importance

IoT Standard Fitness
Scoring the various IoT
candidates agains the data-sharing
requirements shows
that DDS and AMQP are those
that best address IoT needs
AMQP
CoAP
DDS
MQTT
CIoT Fitness IIoT Fitness
0,0% 25,0% 50,0% 75,0% 100,0%
[Ref: A Comparative Study of Data-Sharing Standards for the Internet of Things,
Cutter Journal, Dec 2014
]

Tech Mythology
MQTT is very wire efficient. Probably the most wire-efficient
IoT data sharing standard

DDS & MQTT Wire Efficiency
MQTT encodes the topic name on
every data message, as a result its
wire-efficiency linearly degrades
on the topic name length — which
is usually greater several tens of
bytes
DDS has a predictable protocol
overhead. Furthermore, when
running DDS in streaming mode
over TCP/IP the protocol
efficiency can be further improved
Protocol Overhead
Topic Name Length
300
225
150
75
0
MQTT
DDS
DDS Streaming
8 16 32 64 128 256
Size (bytes)
[Ref: A Comparative Study of Data-Sharing Standards for the Internet of Things,
Cutter Journal, Dec 2014
]

Protocols Overhead Analysis
Message Size (bytes) IPv4 Headers
(bytes)
Total Size
(bytes)
MQTT
(QoS = 0)
(2 to 5) + 2 + length(TopicName) + length(Payload) IP: 20-40
TCP: 20-40
min = 20 + 20 + 4 + length(TopicName) + length(Payload)
max = 40 + 40 + 7 + length(TopicName) + length(Payload)
DDS 44 + length (Payload) IP: 20-40
UDP: 8
min = 20 + 8 + 44 + length(Payload)
max = 40 + 8 + 44 + length(Payload)
DDS
Streaming
24 + length (Payload) IP: 20-40
TCP: 20-40
min = 20 + 20 + 24 + length(Payload)
max = 40 + 40 + 24 + length(Payload)

DDS Enables the IoT

DDS: The IoT Data Sharing Standard

More Related Content

What's hot

Viewers also liked

Similar to DDS: The IoT Data Sharing Standard

More from Angelo Corsaro

Recently uploaded

DDS: The IoT Data Sharing Standard