Your systems. Working as one.

Build Safe & Secure Distributed SystemsMeet DoD Open Architecture Requirements and Cyber Security Guidance

Topics

• Introductions• Open Architecture• Data Distribution Service (DDS)• DDS security• DDS safety• DDS in UCS and FACE• RTI Connext DDS• Q&A

2014-Oct-1 2© 2014 RTI

3

Why is RTI?

To enable and realize the potential ofsmart machines to serve mankind

2014-Oct-1 © 2014 RTI

4

RTI Enables the Industrial Internet

• Real-time IIoT communication platform

• Proven across industries • Sensor-to-cloud integration

© 2014 RTI

Connext DDS

2014-Oct-1

5

About RTI

• Market Leader– 1,000+ projects use Connext DDS– Over 70% DDS middleware market share1

– Largest embedded middleware vendor2

– 2013 Gartner Cool Vendor for technology andOpen Community Source model

• Standards Leader– Active in 15 standards efforts– DDS authors, chair, wire spec, security, more– IIC steering committee; OMG board

• Team Quality Leader– Stanford research pedigree– High-performance, control, systems experts– Top quality product, processes, execution

© 2014 RTI

1Embedded Market Forecasters2VDC Analyst Report

2014-Oct-1

6

IIoT Infrastructure Trusts RTI

• World’s largest Wind Power company• World’s largest Underground Mining Equipment company• World’s largest Navy (all surface ships)• World’s largest Automotive company• World’s largest Emergency Medical System company• World’s largest Medical Imaging provider• World’s 2nd largest Patient Monitoring manufacturer• World’s 2nd largest Air Traffic control system• World’s largest Broadcast Video Equipment manufacturer• World’s largest Launch Control System• World’s largest Telescope (under construction)• World’s 5th-largest Oil & Gas company• World’s 6th-largest power plant (largest in US)• All of world’s top ten defense companies

RTI designed into over $1 trillion

2014-Oct-1 © 2014 RTI

7

RTI Named Most Influential IIoT Company

2014-Oct-1 © 2014 RTI

82008

Global Support and Distribution

© 2014 RTI2014-Oct-1

Open Architecture

102014-Oct-1 © 2014 RTI

11

Reality

2014-Oct-1 © 2014 RTI

12

Imperative

• Affordability

• “Do more with less”

2014-Oct-1 © 2014 RTI

13

How

• Improve reuse• Reduce maintenance and integration time

– Incremental upgrades– New technology insertion– System of Systems

• Promote competition– Reduce costs– Foster innovation

2014-Oct-1 © 2014 RTI

14

Traditional Approach

2014-Oct-1 © 2014 RTI

15

Traditional Approach

?

2014-Oct-1 © 2014 RTI

16

Traditional Approach

2014-Oct-1 © 2014 RTI

17

Traditional Approach

• Hard coded connections

• Up to O(n2)• Complex• Hard to maintain,

evolve, re-use

E.g., sockets, RPC

2014-Oct-1 © 2014 RTI

18

Result

Time & cost of integration,

maintenance and upgrades

System Scale and Age

O(n2)

2014-Oct-1 © 2014 RTI

19

Solution: Modularity

2014-Oct-1 © 2014 RTI

20

Key: Interoperability

Well-defined:• Interfaces• Semantics

2014-Oct-1 © 2014 RTI

21

Implementation Challenges

• Demanding technical requirements– Real-time performance– Reliability, safety, survivability– Dynamic and ad hoc

environments– Unreliable networks

• Migrating existing systems– OA versus other development

and funding priorities2014-Oct-1 © 2014 RTI

Data Distribution Service

Designed for the Industrial Internet of Things

23

For loose coupling, provides:• Discovery• Routing• High-availability• QoS enforcement

• Well-define interfaces

• Standard interoperability Protocol

Data Distribution Service

2014-Oct-1 © 2014 RTI

24

DDS Standard

• Interoperability and portability– Data model specification and

discovery– Network protocol– Programming interface

• Managed by Object Management Group (OMG)

Cross-vendor source portability

Cross-vendor interoperability

Standard Protocol

