Originally presented on May 05, 2016. Watch On-Demand: http://ecast.opensystemsmedia.com/636

1. Space rovers and surgical robots: system
architecture lessons from Mars
Edwin de Jong, PhD – edwin@rti.com
RTI

2. ©2015 Real-Time Innovations, Inc.
The smart machine era will be the most disruptive in the history of IT
-- Gartner 2015

3. 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

4. Space-Proven Data Link
NASA’s Human-
Robotic Systems
prototypes robots for
extraterrestrial
surfaces

5. Solving Extreme Communication Challenges
• ESA's Telerobotics &
Haptics Lab develops
robotic technologies for
advanced human-
machine interaction
• Two people shake hands
5,000 km apart
• Requires real-time closed
loop control over highly
challenged link

6. Surgical Systems
• The Minimally Invasive
Robotic Surgery (MIRS)
system at DLR
coordinates three
robots to perform
delicate heart surgery
• The system closes a
distributed loop
between the robots
and the remote
surgeon’s control at
3kHz

7. 200+ companies strong
Goal: build and prove a common
architecture that spans sensor to
cloud, interoperates between
vendors, and works across industries

8. 200+ Companies, 27 Countries

9. 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
Consortium
• DDS: open & cross-vendor
– Open Standard & Open Source
– 12+ implementations
Interoperability between source
written for different vendors
Interoperability between applications
running on different implementations
DDS-RTPS Protocol
Real-Time Publish-Subscribe
Distribution Fabric
DDS API

10. Peer-To-Peer Plug & Play Databus
OMG Data Distribution Service (DDS)
Control
Commands
Sensor
SensorData
ActuatorSensor
SensorData
Display

11. Data Centric Architecture
• Data-centric middleware maintains state
• Middleware manages the content
• CRUD operations on distributed state
Persistence
Service
Recording
Service
Source
(Key)
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)

12. More Robust Systems
Messaging
• Ann: Can you visit on 1/23?
• John: Yes
• A: 23rd is booked, how
about 2/20?
• J: OK
• A: March 6th is better…
• J: OK
• A: Can you stay longer?
• J: No; start ½ hour earlier?
• A: OK, confirmed!
Data-Centric Pub-Sub
• 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
J:
2/20
A:
3/6
3/6
11:00
A J

13. DDS Real-Time Quality of Service
©2015 Real-Time Innovations, Inc.
• Highly tunable reliability
protocol
– Balancing throughput
and latency
– Across wide variety of interconnects
• Time aware
– Deadline notifications
– Nanoseconds timestamps
• Historic data for late joiners
• Control over subscribed data
– By time
– By content

14. Sensor-to-Cloud Data Bus
©2015 Real-Time Innovations, Inc.
Unit DataBus
Unit DataBus
• Connect…
– Fast
– Seamless
– Secure
• Across many
platforms…
• Over any networking
technology Intelligent
Machines
Intelligent
Systems
Intelligent
Industrial
Internet
Cloud DataBus
Site DataBus
Intelligent
System of
Systems
Unit DataBus
Sense Act
Think HMI
Machine DataBus
Think HMI
Machine DataBus
Sense Act
Think HMI
Machine DataBus
Hide
Complex
Topology
behind a
Single
logical
DataBus

15. Data Centricity Directly Controls Flow
• Global Data Space
– Automatic discovery
– Read & write data in any OS,
language, transport
– Type Aware
– Redundant sources/sinks/nets
• No Servers!
• QoS control
– Timing, Reliability,
Redundancy, Ordering,
Filtering
Shared Global Data Space
DDS DataBus
Patient Hx
Device
Identity
Surgical
robot
SupervisoryCDS
Physiologic
State
Operating
Theater
Clou
d
Offer: publish this
3KHz
Reliable
Request: Read this 60 Hz
If patient = “Joe”
Best-effort

16. Reduce Application Development By 50%
Message Centric Data Centric
Message Centric
Middleware
Application
Application Logic
Message Parsing
and Filtering
Message Caching
Send/Receive
Packets
Addressing,
Marshaling
Data Centric
Middleware (RTI)
Send/Receive
Packets
Discovery, Presence
Marshaling, 32/64
Message Caching &
State Management
Message Parsing
and Filtering
Application
Application Logic
Savings

17. Why Choose DDS for Your Robotic System?
• Reliability: Severe consequences if offline for 5 minutes?
• Performance/scale:
– 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?

18. Applications of DDS Standard
• Over 1,000 IIoT designs
– Robotics
– Healthcare
– Automotive
– Communications
– Energy
– Industrial
– Defense
• 15+ Standards & Consortia Efforts
– Interoperability
– Multi-vendor ecosystems

19. ROS 2 - Built on DDS
+ ROS usability
less time
spent here
means
more time to
spent here

20. Data Security

21. Security Example
21
Data Item Authentication Access
Control
Integrity Non-
repudiation
Confidentiality
Device
diagnostic
data
X X
Remote
commands
X X X X
Patient Data X X X X

