The document discusses advancements in DDS (Data Distribution Service) including type extensibility, new Java and C++ programming interfaces, and enhanced security features. It also outlines the integration of DDS with REST interfaces for broader access across applications and platforms, as well as micro DDS capabilities for resource-constrained environments. Additionally, the document emphasizes safety certification standards for DDS in critical systems and tooling integration examples with DDS technologies.

1. DDS Innovations
Bert Farabaugh (FAE Manager)
Real-Time Innovations

2. Agenda
OMG DDS Standard Enhancements
• Type Extensibility
• New Java and C++ PSM from OMG
• DDS Security Profile from OMG
• DDS HTTP Rest Interface
RTI DDS Enhancements
• Request / Reply communication pattern using
publish / subscribe
• Micro DDS for resource constrained platforms
• Safety Certification
• Tooling Integration with DDS

3. TYPE EXTENSIBILITY

4. Data Type Extensibility
• Share data definitions across DDS vendors
– Standardizes Annotations
– Currently not seamless due to vendor-specific annotations, like
keys
– Different formats in use (IDL, XML, API)
• Extend data definitions
– Extensible, Mutable, Final
– Optional Fields, Required Fields
• Adds Alternate Type representation
– XML, XSD, Dynamic Type API
• Built-in Types
– String, KeyedString, Bytes, KeyedBytes
• Type Object
– Learn type representation during Discovery
– Now part of OMG RTPS Wire Protocol
– Optional

5. Data Type Extensibility
struct Track {
long id; //@key
float range;
float bearing;
}
struct AirTrack {
long id; //@key
float range;
float bearing;
float elevation;
}
struct Track {
long id; //@key
float range;
float bearing;
} struct AirTrack {
long id; //@key
float elevation;
}
Extensible Type
• Newer applications can add fields to
existing base types
Mutable Type
• Type representations can differ from each
other with Additions, Deletions and
Transpositions
• Support for Optional Fields
struct Track {
long id; //@key
float range;
float bearing;
}
Final Type
• Type definitions are strictly defined
struct Track {
long id; //@key
float range;
float bearing;
}

6. Type Extensibility Example
Base TypeExtended Type

7. Type Extensibility Example
7
enum ShapeFillKind { SOLID_FILL = 0,
TRANSPARENT_FILL = 1,
HORIZONTAL_HATCH_FILL = 2,
VERTICAL_HATCH_FILL = 3};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
struct ShapeType{
string<128> color; //@key
long x;
long y;
long shapesize;};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
struct ShapeTypeExtended: ShapeType {
public ShapeFillKind fillKind;
public float angle;
};
struct ShapeType{
string<128> color; //@key
long x;
long y;
long shapesize;};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
Base TypeExtended Type

8. NEW JAVA & C++ PSM’S

9. Simplified DDS App Development
• New Java and C++ programming interfaces
from OMG
• Enhanced portability
– OMG providing standard interfaces files
– Decide at compile-time (C++) or even run-time (Java)
which DDS implementation to use
• Improved productivity through use of latest C++ and
Java features
– Getters and setters to access state
– Built-in primitive types, std::string, namespaces, templates,
and iterators in C++
– Standard collection types and generics in Java
– Exceptions for reporting errors
9

10. C++ “string” DataWriter Example
dds::domain::DomainParticipant dp(0);
dds::topic::Topic<Track> topic(dp, “track-topic”);
dds::pub::Publisher pub(dp);
dds::pub::qos::DataWriterQos dwqos =
pub.default_writer_qos() << Reliability::Reliable()
<< History::KeepLast(10)
<< Durability::Transient();
dds::pub::DataWriter<Track> dw (pub, topic, dwqos);
Track t = { 0xDEAD, “tank” }; // track id and vehicle-type
for(;;) {
dw.write(t);
}

11. SECURITY PROFILE FOR DDS

12. Enhanced Security Vision
The RTI DataBus can:
• Authenticate subjects
• Enforce access control
to data objects
• Ensure data integrity
• Ensure data confidentiality
• Enforce non-repudiation
• Provide availability of data
• Create auditable security logs
….while maintaining high performance
RTI DataBus™
Connext
App 1
Connext
App 2
Key Management
Authentication
Logging
Cryptography
Access Control

13. Pluggable Security Architecture
App.
Other
DDS
System
Secure DDS
middleware
Authentication
Plugin
Access Control
Plugin Cryptography
Plugin
Key
Management
Plugin
Secure Kernel
Crypto
Module
(e.g. TPM )
Secure Transport (e.g. TLS)
application componentcertificates
?
Data
cache
Protocol
Engine
Kernel
Policies
DDS Entities
Network
Driver
?
Network
Encrypted DataTAG
Other
DDS
System
Other
DDS
System
App.App.
Auditing
Plugin

14. DDS HTTP REST INTEGRATION

15. HTTP
Web Integration
• Web-enabled interface to Data Bus
– REST
• Access DDS from any application,
platform or language that can invoke a
Web Service
– Web applications, e.g., Google Maps
– JavaScript, Flash, Perl, PHP, Python, CGI
scripts
– ESBs
• Lightweight interface to DDS Data Bus
– Clients do not need to link or load
special libraries
DDS
15

