Upload
real-time-innovations-rti
View
531
Download
0
Embed Size (px)
Citation preview
Space rovers and surgical robots: system architecture lessons from MarsEdwin de Jong, PhD – [email protected]
©2015 Real-Time Innovations, Inc.
The smart machine era will be the most disruptive in the history of IT-- Gartner 2015
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 LinkNASA’s Human-Robotic Systems prototypes robots for extraterrestrial surfaces
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
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
200+ Companies, 27 Countries
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 ProtocolReal-Time Publish-Subscribe
Distribution Fabric
DDS API
Peer-To-Peer Plug & Play Databus
OMG Data Distribution Service (DDS)
Sens
or D
ata
Control
Com
man
ds
Stat
us
Sensor
Sens
or D
ata
Actuator
Com
man
ds
Stat
us
Sensor
Sens
or D
ata
Display
Sens
or D
ata
Stat
us
Data Centric Architecture
• Data-centric middleware maintains state• Middleware manages the content• CRUD operations on distributed state
PersistenceService
RecordingService
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)
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/611:00
A J
DDS Real-Time Quality of Service
©2015 Real-Time Innovations, Inc.
• Highly tunable reliabilityprotocol
– Balancing throughputand 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
Sensor-to-Cloud Data Bus
©2015 Real-Time Innovations, Inc.
Unit DataBusUnit DataBus
• Connect…– Fast– Seamless– Secure
• Across many platforms…• Over any networking
technology IntelligentMachines
IntelligentSystems
IntelligentIndustrial Internet
Cloud DataBus
Site DataBus
IntelligentSystem 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
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
Surgicalrobot
Supe
rviso
ry C
DS
Physiologic State
Ope
ratin
gTh
eate
r
Cloud
Offer: publish this 3KHz
Reliable
Request: Read this 60 HzIf patient = “Joe”
Best-effort
Contract
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
Savi
ngs
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?
Applications of DDS Standard• Over 1,000 IIoT designs
– Robotics– Healthcare– Automotive– Communications– Energy– Industrial– Defense
• 15+ Standards & Consortia Efforts– Interoperability– Multi-vendor ecosystems
Data Security
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
Limitations of Transport Layer Security
TCP/IP Capable Network
NativeDDS App
DDS Library
NativeDDS APP
DDS Library
Secure Transport Secure Transport
SSL, TLS or DTLS
NativeDDS APP
DDS Library
Secure Transport
• No multicast• Poor latency/jitter• Robust networks only• Reliable delivery only• Data and headers
always encrypted• Gross level security
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)
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
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
05/02/2023 25
Safety-Certifiable IIoT Platform
• Scalable product line forsafety critical devices
• Certifiable component– DO-178C Level A– ~25K ELOC
• Follows OMG DDS specification
05/02/2023 26
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 EvidenceProduct Name Product Description Control Category DO-178C
ReferencePlan 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.5Software 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.2Software 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.21Software 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.22Libraries 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 Requirements3,680 Low-Level Requirements3,400 test files99.88% code coverage testing
©2015 Real-Time Innovations, Inc.
The Network Is The Robot
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