Build Safe and Secure Distributed Systems

Your systems. Working as one.
Build Safe & Secure Distributed Systems
Meet 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 © 2014 RTI 2

Why is RTI?
To enable and realize the potential of
smart machines to serve mankind
2014-Oct-1 © 2014 RTI 3

RTI Enables the Industrial Internet
• Real-time IIoT
communication platform
• Proven across industries
• Sensor-to-cloud integration
2014-Oct-1 © 2014 RTI 4

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 and
Open 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 Forecasters
2VDC Analyst Report
2014-Oct-1 5

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 6

RTI Named Most Influential IIoT Company
2014-Oct-1 © 2014 RTI 7

2008
Global Support and Distribution
2014-Oct-1 © 2014 RTI 8

Reality
2014-Oct-1 © 2014 RTI 11

Imperative
• Affordability
• “Do more with less”
2014-Oct-1 © 2014 RTI 12

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 13

Traditional Approach
2014-Oct-1 © 2014 RTI 14

• Hard coded
connections
• Up to O(n2)
• Complex
• Hard to maintain,
evolve, re-use
E.g., sockets, RPC
2014-Oct-1 © 2014 RTI 17

Result
Time & cost of
integration,
maintenance
and upgrades
System Scale and Age
O(n2)
2014-Oct-1 © 2014 RTI 18

Solution: Modularity
2014-Oct-1 © 2014 RTI 19

Key: Interoperability
Well-defined:
• Interfaces
• Semantics
2014-Oct-1 © 2014 RTI 20

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 priorities
2014-Oct-1 © 2014 RTI 21

Data Distribution Service
Designed for the Industrial Internet of Things

For loose coupling, provides:
• Discovery
• Routing
• High-availability
• QoS enforcement
• Well-define interfaces
• Standard interoperability
Protocol
2014-Oct-1 © 2014 RTI 23

DDS Standard
• Interoperability and
portability
– Data model specification
and discovery
– Network protocol
– Programming interface
• Managed by Object
Management Group (OMG)
Cross-vendor source portability
Standard API
Data
Model
DDS Implementation
Standard Protocol
Cross-vendor interoperability
2014-Oct-1 © 2014 RTI 24

Peer-to-Peer Communication
DDS-RTPS Wire Interoperability Protocol
• Completely decentralized
• No intermediate servers,
message brokers or ESB
• Low latency
• High scalability
• No single point of failure
App or
Component
DDS Library
App or
Component
DDS Library
DDS
API
2014-Oct-1 © 2014 RTI 25

Easy Integration of Existing Components
Unmodified
App
Adapter
DDS Routing
Service
Unmodified
App
Adapter
DDS Routing
Service
App or
Component
DDS Library
App or
Component
DDS Library
DDS or other protocol
DDS
API
New and Updated Applications Existing, Unmodified Applications
2014-Oct-1 © 2014 RTI 26

Seamless Enterprise-Wide Connectivity
Connect Everything, Everywhere
Seamless data sharing regardless of:
• Proximity
• Platform
• Language
• Physical network
• Transport protocol
• Network topology
2014-Oct-1 © 2014 RTI 27

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
2014-Oct-1 © 2014 RTI 28

Foundation: Publish/Subscribe
Commands
Control
App
Sensor Data
Sensor
Sensor Data
Display
App
Sensor Actuator
2014-Oct-1 © 2014 RTI 29

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 30

Why Distribution Middleware?
1.0 Common Services
1.0 Common Services
RDR IFF ESM SAFE
RDR IFF ESM SAFE
DIA NAV MCP IPCC
DIA NAV MCP IPCC
DWC
 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 MSI
WAC TDA
L4 L11 L16 SEN DSC
HMI ACIS
MUX
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
RIP CEC TRK MSI
WAC TDA RAIDER
CHAT
SEN DSC
Distributed Data Framework
L4 L11 L16 IPv6
HMI ACIS T4O
MUX
FIL TDM aADNS TIS
 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

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 33

