build safe and secure distributed systems
DESCRIPTION
Slides presented at the Dahlgren Road Show.TRANSCRIPT
Your systems. Working as one.
Build Safe & Secure Distributed SystemsMeet DoD Open Architecture Requirements and Cyber Security Guidance
Topics
• Introductions• Open Architecture• Data Distribution Service (DDS)• DDS security• DDS safety• DDS in UCS and FACE• RTI Connext DDS• Q&A
2014-Oct-1 2© 2014 RTI
3
Why is RTI?
To enable and realize the potential ofsmart machines to serve mankind
2014-Oct-1 © 2014 RTI
4
RTI Enables the Industrial Internet
• Real-time IIoT communication platform
• Proven across industries • Sensor-to-cloud integration
© 2014 RTI
Connext DDS
2014-Oct-1
5
About RTI
• Market Leader– 1,000+ projects use Connext DDS– Over 70% DDS middleware market share1
– Largest embedded middleware vendor2
– 2013 Gartner Cool Vendor for technology andOpen Community Source model
• Standards Leader– Active in 15 standards efforts– DDS authors, chair, wire spec, security, more– IIC steering committee; OMG board
• Team Quality Leader– Stanford research pedigree– High-performance, control, systems experts– Top quality product, processes, execution
© 2014 RTI
1Embedded Market Forecasters2VDC Analyst Report
2014-Oct-1
6
IIoT Infrastructure Trusts RTI
• World’s largest Wind Power company• World’s largest Underground Mining Equipment company• World’s largest Navy (all surface ships)• World’s largest Automotive company• World’s largest Emergency Medical System company• World’s largest Medical Imaging provider• World’s 2nd largest Patient Monitoring manufacturer• World’s 2nd largest Air Traffic control system• World’s largest Broadcast Video Equipment manufacturer• World’s largest Launch Control System• World’s largest Telescope (under construction)• World’s 5th-largest Oil & Gas company• World’s 6th-largest power plant (largest in US)• All of world’s top ten defense companies
RTI designed into over $1 trillion
2014-Oct-1 © 2014 RTI
7
RTI Named Most Influential IIoT Company
2014-Oct-1 © 2014 RTI
82008
Global Support and Distribution
© 2014 RTI2014-Oct-1
Open Architecture
102014-Oct-1 © 2014 RTI
11
Reality
2014-Oct-1 © 2014 RTI
12
Imperative
• Affordability
• “Do more with less”
2014-Oct-1 © 2014 RTI
13
How
• Improve reuse• Reduce maintenance and integration time
– Incremental upgrades– New technology insertion– System of Systems
• Promote competition– Reduce costs– Foster innovation
2014-Oct-1 © 2014 RTI
14
Traditional Approach
2014-Oct-1 © 2014 RTI
15
Traditional Approach
?
2014-Oct-1 © 2014 RTI
16
Traditional Approach
2014-Oct-1 © 2014 RTI
17
Traditional Approach
• Hard coded connections
• Up to O(n2)• Complex• Hard to maintain,
evolve, re-use
E.g., sockets, RPC
2014-Oct-1 © 2014 RTI
18
Result
Time & cost of integration,
maintenance and upgrades
System Scale and Age
O(n2)
2014-Oct-1 © 2014 RTI
19
Solution: Modularity
2014-Oct-1 © 2014 RTI
20
Key: Interoperability
Well-defined:• Interfaces• Semantics
2014-Oct-1 © 2014 RTI
21
Implementation Challenges
• Demanding technical requirements– Real-time performance– Reliability, safety, survivability– Dynamic and ad hoc
environments– Unreliable networks
• Migrating existing systems– OA versus other development
and funding priorities2014-Oct-1 © 2014 RTI
Data Distribution Service
Designed for the Industrial Internet of Things
23
For loose coupling, provides:• Discovery• Routing• High-availability• QoS enforcement
• Well-define interfaces
• Standard interoperability Protocol
Data Distribution Service
2014-Oct-1 © 2014 RTI
24
DDS Standard
• Interoperability and portability– Data model specification and
discovery– Network protocol– Programming interface
• Managed by Object Management Group (OMG)
Cross-vendor source portability
Cross-vendor interoperability
Standard Protocol
DDS Implementation
Standard APIData
Model
2014-Oct-1 © 2014 RTI
25
Peer-to-Peer Communication
• Completely decentralized• No intermediate servers,
message brokers or ESB
• Low latency• High scalability• No single point of failure
DDS-RTPS Wire Interoperability Protocol
App or Component
DDS Library
App or Component
DDS LibraryDDSAPI
2014-Oct-1 © 2014 RTI
26
Easy Integration of Existing Components
Unmodified App
DDS-RTPS Wire Interoperability Protocol
DDS Routing Service
Adapter
Unmodified App
DDS Routing Service
AdapterApp or
Component
DDS Library
App or Component
DDS Library
DDS or other protocol
DDSAPI
New and Updated Applications Existing, Unmodified Applications
2014-Oct-1 © 2014 RTI
27
Seamless Enterprise-Wide ConnectivityConnect Everything, Everywhere
• Proximity• Platform• Language
• Physical network• Transport protocol• Network topology
Data Distribution Service
Seamless data sharing regardless of:
2014-Oct-1 © 2014 RTI
28
Example: RTI Connext Availability
• Programming languages and environments
– C, C++, C#/.NET, Java, Ada– Lua, Python– LabVIEW, MATLAB, Simulink, UML– REST/HTTP
• Operating systems– Windows, Linux, Unix, Mac OS– Mobile– Embedded, real time– Safety critical, partitioned
• Processor families– x86, ARM, PowerPC…– 32- and 64-bit
• Transport types– Shared memory– LAN (incl. multicast)– WAN / Internet– Wireless– Low bandwidth
Completely application transparent2014-Oct-1 © 2014 RTI
29
Foundation: Publish/Subscribe
Data Distribution Service
Sens
or D
ata
Control App
Com
man
ds
Stat
usSensor
Sens
or D
ata
Actuator
Com
man
ds
Stat
us
Sensor
Sens
or D
ata
Display App
Sens
or D
ata
Stat
us
2014-Oct-1 © 2014 RTI
30
Support for Mission-Critical Systems
• Autonomous operation– Automatic discovery– No sys admin or centralized
infrastructure• Non-stop: no single point of failure• QoS control and visibility into
real time behavior, system health‑• Embeddable• RTI Connext is TRL 9
2014-Oct-1 © 2014 RTI
Why Distribution Middleware?
8.0 Training
5.0 Communications
2.0 Sensors
3.0 Fusion
4.0 BMC2
7.0 Visualization
6.0 Sensor Control
1.0 Common Services
Grouping the modules into functional clusters does nothing to change that reality and ease software integration
UNCLASSIFIED
Hawkeye has functionally oriented software modules
Each module talks to many other modules
RIP TRK MSIWAC TDA
ESM SAFERDR IFF
SEN DSCL4 L16L11
HMI ACIS
DIA NAV IPCCMCPMUX
FIL TDM
Adding new functionality cascades integration re-work across many other modules
CEC
8.0 Training
5.0 Communications
2.0 Sensors
3.0 Fusion
4.0 BMC2
7.0 Visualization
6.0 Sensor Control
1.0 Common Services
RIP TRKCEC MSIWAC RAIDERTDA
DWC
CHAT
ESM SAFERDR IFF
SEN DSCD
istributed Data Fram
ework
IPv6L4 L16L11
HMI ACIS T4O
DIA NAV IPCCMCPMUX
FIL TDM aADNS TIS
1.0 Common Services
Changing the communication between the modules can ease integration, when the new ‘Publish Subscribe’ approach is used – each module publishes its output w/o regard to who is receiving it, in contrast to the point-to-point approach of traditional inter-process communication
It’s about an architecture that can assimilate evolving functionality, rather than remaining set in time
33
US Army Asset Tracking System
Next-Gen Capability:• 50K lines of code—order
of magnitude less• 1 yr to develop—8x less• 1 laptop—20x less• Achieved: 250K+ tracked
updates/sec, no single point of failure
Legacy Capability:• 500K lines of code• 8 yrs to develop• 21 servers• Achieved: 20K tracked
updates/sec, reliability and uptime challenges
“This would not have been possible with any other known technology.”—Network Ops Center Technical Lead
2014-Oct-1 © 2014 RTI
34
RPC over DDS
2014DDSSecurity
2014Web-EnabledDDS
2013
DDS: Family of Specifications
DDSImplementation
Network / TCP / UDP / IP
App
DDSImplementation
App
DDSImplementation
DDS Spec
2004
DDSInteroperablity
2006
UML Profilefor DDS
2008
DDS forLw CCM
2009
DDS X-Types
2010 2012
DDS-STD-C++DDS-JAVA5
App
2014-Oct-1 © 2014 RTI
35
RTI RoleRTI Role Product Status
Core DDS API DCPS author 1st implementation
DDS-RTPS Protocol Sole author 1st implementation
Based on IEC 61148, which was authored by RTI and Schneider Automation
DDS-XTypes Primary author 1st implementation Based on prior RTI innovation
DDS C++ PSM RFP author; specification co-author EAR available now
DDS Java PSM Sole author Under development
DDS Security Primary author EAR available nowWeb-enabled DDS Primary author EAR available now
2014-Oct-1 © 2014 RTI
36
RTI Role
RTI Role Product Status
UML Profile for DDS Co-submitter
1st implementation (3rd-parties)
Standard being refined
DDS for lwCCM Co-submitter
1st implementation (3rd-party)
RPC over DDS Primary author
Submission based on current capability
Standard still under development
Instrumentation RFP author Prototype now
2014-Oct-1 © 2014 RTI
37
Broad Adoption and Support
• RTI Connext alone used by 1,000+ projects• ~14 implementations• 9 vendors have demonstrated interoperability
2014-Oct-1 © 2014 RTI
38
Interoperability Demonstration
OCI ETRI PrismTech IBM RTI Twin Oaks
2014-Oct-1 © 2014 RTI
DDS Compared to Alternative Approaches
40
Traditional IT and Consumer
• Limited scalability and performance– Capacity of individual links and switch ports– CPU and resource limits on servers
• Poor robustness– Tied to server maintenance and failures– Single point of vulnerability
• Lessens capabilities and utility– Single centralized “brain”– No autonomy. Lack of intelligence at the edge.
• Centralized ESB or Message Broker
• E.g.: MQTT, XMPP, AMQP, CoAP, Web Services
2014-Oct-1 © 2014 RTI
41
DDS:Distributed Analytics & Control at the Edge
• Analyze orders of magnitude more data• Lower latency control for faster response• Highly resilient, no single point of failure• Fine-grained access control and security• Vastly more capable: Intelligence at the edge
IT
Same Internet, but new WEB
2014-Oct-1 © 2014 RTI
42
Comparison
2014-Oct-1 © 2014 RTI
DDS DBMS RESTCoAP
MQTT AMQP XMPP
Standard wire protocol ✔ ✔ ✔ ✔ ✔Publish/Subscribe (event-driven) ✔ ✔ ✔ ✔Explicit, discoverable interfaces ✔ ✔Type safe (std/disc data encoding) ✔ ✔ ✔ I/S XML
Standard API ✔ ✔ (JMS)
Managed state (single src of truth) ✔ ✔ last
Data-level Quality of Service ✔Content filtering (routing) ✔ ✔ I/S
Time-based filtering ✔ I/L
Decentralized (no failure pt, bottleneck) ✔ Fed
Autonomous (no admin) ✔
N/A=Not Applicable, M/O=Metadata Only, I/S=Implementation Specific, I/L=within Integration Logic
DDS Security
45
Q4 2013 Reported Cyber Incidents toU.S. Critical Infrastructure
http://ics-cert.us-cert.gov/monitors/ICS-MM201312
2014-Oct-1 © 2014 RTI
46
Threats
2014-Oct-1 © 2014 RTI
47
ThreatsAlice: Allowed to publish topic TBob: Allowed to subscribe to topic TEve: Non-authorized eavesdropper Trudy: IntruderTrent: Trusted infrastructure serviceMallory: Malicious insider
1. Unauthorized subscription2. Unauthorized publication3. Tampering and replay 4. Unauthorized access to data
by infrastructure services
2014-Oct-1 © 2014 RTI
48
Security Terms: a Safe-Deposit Box
• Authentication: The bank knows who youare. You must show ID.
• Access Control: The bank only lets thoseon an access list into your box.
• Confidentiality: You are alone in the room. Nobody can see the contents of the box.
• Integrity: The box is sealed. If anybody touches it you will know.
• Non repudiation: You sign when you come in and out so you can’t claim that you weren’t there.
• Availability: The bank is always open. 2014-Oct-1 © 2014 RTI
49
Security Boundaries
System Boundary
Transport
Data
2014-Oct-1 © 2014 RTI
50
System Boundary
• Across security domains• Independent of how data is secured within a
system
System 1
• Diode• Filter• Downgrade
System 2Cross-
Domain Guard
2014-Oct-1 © 2014 RTI
51
Transport Layer
ExistingApp
TCP/IP Capable Network
DDS Routing Service
Adapter
ExistingApp
DDS Routing Service
Adapter
NativeDDS App
DDS Library
NativeDDS APP
DDS Library
Secure Transport
Secure Transport
Secure Transport
Secure Transport
Typically SSL, TLS or DTLS
2014-Oct-1 © 2014 RTI
52
Secure Data Transfer
1. Authenticate– Verify identity
2. Securely exchange cryptographic keys3. Use keys to:
– Encrypt data– Add a message authentication code
App 1 App 2
2014-Oct-1 © 2014 RTI
53
Secure Channel for Cross-Network Bridging
System 1LAN
Routing Service
System 2LAN
Routing Service
TLSWAN/
Internet
Can be used with or without
a firewall
2014-Oct-1 © 2014 RTI
54
Connecting Clients Across a WAN
• Remote access to cloud or data center– Clients communicate with participants in data center or
cloud LAN, not with each other– Clients behind firewalls– Only one public address required
• Example: Exposing a service to end-user clients
Remote App
Routing Service
Remote App
Remote App
TLS
2014-Oct-1 © 2014 RTI
55
Limitations of Transport Security:No Inherent Access Control
• You’re authenticated or you’re not• Less an issue for centralized systems
– E.g.: non-real-time IT and consumer IoT systems– Broker centrally manages access control
Device
App App App
Device Device
Message Broker
• Poor performance and scalability
• Single point of failure/failover
2014-Oct-1 © 2014 RTI
56
Limitations of Transport Security:Overall Poor Performance and Scalability
• No multicast support (even with DTLS over UDP)– Broad data distribution is very inefficient
• Usually runs over TCP: poor latency and jitter• Requires a network robust enough to support IP and
TCP• All data treated as reliable
– Even fast changing data that could be “best effort”• Always encrypts all data, metadata and protocol
headers– Even if some data does not have to be private
• Security is at a very gross level2014-Oct-1 © 2014 RTI
57
Introducing DDS Security
First security standard to address performance, safety and security requirements of
mission critical and real-time systems‑
Secure DDS
Sensors Actuators
Streaming Analytics &
ControlHMI/UI IT, Cloud & SoS
Connectivity
2014-Oct-1 © 2014 RTI
58
DDS Security
• Security extensions to DDS standard• Requires trivial or no change to existing
DDS apps and adapters• Runs over any transport
– Including low bandwidth, unreliable– Does not require TCP or IP– Multicast for scalability, low latency
• Plugin architecture– Built-in defaults– Customizable via standard API
• Completely decentralized– High performance and scalability– No single point of failure
Secure DDSlibrary
Authentication
Access Control
Encryption
Data Tagging
Logging
Application
Any Transport(e.g., TCP, UDP, multicast,
shared memory, )
2014-Oct-1 © 2014 RTI
59
Network
Connext DDSlibrary
Authentication
Access Control
Encryption
Data Tagging
Logging
Application
Transport(e.g., TCP, UDP, multicast,
shared memory)
Secu
rity
Plug
ins
Connext DDSlibrary
Authentication
Access Control
Encryption
Data Tagging
Logging
Application
Transport
Connext DDSlibrary
Authentication
Access Control
Encryption
Data Tagging
Logging
Application
Transport
2014-Oct-1 © 2014 RTI
Service Plugin
Purpose Interactions
Authentication
Authenticate the principal that is joining a DDS Domain.
Handshake and establish shared secret between participants
The principal may be an application/process or the user associated with that application or process.
Participants do mutual authentication and establish shared secret
Access Control
Decide whether a principal is allowed to perform a protected operation.
Protected operations include joining a specific DDS domain, creating a Topic, reading a Topic, writing a Topic, etc.
Cryptography
Perform the encryption and decryption operations. Create & Exchange Keys. Compute digests, compute and verify Message Authentication Codes. Sign and verify signatures of messages.
Invoked by DDS middleware to encrypt data, compute and verify MAC, compute & verify Digital Signatures
Logging Log all security relevant events
Invoked by middleware to log
Data Tagging
Add a data tag for each data sample
61
Standard CapabilitiesAuthentication X.509 Public Key Infrastructure (PKI) with a pre-configured
shared Certificate Authority (CA) Digital Signature Algorithm (DSA) with Diffie-Hellman and
RSA for authentication and key exchange
Access Control Specified via permissions file signed by shared CA Control over ability to join systems, read or write data topics
Cryptography Protected key distribution AES128 and AES256 for encryption HMAC-SHA1 and HMAC-SHA256 for message authentication
and integrity
Data Tagging Tags specify security metadata, such as classification level Can be used to determine access privileges (via plugin)
Logging Log security events to a file or distribute securely over Connext DDS
2014-Oct-1 © 2014 RTI
62
Security FlowDomain
Participant Create Fails
AuthenticateDP?Yes
AuthenticateDP?
No
Ignore Remote DP
AuthenticateRemote DP?
No
Yes
No
Yes
Access OK?Ignore remote
endpoint
Message security
Endpoint Create Fails
YesAccess OK?
No
Create Domain
Participant
Create Endpoints
Discover remote
Endpoints
Send/Receive data
Discover remote DP
2014-Oct-1 © 2014 RTI
63
Protections
Protected Objects
Domain (by domain_id)Topic (by Topic name)DataObjects (by Instance/Key)
Protected Operations
Domain.joinTopic.createTopic.read (includes QoS)Topic.write (includes QoS)Data.createInstanceData.writeInstanceData.deleteInstance
2014-Oct-1 © 2014 RTI
64
Control over Encryption
• Scope– Discovery data– Metadata– Data
• For each:– Encrypt– Sign
• Optimizes performance by only encrypting data that must be private
2014-Oct-1 © 2014 RTI
65
Example Domain Governance
2014-Oct-1 © 2014 RTI
66
Example Permissions
2014-Oct-1 © 2014 RTI
67
DDS Security Status
• Specification adopted March 2014– Considered “Beta” for 1 year– RTI chairing Finalization Task Force
• Specification provides a framework for securing DDS systems– Built-in plugins provide a common approach for
applications without specialized requirements– Custom plugins can be developed to match more
specialized deployments and integrate with existing infrastructure and hardware
• Early Access Release available now from RTI2014-Oct-1 © 2014 RTI
68
Specification Reviewers Include:
• GE• Intel• Siemens• Technicolor• NSWC• General Dynamics
• THALES• SAAB• Cassidian• QinetiQ & UK MOD• Lockheed• Raytheon
• None found any show stoppers• Several contacted OMG to urge adoption
2014-Oct-1 © 2014 RTI
USS SecureThe USS SECURE cybersecurity test bed is a collaboration between the National Security Agency, Department of Defense Information Assurance Range Quantico, Combat Systems Direction Activity Dam Neck, NSWCDD, NSWC Carderock/Philadelphia, Office of Naval Research, Johns Hopkins University Applied Physics Lab, and Real Time Innovations Inc.
• The objective of USS SECURE is to immunize a warfare system against the effects of a cyberattack and to rapidly recover when the system is impacted.
• USS SECURE's test bed determines the best combination of cyberdefense technologies to secure a naval combatant without impacting real time deadline scheduled performance requirements.
• The DoN IM/IT and Cyberspace mission is to provide effective, efficient, trusted and shared Information Management/Information Technology cyberspace and IRM capabilities to support the Navy, Marine Corps and their mission partners conducting global military and business operations.
http://www.navy.mil/submit/display.asp?story_id=79228
2014-Oct-1 © 2014 RTI 69
USS Secure• "This test bed enables us to develop, evaluate and test cybersecurity concepts and
technologies to defend mission critical systems at sea and ashore," said Simonoff.
• "The USS SECURE has led a series of cybersecurity and cyberengineering 'firsts' for NSWCDD and has helped position the command as a leader and innovator for cybersecurity solutions that will benefit not only our Navy but the Department of Defense community at large," said Nerney.
• "For the Navy, USS SECURE means increasing maneuverability in cyberspace to execute the assigned mission, undeterred by a cyberattack," said Simonoff. "For the Dept. of Defense, the nation is well served because America's Navy stands available 24/7, even in the face of a cyberattack."
2014-Oct-1 © 2014 RTI 70
Security Example:Power Grid
In Partnership with PNNL
© 2014 RTI
72
Data Security Requirements
Data Item Authentica-tion
Access Control
Integrity Non-repudiation
Confidentiality
Control traffic X X X X X
Data Telemetry traffic
X X
Physical Security Data
X X X
Engineering maintenance
X
Source: www.sxc.hu
2014-Oct-1 © 2014 RTI
73
Test Environment
• Real World Environment– Transmission switching
substation– Real substation equipment
• PNNL powerNET Testbed– Remote connectivity– Local control room
demonstration environment– Dynamically reconfigurable
2014-Oct-1 © 2014 RTI
74
SCADA Equipment Setup
2014-Oct-1 © 2014 RTI
75
Control Station
DNP3 MasterDevice
Transmission Substation
DNP3 Slave
Device
RTI and PNNL Grid Security Retrofit
RTI Routing Service
ComProcessor
RTI Routing Service
Gateway
DNP3 Slave
Device
DNP3 overRS232/485
DNP3 overEthernet DNP3 over DDS
RTI Routing Service
Gateway
DDSLAN
DDSLAN
RTI Routing Service
ComProcessor
IPRouter
IPRouter
DDS over WAN
Secure DDS
over UDP
Attack Detector
Display
ScadaConverter
AnomalyDetector
Effective DNP3 connection
Details at http://blogs.rti.com
2014-Oct-1 © 2014 RTI
Support for Safety Critical Systems
77
DDS Inherently Well-Suited to Safety Critical Systems
• Non-stop availability– No single point of failure– …including run-time services– Support for redundant networks– Automatic failover between redundant publishers– Dynamic upgrades
• Visibility into missed deadlines and presence• Proven in hundreds of mission critical systems• Used in US DoD TRL 9 systems
2014-Oct-1 © 2014 RTI
78
High-Assurance Safety: DO-178C
• Guideline• Used by FAA as basis
for certification– Aircraft are “certified”– Software code
developed underDO-178 provides “certification evidence”
• Increasingly adopted for military aircraft• Likely required for UAS integration into NAS
2014-Oct-1 © 2014 RTI
79
DO-178 Safety Levels
Level Failure Condition Typical % of avionics code
A Catastrophic(may be total loss of aircraft) 15%
B Hazardous/Severe(serious injuries) 35%
C Major(minor injuries) 30%
D Minor(inconvenience) 15%
E No effect 5%
2014-Oct-1 © 2014 RTI
80
Certification Costs
• Generation of DO-178C evidence typically costs $50-$100 per ELOC
• Process objectives must be met
• All must be documented• Code must be clean
– Testable– No dead code– Deterministic
Level Process Objectives
Code Coverage
A 71 Level B and 100% of MCDC
B 69 Level C plus 100% of DC
C 62 Level D plus 100% of SC
D 26 100% of Requirements
E 0 None
2014-Oct-1 © 2014 RTI
©
DO-178C Software Life Cycle Data
System Requirements
High-LevelRequirements
Low-LevelRequirements
SourceCode
Executable Object Code
SoftwareArchitecture
© 2014 RTI81
©
Test Strategy
Requirements-Based Test Selection
Requirements-Based Test Coverage Analysis
Structural Coverage Analysis
© 2014 RTI82
83
Tenets Of Safety-Critical Software
• Reduce code size• Consider testability in design• Design code to be deterministic
2014-Oct-1 © 2014 RTI
84
Connext DDS Cert
• Small footprint, certifiable DDS– ~25K ELOC– No dynamic memory allocation– Static endpoint discovery only
• Follows OMG DDS specification– C and C++ APIs– Subset of minimum profile
• Application portability and interoperability with full DDS– Including Routing Service
• Compatible with RTI’s FACE interface• DO-178C Level A certification available 1H 20152014-Oct-1 © 2014 RTI
85
DO-178C Level A Certification Evidence
• Plan for Software Aspects of Certification (PSAC)
• Software Development Plan (SDP)– Requirements standards– Design standards– Code standards
• Software Verification Plan (SVP)• Software Configuration
Management Plan (SCM)• Software Quality Assurance Plan
• Software Requirements Data• Design Description• Traceability• SQA Records• SCM Records• Software Configuration Index• Software Verification Cases and
Procedures• Software Verification Results• Software Accomplishment
Summary
Certification evidence can be re-used across programs2014-Oct-1 © 2014 RTI
86
Savings from DDS Certification Evidence
30,000 ELOC 20,000 ELOC 10,000 ELOC
Level A $3,000,000 $2,000,000 $1,000,000
Level B $2,550,000 $1,700,000 $850,000
Level C $1,800,000 $1,200,000 $600,000
• DDS certification evidence available at fraction of cost
• Availability at start of project also reduces risk
2014-Oct-1 © 2014 RTI
87
Summary
• Certifiable DDS designed for safety-critical applications now available– Connext DDS Cert– Standards compliant– Small footprint
• Code is certifiable to DO-178 Level A– Minimal lines of code– Deterministic
• Certification evidence is reusable
2014-Oct-1 © 2014 RTI
UCS and FACE
UAS Control Segment (UCS) Architecture
UCS Technical Reference Model
DDS has a number of desirable technical characteristics for use in real-time systems and real-time control problems. It has demonstrated very low latency or time delay and message delivery between DDS nodes. It can also be implemented without the use of intermediate-level nodes or servers, which reduces system requirements and complexity. DDS has already been adopted and incorporated into the UAS I IPT common grounds control ‑system standard.
93 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088
The FACE approach is a government-industry software standard and business strategy to:• Acquire affordable software systems• Rapidly integrate portable capabilities across global
defense programs• Attract innovation and deploy it quickly and affordably
FACE Approach
94 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088
Transitioning to Open Interface Architecture
Closed/Proprietary Open
* http://www.forbes.com/sites/darcytravlos/2012/08/22/five-reasons-why-google-android-versus-apple-ios-market-share-numbers-dont-matter/ 2014-Oct-1
© 2014 RTI94
95 http://www.opengroup.org/face Distro A, Approved for Public Release NAVAIR 2014-088
FACE Architecture - Layered Architecture Example
96
DDS Benefits for FACE
• Loose coupling of publish/subscribe• Flexible communication: 11,
1many, many1, manymany• Proximity and physical transport
independence• Easy integration with non-FACE apps• FACE TSS is thin layer over DDS
– Less than 2,000 SLOC– DDS already supports FACE data model (IDL),
serialization and deserialization– Expeditious path to DO-178C certification
• Tooling2014-Oct-1 © 2014 RTI
97
TSS Connection Mechanism Comparison
RTI DDS
CORBA
Sockets
POSIX
Queues
Shared
memory
Queuing
ports
Sampling
ports
Proximity Intra-partition ● ● ● ● ● ● ●Inter-partition ● ● ● ● ●Inter-node ● ● ●Multiple concurrently ●
Distribution One-to-one ● ● ● ● ● ● ●One-to-many ● ● ● ● ●Many-to-one ● ● ●Many-to-many ● ●
● Unreliable
2014-Oct-1 © 2014 RTI
98
Airborne System
Airborne System
Flexible IntegrationIncluding TSS andNative DDS Apps
FACEUoP
FACEUoP
Local Communication
TSS Library TSS Library
Routing Service
FACEUoP
FACEUoP
Local Communication
TSS Library TSS Library
Routing Service
DDSApp
DDSApp
Local Communication
DDS Library DDS Library
Routing Service
Ground System
2014-Oct-1 © 2014 RTI
99
DDS and FACE™ TSS Demo
Android app using DDS to publish data from the
tablet’s sensors
Simulated cockpit display receiving data through FACE
Transport Services Segment (TSS)
2014-Oct-1 © 2014 RTI
100
Esterel SCADE generated C AppJava App
Demo Stack
RTI Connext DDS Micro
RTI implementation of FACE TSS
DDS-RTPS Wire Interoperability Protocol
ARM CPU PowerPC CPU
Wind River VxWorks 653 OS
RTI Connext DDS Professional
Android OS
2014-Oct-1 © 2014 RTI
101
Esterel SCADE generated C AppJava App
Interoperability at Multiple LayersAll Application Transparent
RTI Connext DDS Micro
RTI implementation of FACE TSS
DDS-RTPS Wire Interoperability Protocol
ARM CPU PowerPC CPU
Wind River VxWorks 653 OS
RTI Connext DDS Professional
Android OS
Java ↔ C
DDS API ↔ FACE TSS API
Android ↔ VxWorks 653
ARM ↔ PowerPC
2014-Oct-1 © 2014 RTI
RTI Connext DDS
103
DDS StandardInteroperability
PortabilityReal-time QoS
DDS Differentiation
2014-Oct-1 © 2014 RTI
104
Secure CertMicroProfessional
Connext DDS Product Family
DDS-RTPS Wire Interoperability Protocol
Full DDS Libraries
Routing Service
Database Integration
DDSSubset
DDS SubsetDO-178C Certifiable
Admin Console
Monitoring
Microsoft Excel
Recording
Replay
Wireshark
Persistence
Logging
Prototyper
General Purpose& Real-Time Apps
Remote Apps Existing Apps and Devices
Adapter
Small Footprint Apps
High Assurance Apps
JMS API
Security Plugins
2014-Oct-1 © 2014 RTI
Application Code
Data Types
Data-Centric Publish/Subscribe
Automatic Discovery
HistoryCache
Monitoring
Local & rem
ote APIs
Quality of Svc
API & file-based
Operating System and Network StackWindows, Linux, Unix, embedded, mobile, RTOS
Interface Compiler
Interface Definitions• IDL• XML
Shared M
emory
UD
Pv4 & v6
ucast & m
cast
TLS & DTLS
(SSL)
WAN
TCP
Custom
Pluggable Transport Interface
C, C++, C#, Java, Ada, Lua, LabVIEW, Simulink, Python
Generated
DDS APIs – event-driven, polled & SQL query
Reliability • DDS-RTPS Wire Protocol
Dynamically defined (API) Custom Pre-defined
<XML>
Plugins
Fully dynamicStatic endpointServer Based
Low
Bandwidth
<XML>UML
MATLAB
Request/reply, Guaranteed Messaging, JMS
Security
Plugins
AuthenticationEncryption
Access ControlTaggingLogging
2014-Oct-1 © 2014 RTI 105
Custom
Introduced in 5.0
107
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
108
Request-Reply
Requestor Replier
RequestRequest
Topic
ReplyTopic Reply
2014-Oct-1 © 2014 RTI
109
Correlation
ReplierRequests
Replies
3
3
2 1
21
Message ID
Correlation ID
1
1
Requestor
Correlation
2014-Oct-1 © 2014 RTI
110
Single-Request Multiple-Reply
Requestor Replier
Replies
321
Sequence ID
Request
2014-Oct-1 © 2014 RTI
111
Multiple Repliers
Requester
Replier A
Replier C
Replier B
Request
Reply
2014-Oct-1 © 2014 RTI
112
Guaranteed Delivery
Publisher
Message
Disk
Message
Message
Subscriber
Durable Subscriber
Message
App-level ack
2014-Oct-1 © 2014 RTI
113
Combining Patterns
Requestor Replier
RequestRequest
Topic
ReplyTopic Reply
Subscriber
Subscriber
Wire Tap
2014-Oct-1 © 2014 RTI
114
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 Eclipse2014-Oct-1
116
5.0 Migration Considerations
• Wire interoperable with 4.5e and greaterExcept:– 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
Introduced in 5.1
@Extensibility(Mutable_EXTENSIBILITY)struct TrackData { long id; //@ID 1 long x; //@ID 2 long y; //@ID 3};
@Extensibility(Mutable_EXTENSIBILITY)struct TrackData { long id; //@ID 1 long x; //@ID 2 long y; //@ID 3 long z; //@ID 4};
Connext DDS 5.1
@Extensibility(Mutable_EXTENSIBILITY)struct TrackData { long id; //@ID 1 long x; //@ID 2 long y; //@ID 3};
@Extensibility(Mutable_EXTENSIBILITY)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: Mutable Types
XTypes: Optional Members
@Extensibility(MUTABLE_EXTENSIBILITY)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 memberFINAL/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_ROOT
BASELINE_5_0_0
BASELINE
BASELINE_5_1_0
GENERIC_COMMON
GENERIC_MONITORING
GENERIC__CONNEXT_MICRO_COMPATIBILITY
GENERIC_CONNEXT_OTHER
DDS_VENDOR_COMPATIBILITY
Baseline Generic
PERIODIC_DATA
RELIABLE_STREAMING
STREAMING
EVENT
STATUS
ALARM_EVENT
ALARM_STATUS
LAST_VALUE_CACHE
Pattern
Experimental
KEEP_LAST_RELIABLE_TRANSIENT_LOCAL
KEEP_LAST_RELIABLE_TRANSIENT
KEEP_LAST_RELIABLE_PERSISTENT
STRICT_RELIABLE_LARGE_DATA_FAST_FLOW
STRICT_RELIABLE_LARGE_DATA_MEDIUM_FLOW
STRICT_RELIABLE_LARGE_DATA_SLOW_FLOW
KEEP_LAST_RELIABLE_LARGE_DATA_FAST_FLO
W
KEEP_LAST_RELIABLE_LARGE_DATA_MEDIUM_
FLOW
KEEP_LAST_RELIABLE_LARGE_DATA_SLOW_
FLOW
STRICT_RELIABLE
BEST_EFFORT
KEEP_LAST_RELIABLE
STRICT_RELIABLE_HIGH_THROUGHPUT
STRICT_RELIIABLE_LOW_LATENCY
Basic
Durability
PARTICIPANT_LARGE_DATA
PARTICIPANT_LARGE_DATA_MONITORING
STRICT_RELIABLE_LARGE_DATA
KEEP_LAST_RELIABLE_
LARGE_DATA
AUTO_TUNING
Large Data
Performance
Large Data withFlow Control
DomainParticipant 1
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
© 2014 REAL-TIME INNOVATIONS, INC.
UDPv4 Transport
Dst IP: 10.10.1.4
Unicast discovery locator: 10.10.1.3:21410Unicast 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
DataWriter
1 2 3
876
1 86DataReader
DataReader
DataReader
1
6
8
DR DW
Turbo Mode (Experimental)
DataWriter Batching DisabledSamples 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
XMLSettings
Prototyper (“Container”)
Lua Engine
DDS
Lua Component
Prototyper with LUA (Experimental)
Admin Console
Eclipse RCP DDS
Admin Console Infrastructure
RTI ServicesAdministration
(5.0.0)
Debugging(5.1.0)
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
Q&A and Discussion
129
Next Steps – Learn More
• Contact RTI– Demo, Q&A
• Download software– www.rti.com/downloads– Free trial with comprehensive tutorial– RTI Shapes Demo
• Watch videos & webinars, read whitepapers– www.rti.com/resources– www.youtube.com/realtimeinnovations
2014-Oct-1 © 2014 RTI
130
www.rti.com
community.rti.com
demo.rti.com
www.youtube.com/realtimeinnovations
blogs.rti.com
www.twitter.com/RealTimeInnov
www.facebook.com/RTIsoftware
dds.omg.org
www.omg.org
www.slideshare.net/GerardoPardowww.slideshare.net/RealTimeInnovations
2014-Oct-1 © 2014 RTI
131
Summary
• Adoption of OA is essential– Affordability – Competitiveness
• DDS is well-suited for OA– Loose coupling– Meets real-time, mission-critical requirements– Leading-edge security and safety– Proven foundation– Eases existing system migration/modernization
• RTI Connext provides a robust DDS solution2014-Oct-1 © 2014 RTI
Thank You!