29
Space rovers and surgical robots: system architecture lessons from Mars Edwin de Jong, PhD – [email protected] RTI

Space Rovers and Surgical Robots: System Architecture Lessons from Mars

Embed Size (px)

Citation preview

Page 1: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

Space rovers and surgical robots: system architecture lessons from MarsEdwin de Jong, PhD – [email protected]

Page 2: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

©2015 Real-Time Innovations, Inc.

The smart machine era will be the most disruptive in the history of IT-- Gartner 2015

Page 3: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 4: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

Space-Proven Data LinkNASA’s Human-Robotic Systems prototypes robots for extraterrestrial surfaces

Page 5: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 6: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 7: Space Rovers and Surgical Robots: System Architecture Lessons from Mars
Page 8: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

200+ Companies, 27 Countries

Page 9: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 10: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 11: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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)

Page 12: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 13: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 14: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 15: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 16: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 17: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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?

Bob Leigh
Can this say "Why Choose DDS for Autonomous Vehicles?" Let's be explicit
Page 18: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

Applications of DDS Standard• Over 1,000 IIoT designs

– Robotics– Healthcare– Automotive– Communications– Energy– Industrial– Defense

• 15+ Standards & Consortia Efforts– Interoperability– Multi-vendor ecosystems

Page 19: Space Rovers and Surgical Robots: System Architecture Lessons from Mars
Page 20: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

Data Security

Page 21: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 22: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 23: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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)

Page 24: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 25: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 26: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 27: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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

Page 28: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

©2015 Real-Time Innovations, Inc.

The Network Is The Robot

Page 29: Space Rovers and Surgical Robots: System Architecture Lessons from Mars

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