2014
RPC
over DDS
2014
DDS
Securit
y
DDS: Family of Specifications
2013
Web-Enabled
DDS
DDS
2008
2009
Implementation
Network / TCP / UDP / IP
App
DDS
Implementation
App
DDS
Implementation
2010 2012
DDS Spec
2004
DDS
2006
Interoperablity
UML Profile
for DDS
DDS for
Lw CCM
DDS
X-Types
DDS-STD-C++
DDS-JAVA5
App
2014-Oct-1 © 2014 RTI 34

RTI Role
RTI 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 now
Web-enabled DDS Primary author EAR available now
2014-Oct-1 © 2014 RTI 35

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 36

Broad Adoption and Support
• RTI Connext alone used by 1,000+ projects
• ~14 implementations
• 9 vendors have demonstrated interoperability
2014-Oct-1 © 2014 RTI 37

Interoperability Demonstration
OCI ETRI PrismTech IBM RTI Twin Oaks
2014-Oct-1 © 2014 RTI 38

DDS Compared to
Alternative Approaches

Traditional IT and Consumer
• Centralized ESB or Message
Broker
• E.g.: MQTT, XMPP, AMQP,
CoAP, Web Services
• 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.
2014-Oct-1 © 2014 RTI 40

DDS:
Distributed Analytics & Control at the Edge
IT
• 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
Same
Internet,
but new
WEB
2014-Oct-1 © 2014 RTI 41

Comparison
DD
S
DBM
S
REST
CoAP
MQTT AMQ
P
XMP
P
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
2014-Oct-1 © 2014 RTI 42

Q4 2013 Reported Cyber Incidents to
U.S. Critical Infrastructure
http://ics-cert.us-cert.gov/monitors/ICS-MM201312
2014-Oct-1 © 2014 RTI 45

Threats
2014-Oct-1 © 2014 RTI 46

Threats
Alice: Allowed to publish topic T
Bob: Allowed to subscribe to topic T
Eve: Non-authorized eavesdropper
Trudy: Intruder
Trent: Trusted infrastructure service
Mallory: Malicious insider
1. Unauthorized subscription
2. Unauthorized publication
3. Tampering and replay
4. Unauthorized access to data by
infrastructure services
2014-Oct-1 © 2014 RTI 47

Security Terms: a Safe-Deposit Box
• Authentication: The bank knows who you
are. You must show ID.
• Access Control: The bank only lets those
on 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 48

Security Boundaries
System Boundary
Transport
Data
2014-Oct-1 © 2014 RTI 49

System Boundary
System 1
Cross-
Domain
Guard
• Diode
• Filter
• Downgrade
System 2
• Across security domains
• Independent of how data is secured within a
system
2014-Oct-1 © 2014 RTI 50

Transport Layer
Existing
App
Adapter
DDS Routing
Service
TCP/IP Capable Network
Existing
App
Adapter
DDS Routing
Service
Native
DDS App
DDS Library
Native
DDS APP
DDS Library
Secure
Transport
Secure
Transport
Secure
Transport
Secure
Transport
Typically SSL,
TLS or DTLS
2014-Oct-1 © 2014 RTI 51

Secure Data Transfer
1. Authenticate
– Verify identity
2. Securely exchange cryptographic keys
3. Use keys to:
– Encrypt data
– Add a message authentication code
App 1 App 2
2014-Oct-1 © 2014 RTI 52

Secure Channel for Cross-Network Bridging
System 1
LAN
Routing
Service
System 2
LAN
Routing
Service
TLS
WAN/
Internet
Can be used
with or without
a firewall
2014-Oct-1 © 2014 RTI 53

Connecting Clients Across a WAN
Remote
App
Routing
Service
Remote
App
Remote
App
TLS
• 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
2014-Oct-1 © 2014 RTI 54

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
App App App
Device
Message
Broker
Device Device
• Poor performance
and scalability
• Single point of
failure/failover
2014-Oct-1 © 2014 RTI 55

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 level
2014-Oct-1 © 2014 RTI 56