DDS Implementation

Standard APIData

Model

2014-Oct-1 © 2014 RTI

25

Peer-to-Peer Communication

• Completely decentralized• No intermediate servers,

message brokers or ESB

• Low latency• High scalability• No single point of failure

DDS-RTPS Wire Interoperability Protocol

App or Component

DDS Library

App or Component

DDS LibraryDDSAPI

2014-Oct-1 © 2014 RTI

26

Easy Integration of Existing Components

Unmodified App

DDS-RTPS Wire Interoperability Protocol

DDS Routing Service

Adapter

Unmodified App

DDS Routing Service

AdapterApp or

Component

DDS Library

App or Component

DDS Library

DDS or other protocol

DDSAPI

New and Updated Applications Existing, Unmodified Applications

2014-Oct-1 © 2014 RTI

27

Seamless Enterprise-Wide ConnectivityConnect Everything, Everywhere

• Proximity• Platform• Language

• Physical network• Transport protocol• Network topology

Data Distribution Service

Seamless data sharing regardless of:

2014-Oct-1 © 2014 RTI

28

Example: RTI Connext Availability

• Programming languages and environments

– C, C++, C#/.NET, Java, Ada– Lua, Python– LabVIEW, MATLAB, Simulink, UML– REST/HTTP

• Operating systems– Windows, Linux, Unix, Mac OS– Mobile– Embedded, real time– Safety critical, partitioned

• Processor families– x86, ARM, PowerPC…– 32- and 64-bit

• Transport types– Shared memory– LAN (incl. multicast)– WAN / Internet– Wireless– Low bandwidth

Completely application transparent2014-Oct-1 © 2014 RTI

29

Foundation: Publish/Subscribe

Data Distribution Service

Sens

or D

ata

Control App

Com

man

ds

Stat

usSensor

Sens

or D

ata

Actuator

Com

man

ds

Stat

us

Sensor

Sens

or D

ata

Display App

Sens

or D

ata

Stat

us

2014-Oct-1 © 2014 RTI

30

Support for Mission-Critical Systems

• Autonomous operation– Automatic discovery– No sys admin or centralized

infrastructure• Non-stop: no single point of failure• QoS control and visibility into

real time behavior, system health‑• Embeddable• RTI Connext is TRL 9

2014-Oct-1 © 2014 RTI

Why Distribution Middleware?

8.0 Training

5.0 Communications

2.0 Sensors

3.0 Fusion

4.0 BMC2

7.0 Visualization

6.0 Sensor Control

1.0 Common Services

Grouping the modules into functional clusters does nothing to change that reality and ease software integration

UNCLASSIFIED

Hawkeye has functionally oriented software modules

Each module talks to many other modules

RIP TRK MSIWAC TDA

ESM SAFERDR IFF

SEN DSCL4 L16L11

HMI ACIS

DIA NAV IPCCMCPMUX

FIL TDM

Adding new functionality cascades integration re-work across many other modules

CEC

8.0 Training

5.0 Communications

2.0 Sensors

3.0 Fusion

4.0 BMC2

7.0 Visualization

6.0 Sensor Control

1.0 Common Services

RIP TRKCEC MSIWAC RAIDERTDA

DWC

CHAT

ESM SAFERDR IFF

SEN DSCD

istributed Data Fram

ework

IPv6L4 L16L11

HMI ACIS T4O

DIA NAV IPCCMCPMUX

FIL TDM aADNS TIS

1.0 Common Services

Changing the communication between the modules can ease integration, when the new ‘Publish Subscribe’ approach is used – each module publishes its output w/o regard to who is receiving it, in contrast to the point-to-point approach of traditional inter-process communication

It’s about an architecture that can assimilate evolving functionality, rather than remaining set in time

33

US Army Asset Tracking System

Next-Gen Capability:• 50K lines of code—order

of magnitude less• 1 yr to develop—8x less• 1 laptop—20x less• Achieved: 250K+ tracked

updates/sec, no single point of failure

Legacy Capability:• 500K lines of code• 8 yrs to develop• 21 servers• Achieved: 20K tracked

updates/sec, reliability and uptime challenges

