Watch the replay: http://ecast.opensystemsmedia.com/392
Looking to build a complex distributed system based on the latest and greatest technical innovations? The Data Distribution Service (DDS) standard from the Object Management Group (OMG) provides the software infrastructure for a diverse range of systems, from small networking appliances to massive wind farms. Since its adoption in 2004, the DDS standard and its implementations have evolved to address the needs of this broad application base. Attend this presentation to learn about 7 critical DDS innovations that will significantly improve the development of your next distributed system:
Type extensibility to support long-term system evolution
Rich communication patterns to simplify development and integration
Small footprint DDS implementation for resource-constrained platforms
Certification for safety-critical applications including avionics
Flexible, scalable and efficient security
Web Integration Service (HTTP / REST) interface
Integration with visual development environments: Simulink, Artisan Studio and LabView
Speaker: Bert Farabaugh, Worldwide Field Applications Engineering Manager
Bert Farabaugh is Worldwide Field Applications Engineering Manager at RTI. He works with customers to identify and develop solutions and design patterns tailored for their projects. Bert has over 16 years of experience developing networking protocols and communications design patterns from scratch for robotics and embedded systems. He has been a field applications engineer for the past 10 years, with hundreds of different applications in his portfolio.
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;
}
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);
}
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
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()
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
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