Introducing DDS Security
First security standard to address performance,
safety and security requirements of
mission-critical and real-time systems
HMI/UI IT, Cloud & SoS
Secure DDS
Streaming
Analytics &
Control
Connectivity
Sensors Actuators
2014-Oct-1 © 2014 RTI 57

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 DDS
library
Authentication
Access Control
Encryption
Data Tagging
Logging
Application
Any Transport
(e.g., TCP, UDP, multicast,
shared memory, )
2014-Oct-1 © 2014 RTI 58

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

Standard Capabilities
Authenticatio
n
 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 61

Security Flow
Domain
Participant
Create Fails
Authenticate
Authenticate
DP?
Yes DP?
No
Ignore
Remote DP
Authenticate
Remote DP?
No
Yes
No
Yes
Access OK?
Ignore
remote
endpoint
Message
security
Endpoint
Create Fails
Yes
Access OK?
No
Create
Domain
Participant
Create
Endpoints
Discover
remote DP
Discover
remote
Endpoints
Send/Receiv
e data
2014-Oct-1 © 2014 RTI 62

Protections
Protected
Objects
Domain (by domain_id)
Topic (by Topic name)
DataObjects (by Instance/Key)
Protected
Operations
Domain.join
Topic.create
Topic.read (includes QoS)
Topic.write (includes QoS)
Data.createInstance
Data.writeInstance
Data.deleteInstance
2014-Oct-1 © 2014 RTI 63

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 64

Example Domain Governance
2014-Oct-1 © 2014 RTI 65

Example Permissions
2014-Oct-1 © 2014 RTI 66

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 RTI
2014-Oct-1 © 2014 RTI 67

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 68

USS Secure
The 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 http://Inc.
www.navy.mil/submit/display.asp?story_id=79228
• 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.
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

Data Security Requirements
Data Item Authentica-tion
Access
Control
Integrity Non-repudiation
Confidentialit
y
Control traffic X X X X X
Data
X X
Telemetry
traffic
Physical
Security Data
X X X
Engineering
maintenance
X
Source: www.sxc.hu
2014-Oct-1 © 2014 RTI 72

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 73

SCADA Equipment Setup
2014-Oct-1 © 2014 RTI 74

RTI and PNNL Grid Security Retrofit
Control Station
DNP3
Master
Device
Transmission Substation
DNP3
Slave
Device
RTI Routing
Service
Gateway
RTI Routing
Service
ComProcessor
DNP3
Slave
Device
DNP3 over
Ethernet DNP3 over DDS
DNP3 over
RS232/485
RTI Routing
Service
Gateway
DDS
LAN
DDS
LAN
RTI Routing
Service
ComProcessor
IP
Router
IP
Router
DDS over WAN
Attack Detector
Scada
Converter
Anomaly
Detector
Secure DDS
over UDP
Display
Effective DNP3
connection
Details at http://blogs.rti.com
2014-Oct-1 © 2014 RTI 75

Support for Safety Critical
Systems

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 77

High-Assurance Safety: DO-178C
• Guideline
• Used by FAA as basis
for certification
– Aircraft are “certified”
– Software code
developed under
DO-178 provides “certification evidence”
• Increasingly adopted for military aircraft
• Likely required for UAS integration into NAS
2014-Oct-1 © 2014 RTI 78

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 79

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 80

DO-178C Software Life Cycle Data
  
©
System
Requirements
High-Level
Requirements
Low-Level
Requirements
Source
Code
Executable
Object Code
Software
Architecture
© 2014 RTI 81

Test Strategy
  
Requirements-Based Test Selection
©

Requirements-Based Test Coverage Analysis

Structural Coverage Analysis
© 2014 RTI 82

Tenets Of Safety-Critical Software
• Reduce code size
• Consider testability in design
• Design code to be deterministic
2014-Oct-1 © 2014 RTI 83

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 2015
2014-Oct-1 © 2014 RTI 84

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 programs
2014-Oct-1 © 2014 RTI 85

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 86

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 87