“This would not have been possible with any other known technology.”—Network Ops Center Technical Lead

2014-Oct-1 © 2014 RTI

34

RPC over DDS

2014DDSSecurity

2014Web-EnabledDDS

2013

DDS: Family of Specifications

DDSImplementation

Network / TCP / UDP / IP

App

DDSImplementation

App

DDSImplementation

DDS Spec

2004

DDSInteroperablity

2006

UML Profilefor DDS

2008

DDS forLw CCM

2009

DDS X-Types

2010 2012

DDS-STD-C++DDS-JAVA5

App

2014-Oct-1 © 2014 RTI

35

RTI RoleRTI Role Product Status

Core DDS API DCPS author 1st implementation

DDS-RTPS Protocol Sole author 1st implementation

Based on IEC 61148, which was authored by RTI and Schneider Automation

DDS-XTypes Primary author 1st implementation Based on prior RTI innovation

DDS C++ PSM RFP author; specification co-author EAR available now

DDS Java PSM Sole author Under development

DDS Security Primary author EAR available nowWeb-enabled DDS Primary author EAR available now

2014-Oct-1 © 2014 RTI

36

RTI Role

RTI Role Product Status

UML Profile for DDS Co-submitter

1st implementation (3rd-parties)

Standard being refined

DDS for lwCCM Co-submitter

1st implementation (3rd-party)

RPC over DDS Primary author

Submission based on current capability

Standard still under development

Instrumentation RFP author Prototype now

2014-Oct-1 © 2014 RTI

37

Broad Adoption and Support

• RTI Connext alone used by 1,000+ projects• ~14 implementations• 9 vendors have demonstrated interoperability

2014-Oct-1 © 2014 RTI

38

Interoperability Demonstration

OCI ETRI PrismTech IBM RTI Twin Oaks

2014-Oct-1 © 2014 RTI

DDS Compared to Alternative Approaches

40

Traditional IT and Consumer

• Limited scalability and performance– Capacity of individual links and switch ports– CPU and resource limits on servers

• Poor robustness– Tied to server maintenance and failures– Single point of vulnerability

• Lessens capabilities and utility– Single centralized “brain”– No autonomy. Lack of intelligence at the edge.

• Centralized ESB or Message Broker

• E.g.: MQTT, XMPP, AMQP, CoAP, Web Services

2014-Oct-1 © 2014 RTI

41

DDS:Distributed Analytics & Control at the Edge

• Analyze orders of magnitude more data• Lower latency control for faster response• Highly resilient, no single point of failure• Fine-grained access control and security• Vastly more capable: Intelligence at the edge

IT

Same Internet, but new WEB

2014-Oct-1 © 2014 RTI

42

Comparison

2014-Oct-1 © 2014 RTI

DDS DBMS RESTCoAP

MQTT AMQP XMPP

Standard wire protocol ✔ ✔ ✔ ✔ ✔Publish/Subscribe (event-driven) ✔ ✔ ✔ ✔Explicit, discoverable interfaces ✔ ✔Type safe (std/disc data encoding) ✔ ✔ ✔ I/S XML

Standard API ✔ ✔ (JMS)

Managed state (single src of truth) ✔ ✔ last

Data-level Quality of Service ✔Content filtering (routing) ✔ ✔ I/S

Time-based filtering ✔ I/L

Decentralized (no failure pt, bottleneck) ✔ Fed

Autonomous (no admin) ✔

N/A=Not Applicable, M/O=Metadata Only, I/S=Implementation Specific, I/L=within Integration Logic

DDS Security

45

Q4 2013 Reported Cyber Incidents toU.S. Critical Infrastructure

http://ics-cert.us-cert.gov/monitors/ICS-MM201312

2014-Oct-1 © 2014 RTI

46

Threats

2014-Oct-1 © 2014 RTI

47

ThreatsAlice: Allowed to publish topic TBob: Allowed to subscribe to topic TEve: Non-authorized eavesdropper Trudy: IntruderTrent: Trusted infrastructure serviceMallory: Malicious insider

