An adaptable DDS solution for wireless sensor networks

DDOOPPSSYY
ggrroouupp
PPrrooff.. DDrr.. RR.. KKrrööggeerr
KKaaii BBeecckkmmaannnn
MMaarrccuuss TThhoossss
{{ffiirrsstt..ssuurrnnaammee}}@@hhss--rrmm..ddee
LLaabboorr ffüürr VVeerrtteeiillttee SSyysstteemmee
DDiissttrriibbuutteedd SSyysstteemmss LLaabb
hhttttpp::////wwwwwwvvss..ccss..hhss--rrmm..ddee
sDDS
An adaptable DDS Solution
for Wireless Sensor Networks
Kai Beckmann
Distributed Systems Lab
RheinMain University of Applied Sciences
RTI Connext Conference, London, 08.10.2014

08.10.2014, RRTTII CCoonnnneexxtt CCoonnffeerreennccee KKaaii BBeecckkmmaannnn 22 DDOOPPSSYY
ggrroouupp
Personal Introduction
● RheinMain University of Applied Sciences, Wiesbaden,
Germany
● Distributed Systems Lab (headed by Prof. Dr. Kröger)
– Management of Distributed Applications
– Embedded Systems, Industrial automation
● 2010 M.Sc. in computer sciences
● Research associate, Ph.D. student and assistant lecturer
● Interests:
● Application of distributed and embedded systems
● Middleware (esp. OMG Data Distribution Service)
● Wireless sensor networks
● Application of model-driven software development in
embedded systems
● Model-based software testing

QoS?
ggrroouupp
Motivation
Wireless Sensor Networks
Sensor-Actor-Networks
Automation
Often Data-Centric

ggrroouupp
Problems with WSN
● Requirements
● Cheap
● Limited resources
● Low energy consumption
● Heterogeneity
● Hardware architectures
● Network technologies / protocols / standards
● Software / middleware
● Interoperability
● Proprietary products, different standards
● No consolidation so far
● Often IP as compromise
● DDS an approach?

Wireless transport
IEEE 802.15.4
127 byte frame size
8 bit uC
8 kB RAM
128 kB Flash
Finite energy source
32 bit ARM
64 kB RAM
4 GB Flash
Wall-Socket
dynamic node
ggrroouupp
DDS for WSN - problems
● Need for customised DDS functionality
32 bit ARM
2 GB RAM
*nix OS
Temperatur sensor
➔ publisher
Switch sensor
➔ publisher
Movement sensor
➔ publisher
➔ router
Controllable Socket
➔ publisher
➔ subscriber
➔ router
static link

ggrroouupp
Our Approach: sDDS
● sensornetwork DDS (sDDS)
● Minimal individual customisable DDS solution
● DDS API conform
● Model-driven Software Development (MDSD) process
● WSN-System / Structure
● WSN-DDS-Application
● WSN-Node
● DDS middleware adaptation
● Tailoring of functionality of modules to be deployed
● Supporting heterogeneous middleware nodes
● Exploit existing target facilities
● SNPS protocol specialised for WSN environment

DSL
DDS
UML
Profile
ggrroouupp
MDSD Tailoring Process
HW
Spec
Deployment
Topics
QoS
Application
Requirements
● DDS func.
● QoS
DSL
DSML
DSL
DSL
IDL
PIM
PSM
Optimisation
Templates
Code

ggrroouupp
sDDS - Features
● Extensible MDSD process
● Eclipse environment (EMF, Xtext), with alternative
lightweight python scripts
● Proof-of-concept realisation
● Many optimisations, customisations possible
● Integration of other models, specifications
● Platform independent, easy to port
● Plain C
● Abstract interfaces for system and network
● Fast integration of new platforms (Contiki: 2 weeks only, by
undergrad student)
● Small footprint
● 20 kB for static routing with 2 - 4 topics

● Reliable Transport
● Dynamic Discovery
ggrroouupp
Problem - Network
● Heterogeneity
● Different Subsets of DDS
● Still need for cooperation
● Special layer 1-3 protocols
● Frame sizes
● Routing
● Energy consumption
● Transmitting data
expensive
– Amount of data
– Transceiver on/of
● Natural Broadcast
● Limited resources on
nodes
● Best Effort
● Only Publish
● Static link
● Static link

system protocol
Enterprise DDS RTPS
ggrroouupp
Protocol SNPS
● Sensor-Network Publish-Subscribe (SNPS)
● Influenced by RTPS
● Small footprint, small frame sizes, limited bandwidth
● Aim: Low average protocol overhead
● Data aggregation even for different receivers
● Utilises radio network features
WSN
sDDS SNPS

MMeessssaaggee
ggrroouupp
SNPS - Structure
VVeersrsioionn
SSuubbMMssggCCoouunnt t
1
1
1...*
SSuubbMMeessssaaggee
parameter: 4bit
type: 4bit
EExxtetennddeeddSSuubbMMeessssaaggee
extType: 4bit
type = extSubMsg_t
SSuupppplelemmeenntStSuubbMMeessssaaggee
● Small atomic information
units
● Submessage
● Sequential processing
● Self-description and
implicit structure
● Skipping unknown parts
● Small protocol footprint
● Different classes of sizes
● From frequency of use
● “Squeeze” as much
information into a byte as
possible