UAS Control Segment (UCS) Architecture

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.

FACE Approach
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
93 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088

Transitioning to Open
Interface Architecture
Closed/Proprietary Open
© 2014 RTI
* 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
94

FACE Architecture - Layered
Architecture Example

DDS Benefits for FACE
• Loose coupling of publish/subscribe
• Flexible communication: 11,
1many, many1, manymany
• 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
• Tooling
2014-Oct-1 © 2014 RTI 96

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 97

Airborne System
Flexible Integration
Including TSS and
Native DDS Apps
Airborne System
FACE
UoP
FACE
UoP
TSS Library TSS Library
Local Communication
Routing
Service
FACE
UoP
FACE
UoP
TSS Library TSS Library
Local Communication
Routing
Service
DDS
App
DDS
App
DDS Library DDS Library
Local Communication
Routing
Service
Ground System
2014-Oct-1 © 2014 RTI 98

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 99

Demo Stack
Java App Esterel SCADE generated C App
RTI Connext
DDS Micro
RTI implementation of FACE TSS
RTI Connext DDS Professional
Wind River VxWorks 653 OS
ARM CPU PowerPC CPU
Android OS
2014-Oct-1 © 2014 RTI 100

Interoperability at Multiple Layers
All Application Transparent
Java App Esterel SCADE generated C App
RTI Connext
DDS Micro
RTI implementation of FACE TSS
RTI Connext DDS Professional
Wind River VxWorks 653 OS
ARM CPU PowerPC CPU
Android OS
Java ↔ C
DDS API ↔ FACE TSS API
Android ↔ VxWorks 653
ARM ↔ PowerPC
2014-Oct-1 © 2014 RTI 101

Connext DDS Product Family
Secure Professional Micro Cert
Full DDS
Libraries
Routing
Service
Database
Integration
DDS
Subset
DDS Subset
DO-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 104

Application Code
Data Types
Dynamically
defined (API)
Custom Pre-defined
C, C++, C#, Java, Ada, Lua, LabVIEW, Simulink, Python
Data-Centric Publish/Subscribe
Automatic
Discovery
History
Cache
Monitoring
Local & remote APIs
Quality of Svc
API & file-based
Operating System and Network Stack
Windows, Linux, Unix, embedded, mobile, RTOS
Interface
Compiler
Interface Definitions
• IDL
• XML
Shared
Memory
UDPv4 & v6
ucast & mcast
TLS & DTLS
(SSL)
WAN
TCP
Custom
Pluggable Transport Interface
Generated
DDS APIs – event-driven, polled & SQL query
Reliability • DDS-RTPS Wire Protocol
<XML>
Plugins
Fully dynamic
Static endpoint
Server Based
Low
Bandwidth
<XML>
UML
MATLAB
Request/reply, Guaranteed Messaging, JMS
Security
Plugins
Authentication
Encryption
Access Control
Tagging
Logging
Custom
2014-Oct-1 © 2014 RTI 105

RTI Connext 5.0
• Expanded Enterprise Integration Patterns
– Request-Reply
– Guaranteed Messaging
– Application-level
Acknowledgement
• Enhanced scalability
• Type extensibility
• Infrastructure
Administration
2014-Oct-1 © 2014 RTI 107

Correlation
2 1
Requests Replier
Replies
3
3
1 2
Message ID
Correlation
1
1
Requestor
Correlation ID
2014-Oct-1 © 2014 RTI 109

Guaranteed Delivery
Publisher
Message
Message
Disk
App-level ack
Message
Subscriber
Durable
Subscriber
Message
2014-Oct-1 © 2014 RTI 112

Combining Patterns
Request
Subscriber
Request
Topic
Requestor Replier
Reply
Topic Reply
Subscriber
Wire Tap
2014-Oct-1 © 2014 RTI 113

