Slides presented at the Columbia Road Show - 2014 10-02

1. Your systems. Working as one.
Build Safe & Secure Distributed Systems
Meet DoD Open Architecture Requirements and Cyber Security Guidance

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

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

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

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

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 6

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

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

9. Open Architecture

10. 2014-Oct-1 © 2014 RTI 10

11. Reality
2014-Oct-1 © 2014 RTI 11

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

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 13

14. Traditional Approach
2014-Oct-1 © 2014 RTI 14

15. Traditional Approach
2014-Oct-1 © 2014 RTI 15

16. Traditional Approach
2014-Oct-1 © 2014 RTI 16

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 17

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

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

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

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

22. 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 23

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
Standard API
Data
Model
DDS Implementation
Standard Protocol
Cross-vendor interoperability
2014-Oct-1 © 2014 RTI 24

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

26. Easy Integration of Existing Components
Unmodified
App
Adapter
DDS Routing
Service
DDS-RTPS Wire Interoperability Protocol
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

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

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

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

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 30

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

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 33

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

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

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 36

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 37

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

39. DDS Compared to
Alternative Approaches

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

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

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

43. DDS Security

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

46. Threats
2014-Oct-1 © 2014 RTI 46

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

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

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

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

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

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

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

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

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

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

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

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

59. 2014-Oct-1 © 2014 RTI 59

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

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

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

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

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 64

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

66. Example Permissions
2014-Oct-1 © 2014 RTI 66

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

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 68

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

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

71. Security Example:
Power Grid
In Partnership with PNNL
© 2014 RTI

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

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 73

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

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

76. 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 77

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

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 79

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 80

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

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

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

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

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

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 86

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 87

88. UCS and FACE

89. UAS Control Segment (UCS) Architecture

90. UCS Technical Reference Model

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

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

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

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

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 97

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

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 99

100. 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
DDS-RTPS Wire Interoperability Protocol
Android OS
2014-Oct-1 © 2014 RTI 100

101. 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
DDS-RTPS Wire Interoperability Protocol
Android OS
Java ↔ C
DDS API ↔ FACE TSS API
Android ↔ VxWorks 653
ARM ↔ PowerPC
2014-Oct-1 © 2014 RTI 101

102. RTI Connext DDS

103. DDS Differentiation
DDS Standard
Interoperability
Portability
Real-time QoS
2014-Oct-1 © 2014 RTI 103

104. Connext DDS Product Family
Secure Professional Micro Cert
DDS-RTPS Wire Interoperability Protocol
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

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

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

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

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

110. Thank You!