SSuubbMMeessssaaggee
DDoommaainin
TTooppicic DDaatata
EExxtetennddeeddSSuubbMMeessssaaggee
PPaayyloloaadd
Handshaking
Ack SSeeqqNNr r Ack NNaacckk
Data Addressing
EExxtTtTooppicic
ggrroouupp
SNPS – Data transmission
● Addressing => Domain, Topic
● Data => header for payload
● Handshaking => Ack, Nack, SeqNr (different sizes)
● Sequentially assembled state used for interpretation

Data
reader
Subscriber
Data
writer
Publisher
Global data space (domain α)
Data
writer
Topic A
Publisher
Data
reader
ggrroouupp
Example – Data Transmission
● SNPS protocol semantics limited to data transmission
● Subscription etc. handled at DDS level
– BuiltIn-Topics
● Realisation is the task of the middleware
Subscriber
Topic B Topic C
Domain
participant
Domain
participant
Domain
participant
Node1 Node2 Node3
Data
reader
Data
writer

Data
reader
Subscriber
Data
writer
Data
writer
Topic A
Publisher
Data
reader
ggrroouupp
● Node 1 publishes data for topic A and B
● Node 2 needs reliable transmission, node 3 does not
● SNPS message of node 1:
Publisher
Subscriber
Topic B Topic C
Domain
participant
Domain
participant
Domain
participant
Node1 Node2 Node3
Data
reader
Data
writer
Version No. of
SubMsgs
Domain
α
Topic
A
Data
1
Payload
1
Topic
B
Data
2
Payload
2 SeqNr

Topic B Topic C
Data
reader
Subscriber
Data
writer
Publisher
Domain
participant
Data
writer
Topic A
Publisher
Data
reader
Subscriber
Domain
participant
ggrroouupp
● Node 3 needs only topic B
● Skipping part related to topic A
● Processing data of topic B, skipping SeqNr and done
Domain
participant
Node1 Node2 Node3
Data
reader
Data
writer
Version No. of
SubMsgs
Domain
α
Topic
A
Data
1
Payload
1
Topic
B
Data
2
Payload
2 SeqNr

Data
reader
Subscriber
Publisher
Data
writer
Topic A
Publisher
Data
reader
ggrroouupp
● Node 2 needs only topic B as well
● Node 2 processes data of topic B
● Acknowledgement required
Data
writer
Subscriber
Topic B Topic C
Domain
participant
Domain
participant
Domain
participant
Node1 Node2 Node3
Data
reader
Data
writer
Version No. of
SubMsgs
Domain
α
Topic
A
Data
1
Payload
1
Topic
B
Data
2
Payload
2 SeqNr

Topic B Topic C
Data
reader
Subscriber
Data
writer
Publisher
Domain
participant
Data
writer
Topic A
Publisher
Data
reader
Subscriber
Domain
participant
ggrroouupp
● Node 2 publishes data for topic C
● And an acknowledgement for topic B
● Node 1 ignores topic C and processes the Ack
Domain
participant
Node1 Node2 Node3
Data
reader
Data
writer
Version No. of
SubMsgs
Domain
α
Topic
C
Data
1
Payload
1
Topic
B ACK SeqNr

ggrroouupp
SNPS – Message Sizes
Version No. of
SubMsgs
Domain
α
Topic
A
Data
1
Payload
1
Data
2
Payload
2
Topic
B
Data
3
Payload
3
Header
Minimum Submessage Sequence
Size: 5 + [payload] Bytes Same Topic:
1 + [payload] Bytes
Different Topic:
2 + [payload] Bytes
● Minimum: Header, Domain, Topic, Data
● Data aggregation in one message adds little overhead
● Assumption:
● Switching transceiver on and off => base cost of energy
● Protocol layer 1, 2 and 3 overhead is significant too
● The overhead of the additional data is acceptable

ggrroouupp
sDDS - Status
● Development system: Linux and UDP/IP
● Target systems
● TI SoC CC2430
● Atmel Atmega128 platform
● Transports
● UDP/IP
● 6LoWPAN (on Contiki OS)
● ZigBee Layer 3 (TI zStack)
● First concepts for CAN
● Work in Progress -> limited support of DDS functionality
● Used in an Ambient Assisted Living (AAL) research
project and university courses

ggrroouupp
sDDS - Future Work
● Currently funded by small internal research project
● Clean up, documentation, integration of functionality
● Aim: Publish as Open Source within next year
● Rework MDSD process
● Functionality
● Dynamic discovery
● QoS
● History on qualified nodes
● Connect WSN to “normal” DDS
● SNPS integration in RTI Connext DDS
● Vertical integration
● New application fields: Industry 4.0, IoT
● Base for new research projects

ggrroouupp
Questions ?

An adaptable DDS solution for wireless sensor networks

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to An adaptable DDS solution for wireless sensor networks

Similar to An adaptable DDS solution for wireless sensor networks (20)

More from Real-Time Innovations (RTI)

More from Real-Time Innovations (RTI) (20)

Recently uploaded

Recently uploaded (20)

An adaptable DDS solution for wireless sensor networks