22. Limitations of Transport Layer Security
TCP/IP Capable Network
Native
DDS App
DDS Library
Native
DDS APP
DDS Library
Secure Transport Secure Transport
SSL, TLS or DTLS
Native
DDS APP
DDS Library
Secure Transport
• No multicast
• Poor latency/jitter
• Robust networks only
• Reliable delivery only
• Data and headers
always encrypted
• Gross level security

23. Practical Fine-Grain Security
• Per-Topic Security
– Control r,w access for each function
– Ensures proper dataflow operation
• Complete Protection
– Discovery authentication
– Data-centric access control
– Cryptography
– Tagging & logging
– Non-repudiation
– Secure multicast
– 100% standards compliant
• No code changes!
• Plugin architecture for advanced uses
© 2015 Real-Time Innovations, Inc.
CBM AnalysisPMU Control Operator
State Alarms SetPoint
Topic Security model:
• PMU: State(w)
• CBM: State(r); Alarms(w)
• Control: State(r), SetPoint(w)
• Operator: *(r), Setpoint(w)
New Secure DDS Standard
• Per topic security
• Complete protection
– Data-centric access control
– Cryptography
– Secure multicast
– Standards compliant
• No code changes!
Topic security model:
• PMU: State (w)
• CBM: State(r); Alarms(w)
• Control: State(r), SetPoint(w)
• Operator: *(r), SetPoint(w)

24. Safety Certification
• 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
Available
Soon
Soon

25. Certification Costs
• DO-178 costs over $100 per ELOC
• Process objectives must be met
• All must be documented
• Code must be clean
– Testable
– No dead code
– Deterministic
Level Process
Objectives
Code Coverage
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
5/9/2016 25

26. Safety-Certifiable IIoT Platform
• Scalable product line for
safety critical devices
• Certifiable component
– DO-178C Level A
– ~25K ELOC
• Follows OMG DDS specification
5/9/2016 26

27. Software Development Folder (electronic form)
(SDF)
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
a minimum:
 Reference to the applicable requirements.
 Reference to the implementation (Design &
Code).
 Evidence of reviews for the requirements,
design, code, test procedures, test results,
and structural coverage analyses.
 Software test procedures.
 Software test results.
 White Papers.
 Artifact Change history (CM System).
 Applicable problem reports.
 SQA Audit Reports.
 Internal Software Conformity Review
(provided separate from the certification
data package).
CC1 11.9
11.10
11.13
11.14
11.17
11.18
11.19
Full Evidence
Product Name Product Description Control Category DO-178C
Reference
Plan for Software Aspects of Certification
(PSAC)
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.
CC1 11.1
Software Quality Assurance Plan (SQAP) Defines the SQA process and activities. CC1 11.5
Software Configuration Management Plan
(SCMP)
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.
CC1 11.2
11.6
11.7
11.8
Software Verification Plan (SVP) Defines the test philosophy, test methods, and
approach used to verify the software product.
CC1 11.3
Software Test Plan (STP) Documents the project-specific approach to
verifying Connext DDS Cert.
CC1 11.3
Tool Qualification Plan Identifies the tools to be qualified under the
current project.
CC2 12.2.2
DO-330
10.1.2
Software Requirements Specification (SRS) Defines the software requirements applicable to
Connext DDS Cert.
CC1 11.9
Software Vulnerability Analysis (SVA) Identifies potential failure conditions in the
software, their potential impact, and proposed
mitigation for Connext DDS Cert.
CC1 N/A
Design Components, in Program Design
Language (PDL)
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.
CC1 11.16
Software Life Cycle Environment Configuration
Index (SECI)
Identifies the tools used to build and test the
software for Connext DDS Cert.
CC1 11.15
Technical White Paper:
- Control-Coupling Verification With
VerOLink (VerOLinkWP.pdf)
-
Single topic technical paper providing additional
information to the certification authorities and
users.
CC2 N/A
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 product.
CC1 11.9
11.21
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.
CC1 11.20
Sources Provides the Source files for:
- Connext DDS Cert
- Test procedures.
- Build and test scripts.
CC1 11.11
Results Documents the results of the functional and
structural coverage analysis. This includes the
actual results and any applicable analyses
performed including coverage analysis.
CC1 11.14
11.21
11.22
Libraries Linkable versions of the “as tested” product
libraries.
CC1 11.12
Verification tools Verification tools are identified and described in the
Tool Qualification Plan for Connext DDS Cert.
CC2 12.2
940 High-Level Requirements
3,680 Low-Level Requirements
3,400 test files
99.88% code coverage testing

28. ©2015 Real-Time Innovations, Inc.
The Network Is The Robot

29. For More Information
• DDS and RTI: www.rti.com
• Robotics seminar in Boston area June 15
• Get started with DDS for free:
www.rti.com/downloads