Admin Console
© 2014 RTI
• Centralized console for infrastructure
• Dashboard summary of all running services
• Live status updates
• Live distributed logging
• Real-time statistics
• System Performance statistics (CPU and memory)
• Remote administration of Routing Service:
• GUI for sending remote commands
• Retrieving and updating current configurations
• Built-in XML editor for modifying configuration files
• Built on top of Eclipse
2014-Oct-1 114

5.0 Migration Considerations
• Wire interoperable with 4.5e and greater
Except:
– Configuration required for large data with 4.4c and
earlier
– Shared memory
• Source code changes:
– Custom content filters API
– Generated type support code (if customized)
– C++ dynamic data initialization
– Name and location of default QoS profile
– Other rare situations (see release notes)
2014-Oct-1 © 2014 RTI 116

XTypes: Mutable Types
Connext DDS 5.1
@Extensibility(Mutable_EXTENSIBILITY)
struct TrackData {
long id; //@ID 1
long x; //@ID 2
long y; //@ID 3
};
struct TrackData {
long id; //@ID 1
long x; //@ID 2
long y; //@ID 3
long z; //@ID 4
};
struct TrackData {
long id; //@ID 1
long x; //@ID 2
long y; //@ID 3
};
struct TrackData {
long id; //@ID 1
long x; //@ID 2
long z; //@ID 4
long y; //@ID 3
};
4-byte or 12-byte per member extra overhead on the wire.

XTypes: Optional Members
@Extensibility(MUTABLE_E
XTENSIBILITY)
struct TrackData {
long id;
long x;
long y;
long z; //@Optional
};
typedef struct TrackData {
DDS_Long id;
DDS_Long x;
DDS_Long y;
DDS_Long * z;
};
NULL value
means there is no
value because
logically the value
is not there
C/C++
Bandwidth overhead per member
FINAL/EXTENSIBLE MUTABLE
SET 4/12-byte HEADER + VALUE 4/12-byte HEADER + VALUE
NOT SET 4/12-byte HEADER 0-byte

Builtin QoS Profiles
Baseline Generic
BASELINE_
ROOT
BASELINE
BASELINE_
5_0_0
BASELINE_
5_1_0
GENERIC_
COMMON
GENERIC_
MONITORING
GENERIC__
CONNEXT_MICRO
_COMPATIBILITY
GENERIC_
CONNEXT_OTHER
DDS_VENDOR_
COMPATIBILITY
Pattern
PERIODIC_DATA
STREAMING
RELIABLE_
STREAMING
ALARM_EVENT
EVENT
ALARM_STATUS
STATUS
LAST_VALUE_
CACHE
Experimental
Basic
KEEP_LAST_
RELIABLE
STRICT_RELIIABLE_LOW
_LATENCY
KEEP_LAST_RELIABLE_
TRANSIENT_LOCAL
KEEP_LAST_RELIABLE_
TRANSIENT
KEEP_LAST_RELIABLE_
PERSISTENT
STRICT_RELIABLE_LARGE_
DATA_FAST_FLOW
DATA_MEDIUM_FLOW
DATA_SLOW_FLOW
KEEP_LAST_RELIABLE_
LARGE_DATA_FAST_FLO
W
KEEP_LAST_RELIABLE_LAR
GE_DATA_MEDIUM_
FLOW
KEEP_LAST_RELIABLE_
LARGE_DATA_SLOW_
FLOW
STRICT_RELIABLE
BEST_EFFORT
STRICT_RELIABLE_
HIGH_THROUGHPUT
Durability
Large Data
PARTICIPANT_
LARGE_DATA
STRICT_RELIABLE_
LARGE_DATA
PARTICIPANT_LARGE_
DATA_MONITORING
KEEP_LAST_RELIABLE
_
LARGE_DATA
Performance
AUTO_TUNING
Large Data with
Flow Control