1. Unauthorized subscription2. Unauthorized publication3. Tampering and replay 4. Unauthorized access to data

by infrastructure services

2014-Oct-1 © 2014 RTI

48

Security Terms: a Safe-Deposit Box

• Authentication: The bank knows who youare. You must show ID.

• Access Control: The bank only lets thoseon an access list into your box.

• Confidentiality: You are alone in the room. Nobody can see the contents of the box.

• Integrity: The box is sealed. If anybody touches it you will know.

• Non repudiation: You sign when you come in and out so you can’t claim that you weren’t there.

• Availability: The bank is always open. 2014-Oct-1 © 2014 RTI

49

Security Boundaries

System Boundary

Transport

Data

2014-Oct-1 © 2014 RTI

50

System Boundary

• Across security domains• Independent of how data is secured within a

system

System 1

• Diode• Filter• Downgrade

System 2Cross-

Domain Guard

2014-Oct-1 © 2014 RTI

51

Transport Layer

ExistingApp

TCP/IP Capable Network

DDS Routing Service

Adapter

ExistingApp

DDS Routing Service

Adapter

NativeDDS App

DDS Library

NativeDDS APP

DDS Library

Secure Transport

Secure Transport

Secure Transport

Secure Transport

Typically SSL, TLS or DTLS

2014-Oct-1 © 2014 RTI

52

Secure Data Transfer

1. Authenticate– Verify identity

2. Securely exchange cryptographic keys3. Use keys to:

– Encrypt data– Add a message authentication code

App 1 App 2

2014-Oct-1 © 2014 RTI

53

Secure Channel for Cross-Network Bridging

System 1LAN

Routing Service

System 2LAN

Routing Service

TLSWAN/

Internet

Can be used with or without

a firewall

2014-Oct-1 © 2014 RTI

54

Connecting Clients Across a WAN

• Remote access to cloud or data center– Clients communicate with participants in data center or

cloud LAN, not with each other– Clients behind firewalls– Only one public address required

• Example: Exposing a service to end-user clients

Remote App

Routing Service

Remote App

Remote App

TLS

2014-Oct-1 © 2014 RTI

55

Limitations of Transport Security:No Inherent Access Control

• You’re authenticated or you’re not• Less an issue for centralized systems

– E.g.: non-real-time IT and consumer IoT systems– Broker centrally manages access control

Device

App App App

Device Device

Message Broker

• Poor performance and scalability

• Single point of failure/failover

2014-Oct-1 © 2014 RTI

56

Limitations of Transport Security:Overall Poor Performance and Scalability

• No multicast support (even with DTLS over UDP)– Broad data distribution is very inefficient

• Usually runs over TCP: poor latency and jitter• Requires a network robust enough to support IP and

TCP• All data treated as reliable

– Even fast changing data that could be “best effort”• Always encrypts all data, metadata and protocol

headers– Even if some data does not have to be private

• Security is at a very gross level2014-Oct-1 © 2014 RTI

57

Introducing DDS Security

First security standard to address performance, safety and security requirements of

mission critical and real-time systems‑

Secure DDS

Sensors Actuators

Streaming Analytics &

ControlHMI/UI IT, Cloud & SoS

Connectivity

2014-Oct-1 © 2014 RTI

58

DDS Security

• Security extensions to DDS standard• Requires trivial or no change to existing

DDS apps and adapters• Runs over any transport

– Including low bandwidth, unreliable– Does not require TCP or IP– Multicast for scalability, low latency

• Plugin architecture– Built-in defaults– Customizable via standard API

• Completely decentralized– High performance and scalability– No single point of failure

Secure DDSlibrary

Authentication

Access Control

Encryption

Data Tagging

Logging

Application

Any Transport(e.g., TCP, UDP, multicast,

shared memory, )

2014-Oct-1 © 2014 RTI

59

Network

Connext DDSlibrary

Authentication

Access Control

Encryption

Data Tagging

Logging

Application

Transport(e.g., TCP, UDP, multicast,

shared memory)

Secu

rity

Plug

ins

Connext DDSlibrary

Authentication

Access Control

Encryption

Data Tagging

Logging

Application

Transport

