Build Safe and Secure Distributed Systems
Download as PPTX, PDF1 like912 views
The document discusses RTI and its Data Distribution Service (DDS) middleware. DDS provides publish-subscribe communication that is decentralized, scalable, and supports real-time and mission-critical systems. It addresses challenges with traditional approaches that are point-to-point and have single points of failure. DDS is used widely in industries such as defense, automotive, and medical. The document also covers open architecture requirements and how DDS supports security features to address cyber threats.
![Prototyper with LUA (Experimental)
XML
Settings
Prototyper (“Container”)
Lua Engine
1. -- Interface: parameters, inputs, outputs
2. local A, B, C = 30, 30, 10 -- Change the 'C' parameter to to see various flower shapes
3. local ShapeWriter = CONTAINER.WRITER[3] -- Triangles
4.
5. -- Global counter (preserved across invocations)
6. if not count then count = 0 else count = count + 1 end
7.
8. local shape = ShapeWriter.instance;9. local angle = count % 360;
Lua
10.
11. shape['x'] = 120 + (A+B) * math.cos(angle) + B * math.cos((A/B-C)*angle)
12. shape['y'] Component
= 120 + (A+B) * math.sin(angle) + B * math.sin((A/B-C)*angle)
13.
14. shape['shapesize'] = 5
15. shape['color'] = "RED"
16.
17. ShapeWriter:write()
DDS](https://image.slidesharecdn.com/rtidahlgrenroadshow2014-10-01public-141006164357-conversion-gate01/85/Build-Safe-and-Secure-Distributed-Systems-125-320.jpg)
Build Safe and Secure Distributed Systems
- 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
- 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: 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
- 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. 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 107
- 108. Request-Reply Request Request Topic Requestor Replier Reply Topic Reply 2014-Oct-1 © 2014 RTI 108
- 109. Correlation 2 1 Requests Replier Replies 3 3 1 2 Message ID Correlation 1 1 Requestor Correlation ID 2014-Oct-1 © 2014 RTI 109
- 110. Single-Request Multiple-Reply Requestor Replier 1 2 3 Replies Sequence ID Request 2014-Oct-1 © 2014 RTI 110
- 111. Multiple Repliers Requester Replier A Replier B Replier C Request Reply 2014-Oct-1 © 2014 RTI 111
- 112. Guaranteed Delivery Publisher Message Message Disk App-level ack Message Subscriber Durable Subscriber Message 2014-Oct-1 © 2014 RTI 112
- 113. Combining Patterns Request Subscriber Request Topic Requestor Replier Reply Topic Reply Subscriber Wire Tap 2014-Oct-1 © 2014 RTI 113
- 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 Eclipse 2014-Oct-1 114
- 116. 5.0 Migration Considerations • Wire interoperable with 4.5e and greater Except: – Configuration required for large data with 4.4c and earlier – Shared memory • Source code changes: – Custom content filters API – Generated type support code (if customized) – C++ dynamic data initialization – Name and location of default QoS profile – Other rare situations (see release notes) 2014-Oct-1 © 2014 RTI 116
- 117. Introduced in 5.1
- 118. XTypes: Mutable Types 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 y; //@ID 3 long z; //@ID 4 }; @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.
- 119. XTypes: Optional Members @Extensibility(MUTABLE_E XTENSIBILITY) struct TrackData { long id; long x; long y; long z; //@Optional }; typedef struct TrackData { DDS_Long id; DDS_Long x; DDS_Long y; DDS_Long * z; }; NULL value means there is no value because logically the value is not there C/C++ Bandwidth overhead per member FINAL/EXTENSIBLE MUTABLE SET 4/12-byte HEADER + VALUE 4/12-byte HEADER + VALUE NOT SET 4/12-byte HEADER 0-byte
- 120. Builtin QoS Profiles Baseline Generic BASELINE_ ROOT BASELINE BASELINE_ 5_0_0 BASELINE_ 5_1_0 GENERIC_ COMMON GENERIC_ MONITORING GENERIC__ CONNEXT_MICRO _COMPATIBILITY GENERIC_ CONNEXT_OTHER DDS_VENDOR_ COMPATIBILITY Pattern PERIODIC_DATA STREAMING RELIABLE_ STREAMING ALARM_EVENT EVENT ALARM_STATUS STATUS LAST_VALUE_ CACHE Experimental Basic KEEP_LAST_ RELIABLE STRICT_RELIIABLE_LOW _LATENCY KEEP_LAST_RELIABLE_ TRANSIENT_LOCAL KEEP_LAST_RELIABLE_ TRANSIENT KEEP_LAST_RELIABLE_ PERSISTENT STRICT_RELIABLE_LARGE_ DATA_FAST_FLOW STRICT_RELIABLE_LARGE_ DATA_MEDIUM_FLOW STRICT_RELIABLE_LARGE_ DATA_SLOW_FLOW KEEP_LAST_RELIABLE_ LARGE_DATA_FAST_FLO W KEEP_LAST_RELIABLE_LAR GE_DATA_MEDIUM_ FLOW KEEP_LAST_RELIABLE_ LARGE_DATA_SLOW_ FLOW STRICT_RELIABLE BEST_EFFORT STRICT_RELIABLE_ HIGH_THROUGHPUT Durability Large Data PARTICIPANT_ LARGE_DATA STRICT_RELIABLE_ LARGE_DATA PARTICIPANT_LARGE_ DATA_MONITORING KEEP_LAST_RELIABLE _ LARGE_DATA Performance AUTO_TUNING Large Data with Flow Control
- 121. UDPv4 NAT Support • New way to traverse WAN • New UDPv4 transport property dds.transport.UDPv4.builtin.public_address to provide IP address to be announced to other DomainParticipants DomainParticipant 1 © 2014 REAL-TIME INNOVATIONS, INC. UDPv4 Transport Dst IP: 10.10.1.4 Unicast discovery locator: 10.10.1.3:21410 Unicast user-data locator: 10.10.1.3:21411 DomainParticipant 2 192.168.1.1 10.10.1.4 10.10.1.3 Port: 21411 Address: 192.168.1.1 NAT
- 122. Routing Service – Content Filter Propagation Connext DDS 5.1 DataWriter DataWriter DataReader DataReader DataReader X=1 X=6 X=8 DataWriter 1 2 3 DataWriter 6 7 8 1 6 8 DataReader DataReader DataReader 1 6 8 DR DW
- 123. Turbo Mode (Experimental) DataWriter Batching Disabled Samples written Time Samples sent Connext DDS 5.0 • Only during higher frequency will data be batched to trade away low latency in favor of better throughput • Measures frequency every N samples DataWriter Turbo Mode Enabled Time Samples written Samples sent High frequency Low frequency Connext DDS 5.1 Low throughput! DataWriter Batching Enabled Time Samples written Samples sent Finite max_flush_delay High latency! High latency!
- 124. Auto Throttle (Experimental) • Motivation – When system condition changes, automatically adjust QoS to maintain optimal performance – Improves latency average and jitter in high throughput conditions
- 125. Prototyper with LUA (Experimental) XML Settings Prototyper (“Container”) Lua Engine 1. -- Interface: parameters, inputs, outputs 2. local A, B, C = 30, 30, 10 -- Change the 'C' parameter to to see various flower shapes 3. local ShapeWriter = CONTAINER.WRITER[3] -- Triangles 4. 5. -- Global counter (preserved across invocations) 6. if not count then count = 0 else count = count + 1 end 7. 8. local shape = ShapeWriter.instance;9. local angle = count % 360; Lua 10. 11. shape['x'] = 120 + (A+B) * math.cos(angle) + B * math.cos((A/B-C)*angle) 12. shape['y'] Component = 120 + (A+B) * math.sin(angle) + B * math.sin((A/B-C)*angle) 13. 14. shape['shapesize'] = 5 15. shape['color'] = "RED" 16. 17. ShapeWriter:write() DDS
- 126. Admin Console RTI Services Administration (5.0.0) Debugging (5.1.0) Admin Console Infrastructure Eclipse RCP DDS
- 127. 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
- 128. 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/realtimeinnovatio ns 2014-Oct-1 © 2014 RTI 129
- 130. dds.omg.org www.rti.com community.rti.com demo.rti.com www.youtube.com/realtimeinnovations blogs.rti.com www.twitter.com/RealTimeInnov www.facebook.com/RTIsoftware www.omg.org www.slideshare.net/GerardoPardo www.slideshare.net/RealTimeInnovations 2014-Oct-1 © 2014 RTI 130
- 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 solution 2014-Oct-1 © 2014 RTI 131
- 132. Thank You!