UDPv4 NAT Support
• New way to traverse WAN
• New UDPv4 transport property
dds.transport.UDPv4.builtin.public_address to provide IP
address to be announced to other DomainParticipants
DomainParticipant 1
© 2014 REAL-TIME INNOVATIONS, INC.
UDPv4
Transport
Dst IP:
10.10.1.4
Unicast discovery locator:
10.10.1.3:21410
Unicast user-data locator:
10.10.1.3:21411
DomainParticipant 2
192.168.1.1
10.10.1.4
10.10.1.3
Port:
21411
Address:
192.168.1.1
NAT

Routing Service – Content Filter
Propagation
Connext DDS 5.1
DataWriter
DataWriter
DataReader
DataReader
DataReader
X=1
X=6
X=8
DataWriter
1 2 3
DataWriter
6 7 8
1 6 8
DataReader
DataReader
DataReader
1
6
8
DR DW

Turbo Mode (Experimental)
DataWriter Batching Disabled
Samples written
Time
Samples sent
Connext DDS 5.0
• Only during higher frequency will data
be batched to trade away low latency in
favor of better throughput
• Measures frequency every N samples
DataWriter Turbo Mode Enabled
Time
Samples written
Samples sent
High
frequency
Low
frequency
Connext DDS 5.1
Low throughput!
DataWriter Batching Enabled
Time
Samples written
Samples sent
Finite max_flush_delay
High latency! High latency!

Auto Throttle (Experimental)
• Motivation
– When system condition changes, automatically adjust
QoS to maintain optimal performance
– Improves latency average and jitter in high throughput
conditions

Prototyper with LUA (Experimental)
XML
Settings
Prototyper (“Container”)
Lua Engine
1. -- Interface: parameters, inputs, outputs
2. local A, B, C = 30, 30, 10 -- Change the 'C' parameter to to see various flower shapes
3. local ShapeWriter = CONTAINER.WRITER[3] -- Triangles
4.
5. -- Global counter (preserved across invocations)
6. if not count then count = 0 else count = count + 1 end
7.
8. local shape = ShapeWriter.instance;9. local angle = count % 360;
Lua

10.
11. shape['x'] = 120 + (A+B) * math.cos(angle) + B * math.cos((A/B-C)*angle)
12. shape['y'] Component
= 120 + (A+B) * math.sin(angle) + B * math.sin((A/B-C)*angle)
13.
14. shape['shapesize'] = 5
15. shape['color'] = "RED"
16.
17. ShapeWriter:write()
DDS

Admin Console
RTI Services
Administration
(5.0.0)
Debugging
(5.1.0)
Admin Console Infrastructure
Eclipse RCP DDS

5.1 Migration Considerations
• Transport:
– Default message_size_max for UDPv4, UDPv6, TCP, Secure WAN, and
shared-memory transports changed to provide better out-of-the-box
performance
• To go back to default 5.0.0 settings use built-in profile:
BuiltinQosLib::Baseline.5.0.0
• Integrity not affected by this change
• ContentFilteredTopics:
– JAVA with -package: DataWriters in 4.5x and below will not be able to
perform writer-side filtering for Connext 5.1.0 DataReaders using
ContentFilteredTopics
• package is not part of the TypeCode name anymore
• Code generation:
– Moving to 5.1.0 requires regenerating the code

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/realtimeinnovatio
ns
2014-Oct-1 © 2014 RTI 129

dds.omg.org
www.rti.com
community.rti.com
demo.rti.com
www.youtube.com/realtimeinnovations
blogs.rti.com
www.twitter.com/RealTimeInnov
www.facebook.com/RTIsoftware
www.omg.org
www.slideshare.net/GerardoPardo
www.slideshare.net/RealTimeInnovations
2014-Oct-1 © 2014 RTI 130

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 solution
2014-Oct-1 © 2014 RTI 131

Build Safe and Secure Distributed Systems

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Build Safe and Secure Distributed Systems

Similar to Build Safe and Secure Distributed Systems (20)

More from Real-Time Innovations (RTI)

More from Real-Time Innovations (RTI) (20)

Recently uploaded

Recently uploaded (20)

Build Safe and Secure Distributed Systems