Connext DDSlibrary

Authentication

Access Control

Encryption

Data Tagging

Logging

Application

Transport

2014-Oct-1 © 2014 RTI

Service Plugin

Purpose Interactions

Authentication

Authenticate the principal that is joining a DDS Domain.

Handshake and establish shared secret between participants

The principal may be an application/process or the user associated with that application or process.

Participants do mutual authentication and establish shared secret

Access Control

Decide whether a principal is allowed to perform a protected operation.

Protected operations include joining a specific DDS domain, creating a Topic, reading a Topic, writing a Topic, etc.

Cryptography

Perform the encryption and decryption operations. Create & Exchange Keys. Compute digests, compute and verify Message Authentication Codes. Sign and verify signatures of messages.

Invoked by DDS middleware to encrypt data, compute and verify MAC, compute & verify Digital Signatures

Logging Log all security relevant events

Invoked by middleware to log

Data Tagging

Add a data tag for each data sample

61

Standard CapabilitiesAuthentication X.509 Public Key Infrastructure (PKI) with a pre-configured

shared Certificate Authority (CA) Digital Signature Algorithm (DSA) with Diffie-Hellman and

RSA for authentication and key exchange

Access Control Specified via permissions file signed by shared CA Control over ability to join systems, read or write data topics

Cryptography Protected key distribution AES128 and AES256 for encryption HMAC-SHA1 and HMAC-SHA256 for message authentication

and integrity

Data Tagging Tags specify security metadata, such as classification level Can be used to determine access privileges (via plugin)

Logging Log security events to a file or distribute securely over Connext DDS

2014-Oct-1 © 2014 RTI

62

Security FlowDomain

Participant Create Fails

AuthenticateDP?Yes

AuthenticateDP?

No

Ignore Remote DP

AuthenticateRemote DP?

No

Yes

No

Yes

Access OK?Ignore remote

endpoint

Message security

Endpoint Create Fails

YesAccess OK?

No

Create Domain

Participant

Create Endpoints

Discover remote

Endpoints

Send/Receive data

Discover remote DP

2014-Oct-1 © 2014 RTI

63

Protections

Protected Objects

Domain (by domain_id)Topic (by Topic name)DataObjects (by Instance/Key)

Protected Operations

Domain.joinTopic.createTopic.read (includes QoS)Topic.write (includes QoS)Data.createInstanceData.writeInstanceData.deleteInstance

2014-Oct-1 © 2014 RTI

64

Control over Encryption

• Scope– Discovery data– Metadata– Data

• For each:– Encrypt– Sign

• Optimizes performance by only encrypting data that must be private

2014-Oct-1 © 2014 RTI

65

Example Domain Governance

2014-Oct-1 © 2014 RTI

66

Example Permissions

2014-Oct-1 © 2014 RTI

67

DDS Security Status

• Specification adopted March 2014– Considered “Beta” for 1 year– RTI chairing Finalization Task Force

• Specification provides a framework for securing DDS systems– Built-in plugins provide a common approach for

applications without specialized requirements– Custom plugins can be developed to match more

specialized deployments and integrate with existing infrastructure and hardware

• Early Access Release available now from RTI2014-Oct-1 © 2014 RTI

68

Specification Reviewers Include:

• GE• Intel• Siemens• Technicolor• NSWC• General Dynamics

• THALES• SAAB• Cassidian• QinetiQ & UK MOD• Lockheed• Raytheon

• None found any show stoppers• Several contacted OMG to urge adoption

2014-Oct-1 © 2014 RTI

USS SecureThe USS SECURE cybersecurity test bed is a collaboration between the National Security Agency, Department of Defense Information Assurance Range Quantico, Combat Systems Direction Activity Dam Neck, NSWCDD, NSWC Carderock/Philadelphia, Office of Naval Research, Johns Hopkins University Applied Physics Lab, and Real Time Innovations Inc.

• The objective of USS SECURE is to immunize a warfare system against the effects of a cyberattack and to rapidly recover when the system is impacted.

• USS SECURE's test bed determines the best combination of cyberdefense technologies to secure a naval combatant without impacting real time deadline scheduled performance requirements.

