Robotics and IIoT Aligning
The real value is a common architecture that
connects sensor to cloud, interoperates
between vendors, and spans industries
Common technology that spans
industries brings bold new approaches
and enables fast change
Space-Proven Data Link
prototypes robots for
Solving Extreme Communication Challenges
• ESA's Telerobotics &
Haptics Lab develops
robotic technologies for
• Two people shake hands
5,000 km apart
• Requires real-time closed
loop control over highly
• The Minimally Invasive
Robotic Surgery (MIRS)
system at DLR
robots to perform
delicate heart surgery
• The system closes a
between the robots
and the remote
surgeon’s control at
200+ companies strong
Goal: build and prove a common
architecture that spans sensor to
cloud, interoperates between
vendors, and works across industries
The DDS Standard for the IIoT
• The Data Distribution Service (DDS)
is the Proven Data Connectivity
Standard for the IoT
• OMG: world’s largest systems
software standards org
– UML, DDS, Industrial Internet
• DDS: open & cross-vendor
– Open Standard & Open Source
– 12+ implementations
Interoperability between source
written for different vendors
Interoperability between applications
running on different implementations
Peer-To-Peer Plug & Play Databus
OMG Data Distribution Service (DDS)
Data Centric Architecture
• Data-centric middleware maintains state
• Middleware manages the content
• CRUD operations on distributed state
Pos Dir Accel
R1 (3.1, 7) (-1, 3.7) (0, 0)
R2 (8, 4.5) (0,0) (0,0)
R3 50.2 (5.1, 2) (0.2, 3)
More Robust Systems
• Ann: Can you visit on 1/23?
• John: Yes
• A: 23rd is booked, how
• J: OK
• A: March 6th is better…
• J: OK
• A: Can you stay longer?
• J: No; start ½ hour earlier?
• A: OK, confirmed!
• Add: 1/23 @ 11:30A
• Change: 2/20 @ 11:30A
• Change: 3/6 @ 11:30A
• Change: Add dial-in info
• Change: 3/6 @ 11:00A
Data Centricity Directly Controls Flow
• Global Data Space
– Automatic discovery
– Read & write data in any OS,
– Type Aware
– Redundant sources/sinks/nets
• No Servers!
• QoS control
– Timing, Reliability,
Shared Global Data Space
Offer: publish this
Request: Read this 60 Hz
If patient = “Joe”
Reduce Application Development By 50%
Message Centric Data Centric
Message Caching &
Why Choose DDS for Your Robotic System?
• Reliability: Severe consequences if offline for 5 minutes?
– Measure in ms or µs?
– Or scale > 20+ applications or 10+ teams?
– Or 10k+ data values?
• Architecture: System lifecycle >3 yrs?
2 or 3 Checks?
Applications of DDS Standard
• Over 1,000 IIoT designs
• 15+ Standards & Consortia Efforts
– Multi-vendor ecosystems
ROS 2 - Built on DDS
+ ROS usability
more time to
• Safety certifiable connectivity platform
– For safety critical devices (e.g. medical robots)
– Complete certification evidence
– Full interoperability with DDS implementations
• DO-178C Level A
– Flight management systems
• IEC 60601 class 3
– Medical devices
• ISO 26262
– Road vehicle functional safety
• DO-178 costs over $100 per ELOC
• Process objectives must be met
• All must be documented
• Code must be clean
– No dead code
A 71 Level B and 100% of MCDC
B 69 Level C plus 100% of DC
C 62 Level D plus 100% of SC
D 26 100% of Requirements
E 0 None
Safety-Certifiable IIoT Platform
• Scalable product line for
safety critical devices
• Certifiable component
– DO-178C Level A
– ~25K ELOC
• Follows OMG DDS specification
Software Development Folder (electronic form)
NOTE: This information is provided as a set of
files on a DVD. They are not maintained as a
folder; instead, additional files are generated
which allow these materials to be grouped by
requirements. The information is presented in
a browseable format so that the information
may be viewed as a software development
folder based on requirement identification.
The Software Development Folder (SDF) includes at
Reference to the applicable requirements.
Reference to the implementation (Design &
Evidence of reviews for the requirements,
design, code, test procedures, test results,
and structural coverage analyses.
Software test procedures.
Software test results.
Artifact Change history (CM System).
Applicable problem reports.
SQA Audit Reports.
Internal Software Conformity Review
(provided separate from the certification
Product Name Product Description Control Category DO-178C
Plan for Software Aspects of Certification
Provides the certification (approval) authorities an
overview of the means of compliance, and insight
into the planning aspects for delivery of the
product specific to Connext DDS Cert.
Software Quality Assurance Plan (SQAP) Defines the SQA process and activities. CC1 11.5
Software Configuration Management Plan
Defines the CM and change control processes. CC1 11.4
Software Development Plan (SDP)
Software Requirements Standard (SRStd)
Software Design Standard (SDStd)
Software Coding Standard (SCStd)
Defines the processes used for requirements
analysis, development, and test for the software
product. Includes the standards for requirements,
design, and code.
Software Verification Plan (SVP) Defines the test philosophy, test methods, and
approach used to verify the software product.
Software Test Plan (STP) Documents the project-specific approach to
verifying Connext DDS Cert.
Tool Qualification Plan Identifies the tools to be qualified under the
Software Requirements Specification (SRS) Defines the software requirements applicable to
Connext DDS Cert.
Software Vulnerability Analysis (SVA) Identifies potential failure conditions in the
software, their potential impact, and proposed
mitigation for Connext DDS Cert.
Design Components, in Program Design
Describes the design of Connext DDS Cert. CC1 11.10
Software Configuration Index (SCI)
Software Configuration Index (SCI) Tables
Identifies the software components for Connext
DDS Cert with version information necessary to
support regeneration of the product. Also includes
the documents comprising the data package.
Software Life Cycle Environment Configuration
Identifies the tools used to build and test the
software for Connext DDS Cert.
Technical White Paper:
- Control-Coupling Verification With
Single topic technical paper providing additional
information to the certification authorities and
Requirements Traceability Document (RTD) Provides traceability from the requirements to all
related certification life cycle artifacts including
design, code, and test materials for the delivered
Software Accomplishment Summary (SAS) Documents the actual versus planned (per PSAC)
activities and results for the project. Provides a
summary of the means of compliance used for the
software. Justifies any deviations from the plans.
Sources Provides the Source files for:
- Connext DDS Cert
- Test procedures.
- Build and test scripts.
Results Documents the results of the functional and
structural coverage analysis. This includes the
actual results and any applicable analyses
performed including coverage analysis.
Libraries Linkable versions of the “as tested” product
Verification tools Verification tools are identified and described in the
Tool Qualification Plan for Connext DDS Cert.
940 High-Level Requirements
3,680 Low-Level Requirements
3,400 test files
99.88% code coverage testing