More Related Content Similar to Build Safe and Secure Distributed Systems (20) More from Real-Time Innovations (RTI) (14) Build Safe and Secure Distributed Systems1. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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: 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
• 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
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
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