• The DoN IM/IT and Cyberspace mission is to provide effective, efficient, trusted and shared Information Management/Information Technology cyberspace and IRM capabilities to support the Navy, Marine Corps and their mission partners conducting global military and business operations.

http://www.navy.mil/submit/display.asp?story_id=79228

2014-Oct-1 © 2014 RTI 69

USS Secure• "This test bed enables us to develop, evaluate and test cybersecurity concepts and

technologies to defend mission critical systems at sea and ashore," said Simonoff.

• "The USS SECURE has led a series of cybersecurity and cyberengineering 'firsts' for NSWCDD and has helped position the command as a leader and innovator for cybersecurity solutions that will benefit not only our Navy but the Department of Defense community at large," said Nerney.

• "For the Navy, USS SECURE means increasing maneuverability in cyberspace to execute the assigned mission, undeterred by a cyberattack," said Simonoff. "For the Dept. of Defense, the nation is well served because America's Navy stands available 24/7, even in the face of a cyberattack."

2014-Oct-1 © 2014 RTI 70

Security Example:Power Grid

In Partnership with PNNL

© 2014 RTI

72

Data Security Requirements

Data Item Authentica-tion

Access Control

Integrity Non-repudiation

Confidentiality

Control traffic X X X X X

Data Telemetry traffic

X X

Physical Security Data

X X X

Engineering maintenance

X

Source: www.sxc.hu

2014-Oct-1 © 2014 RTI

73

Test Environment

• Real World Environment– Transmission switching

substation– Real substation equipment

• PNNL powerNET Testbed– Remote connectivity– Local control room

demonstration environment– Dynamically reconfigurable

2014-Oct-1 © 2014 RTI

74

SCADA Equipment Setup

2014-Oct-1 © 2014 RTI

75

Control Station

DNP3 MasterDevice

Transmission Substation

DNP3 Slave

Device

RTI and PNNL Grid Security Retrofit

RTI Routing Service

ComProcessor

RTI Routing Service

Gateway

DNP3 Slave

Device

DNP3 overRS232/485

DNP3 overEthernet DNP3 over DDS

RTI Routing Service

Gateway

DDSLAN

DDSLAN

RTI Routing Service

ComProcessor

IPRouter

IPRouter

DDS over WAN

Secure DDS

over UDP

Attack Detector

Display

ScadaConverter

AnomalyDetector

Effective DNP3 connection

Details at http://blogs.rti.com

2014-Oct-1 © 2014 RTI

Support for Safety Critical Systems

77

DDS Inherently Well-Suited to Safety Critical Systems

• Non-stop availability– No single point of failure– …including run-time services– Support for redundant networks– Automatic failover between redundant publishers– Dynamic upgrades

• Visibility into missed deadlines and presence• Proven in hundreds of mission critical systems• Used in US DoD TRL 9 systems

2014-Oct-1 © 2014 RTI

78

High-Assurance Safety: DO-178C

• Guideline• Used by FAA as basis

for certification– Aircraft are “certified”– Software code

developed underDO-178 provides “certification evidence”

• Increasingly adopted for military aircraft• Likely required for UAS integration into NAS

2014-Oct-1 © 2014 RTI

79

DO-178 Safety Levels

Level Failure Condition Typical % of avionics code

A Catastrophic(may be total loss of aircraft) 15%

B Hazardous/Severe(serious injuries) 35%

C Major(minor injuries) 30%

D Minor(inconvenience) 15%

E No effect 5%

2014-Oct-1 © 2014 RTI

80

Certification Costs

• Generation of DO-178C evidence typically costs $50-$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

2014-Oct-1 © 2014 RTI

©

DO-178C Software Life Cycle Data

System Requirements

High-LevelRequirements

Low-LevelRequirements

SourceCode

Executable Object Code

SoftwareArchitecture

© 2014 RTI81

©

Test Strategy

Requirements-Based Test Selection

Requirements-Based Test Coverage Analysis

Structural Coverage Analysis

© 2014 RTI82

83

Tenets Of Safety-Critical Software