16. Proposed REST Api
• “Login” “Join Domain”
• “Logout” “Leave Domain”
• “CreateSubscription,”
• “CreatePublication,”
• “RemoveSubscription,”
• “RemovePublication,”
• “GetSubscriptions,”
• “GetPublications,”
• “AddNotificationEndpoint,”
• “RemoveNotificationEndpoint,”
• “GetNotificationEndpoints,”
• “Read,”
• “Write,”

17. REQUEST / REPLY
COMMUNICATIONS PATTERN

18. Request-Reply
Requestor Replier
Request
Request
Topic
Reply
Topic Reply
18

19. Correlation
ReplierRequests
Replies
3
3
2 1
21
Message ID
Correlation ID
1
1
Requestor
Correlation
19

20. Single-Request Multiple-Reply
Requestor Replier
Replies
321
Sequence ID
Request
20

21. Multiple Repliers
Requester
Replier A
Replier C
Replier B
Request
Reply
21

22. Combining Patterns
Requestor Replier
Request
Request
Topic
Reply
Topic Reply
Subscriber
Subscriber
Wire Tap

23. MICRO DDS

24. Integration In Constrained Environments
• Integration of resource-constrained OT
systems with IT systems
– Stringent SWaP requirements
– Limited primary storage (8MB RAM)
– Limited secondary storage (32MB flash)
– Embedded low-power single-core CPU
– Lack of operating system
• Safety certification
– In avionics, medical systems
– Certification cost drives system design
($50 - $100 per ELOC)
24

25. User-Configurable Feature Set
DDS API Subset
Transport API
Base-line configuration
Static
Discovery
OS API
User Application
UDPv4 Linux 2.6
VxWorks 653APEX Dynamic
Discovery
Queue API
Listeners
Required plug-in components
Linear Q
Keyed Q
Discovery API
Reliability
Durability &
History
Other QoS
Optional
APIs
Shared
memory
VxWorks 5.5
Compile-timeoptions
RTPS
Connext Micro
25

26. Supported QoS
• DataReaderResourceLimits
• The following DataReaderResourceLimits fields are supported. All must be finite
values greater than 0.
– max_remote_writers
– max_remote_writers_per_instance
– max_samples_per_remote_writer
– max_outstanding_reads
• Destination Order
– Only the BY_RECEPTION_TIMESTAMP kind is supported.
• Durability
– Only the VOLATILE and TRANSIENT_LOCAL Durability kinds are supported.
• History
– Only the KEEP_LAST History kind is supported.
• Liveliness
– Only the MANUAL_BY_TOPIC Liveliness kind is supported, with a lease duration range of [1,
infinite].
• Deadline
– The Deadline Qos policy is supported.
• Ownership and OwnershipStrength
– Both SHARED and EXCLUSIVE Ownership kinds are supported.

27. Supported QoS (cont.)
• Reliability
– Both BEST-EFFORT and RELIABLE Reliability kinds are supported.
– For RELIABLE reliability, periodic and piggyback heartbeat
configuration are sup- ported, as well as max_send_window for setting
the size of a reliability window.
• ResourceLimits
– The following limits in the ResourceLimits QoS policy are supported.
All must be finite values greater than 0.
– max_samples,max_instances,max_samples_per_instance
– Note that max_samples must be large enough to contain all samples
for all instances:
– max_samples >= max_instances * max_samples_per_instance
• ContentFilteredTopics
– ContentFilteredTopics are not supported, but content filtering is
provided by two DataReaderListener callbacks:
on_before_sample_deserialize() and on_before_sample_commit()

28. MICRO DDS CERTIFICATION
5/1/2013

29. DO-178B/C
• A guideline
• Used by FAA as a basis
for certification
– Aircraft are “certified”
– Software code
developed under
DO-178 provides “certification evidence”
• Increasingly adopted for military aircraft

30. DO-178C Safety Levels
Level Failure Condition
Typical % of
avionics code
A
Catastrophic
(may be total loss of life)
15%
B
Hazardous/Severe
(may be some loss of life)
35%
C
Major
(injuries possible)
30%
D
Minor
(injuries unlikely)
15%
E No effect 5%

31. Tenets Of Safety-Critical Software
• Reduce code size
• Consider testability in design
• Deterministic in time
• Deterministic in memory
– No dynamic memory allocation after startup

32. Analysis of Suitability for DO178B/C
• Verocel analyzed the prototype source code
• Code is deterministic
• Code is testable
• Conforms to coding styles that make testing
easier
• Uses robustness checks and logging messages
• RTI Connext Micro currently going through
Certification

33. TOOLING INTEGRATION WITH DDS

34. Example

35. Types are defined as Bus Objects

36. 5/1/2013

37. Using Artisan Studio with RTI DDS
• Model a DDS system with UML
• Participants, Entities and Types
• Generate representative XML file
• Use XML App Creation from RTI

38. NI Labview Integration with RTI DDS
• Build LabView Application using DDS
building blocks
• Attach LabView logic block to live
data
• Connect Distributed LabView
applications

39. Download
Connext
Free Trial
NOW
www.rti.com/downloads