• Reduce code size• Consider testability in design• Design code to be deterministic

2014-Oct-1 © 2014 RTI

84

Connext DDS Cert

• Small footprint, certifiable DDS– ~25K ELOC– No dynamic memory allocation– Static endpoint discovery only

• Follows OMG DDS specification– C and C++ APIs– Subset of minimum profile

• Application portability and interoperability with full DDS– Including Routing Service

• Compatible with RTI’s FACE interface• DO-178C Level A certification available 1H 20152014-Oct-1 © 2014 RTI

85

DO-178C Level A Certification Evidence

• Plan for Software Aspects of Certification (PSAC)

• Software Development Plan (SDP)– Requirements standards– Design standards– Code standards

• Software Verification Plan (SVP)• Software Configuration

Management Plan (SCM)• Software Quality Assurance Plan

• Software Requirements Data• Design Description• Traceability• SQA Records• SCM Records• Software Configuration Index• Software Verification Cases and

Procedures• Software Verification Results• Software Accomplishment

Summary

Certification evidence can be re-used across programs2014-Oct-1 © 2014 RTI

86

Savings from DDS Certification Evidence

30,000 ELOC 20,000 ELOC 10,000 ELOC

Level A $3,000,000 $2,000,000 $1,000,000

Level B $2,550,000 $1,700,000 $850,000

Level C $1,800,000 $1,200,000 $600,000

• DDS certification evidence available at fraction of cost

• Availability at start of project also reduces risk

2014-Oct-1 © 2014 RTI

87

Summary

• Certifiable DDS designed for safety-critical applications now available– Connext DDS Cert– Standards compliant– Small footprint

• Code is certifiable to DO-178 Level A– Minimal lines of code– Deterministic

• Certification evidence is reusable

2014-Oct-1 © 2014 RTI

UCS and FACE

UAS Control Segment (UCS) Architecture

UCS Technical Reference Model

DDS has a number of desirable technical characteristics for use in real-time systems and real-time control problems. It has demonstrated very low latency or time delay and message delivery between DDS nodes. It can also be implemented without the use of intermediate-level nodes or servers, which reduces system requirements and complexity. DDS has already been adopted and incorporated into the UAS I IPT common grounds control ‑system standard.

93 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088

The FACE approach is a government-industry software standard and business strategy to:• Acquire affordable software systems• Rapidly integrate portable capabilities across global

defense programs• Attract innovation and deploy it quickly and affordably

FACE Approach

94 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088

Transitioning to Open Interface Architecture

Closed/Proprietary Open

* http://www.forbes.com/sites/darcytravlos/2012/08/22/five-reasons-why-google-android-versus-apple-ios-market-share-numbers-dont-matter/ 2014-Oct-1

© 2014 RTI94

95 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088

FACE Architecture - Layered Architecture Example

96

DDS Benefits for FACE

• Loose coupling of publish/subscribe• Flexible communication: 11,

1many, many1, manymany• Proximity and physical transport

independence• Easy integration with non-FACE apps• FACE TSS is thin layer over DDS

– Less than 2,000 SLOC– DDS already supports FACE data model (IDL),

serialization and deserialization– Expeditious path to DO-178C certification

• Tooling2014-Oct-1 © 2014 RTI

97

TSS Connection Mechanism Comparison

RTI DDS

CORBA

Sockets

POSIX

Queues

Shared

memory

Queuing

ports

Sampling

ports

Proximity Intra-partition ● ● ● ● ● ● ●Inter-partition ● ● ● ● ●Inter-node ● ● ●Multiple concurrently ●

Distribution One-to-one ● ● ● ● ● ● ●One-to-many ● ● ● ● ●Many-to-one ● ● ●Many-to-many ● ●

● Unreliable

2014-Oct-1 © 2014 RTI

98

Airborne System

Airborne System

Flexible IntegrationIncluding TSS andNative DDS Apps

FACEUoP

FACEUoP

Local Communication

TSS Library TSS Library

Routing Service

FACEUoP

FACEUoP

Local Communication

TSS Library TSS Library

Routing Service

DDSApp

DDSApp

Local Communication

DDS Library DDS Library

Routing Service

Ground System

2014-Oct-1 © 2014 RTI

99

DDS and FACE™ TSS Demo

Android app using DDS to publish data from the

tablet’s sensors

Simulated cockpit display receiving data through FACE

Transport Services Segment (TSS)

2014-Oct-1 © 2014 RTI

100

Esterel SCADE generated C AppJava App

Demo Stack

RTI Connext DDS Micro

RTI implementation of FACE TSS

DDS-RTPS Wire Interoperability Protocol

ARM CPU PowerPC CPU

Wind River VxWorks 653 OS

RTI Connext DDS Professional

Android OS

2014-Oct-1 © 2014 RTI

101

Esterel SCADE generated C AppJava App

Interoperability at Multiple LayersAll Application Transparent

RTI Connext DDS Micro

RTI implementation of FACE TSS

DDS-RTPS Wire Interoperability Protocol

ARM CPU PowerPC CPU

Wind River VxWorks 653 OS

RTI Connext DDS Professional

Android OS

Java ↔ C

DDS API ↔ FACE TSS API

Android ↔ VxWorks 653

ARM ↔ PowerPC

2014-Oct-1 © 2014 RTI

RTI Connext DDS

103

DDS StandardInteroperability

PortabilityReal-time QoS

DDS Differentiation

2014-Oct-1 © 2014 RTI

104

Secure CertMicroProfessional

Connext DDS Product Family

DDS-RTPS Wire Interoperability Protocol

Full DDS Libraries

Routing Service

Database Integration

DDSSubset

DDS SubsetDO-178C Certifiable

Admin Console

Monitoring

Microsoft Excel

Recording

Replay

Wireshark

Persistence

Logging

Prototyper

General Purpose& Real-Time Apps

Remote Apps Existing Apps and Devices

Adapter

Small Footprint Apps

High Assurance Apps

JMS API

Security Plugins

2014-Oct-1 © 2014 RTI

Application Code

Data Types

Data-Centric Publish/Subscribe

Automatic Discovery

HistoryCache

Monitoring

Local & rem

ote APIs

Quality of Svc

API & file-based

Operating System and Network StackWindows, Linux, Unix, embedded, mobile, RTOS

Interface Compiler

Interface Definitions• IDL• XML

Shared M

emory

UD

Pv4 & v6

ucast & m

cast

TLS & DTLS

(SSL)

WAN

TCP

Custom

Pluggable Transport Interface

C, C++, C#, Java, Ada, Lua, LabVIEW, Simulink, Python

Generated

DDS APIs – event-driven, polled & SQL query

Reliability • DDS-RTPS Wire Protocol

Dynamically defined (API) Custom Pre-defined

<XML>

Plugins

Fully dynamicStatic endpointServer Based

Low

Bandwidth

<XML>UML

MATLAB

Request/reply, Guaranteed Messaging, JMS

Security

Plugins

AuthenticationEncryption

Access ControlTaggingLogging

2014-Oct-1 © 2014 RTI 105

Custom

Q&A and Discussion

107

Next Steps – Learn More

• Contact RTI– Demo, Q&A

• Download software– www.rti.com/downloads– Free trial with comprehensive tutorial– RTI Shapes Demo

• Watch videos & webinars, read whitepapers– www.rti.com/resources– www.youtube.com/realtimeinnovations

2014-Oct-1 © 2014 RTI

108

www.rti.com

community.rti.com

demo.rti.com

www.youtube.com/realtimeinnovations

blogs.rti.com

www.twitter.com/RealTimeInnov

www.facebook.com/RTIsoftware

dds.omg.org

www.omg.org

www.slideshare.net/GerardoPardowww.slideshare.net/RealTimeInnovations

2014-Oct-1 © 2014 RTI

109

Summary

• Adoption of OA is essential– Affordability – Competitiveness

• DDS is well-suited for OA– Loose coupling– Meets real-time, mission-critical requirements– Leading-edge security and safety– Proven foundation– Eases existing system migration/modernization

• RTI Connext provides a robust DDS solution2014-Oct-1 © 2014 RTI

Thank You!