DDS Enabling Open Architecture

1. Your systems. Working as one. DDS: Enabling Open Architecture David Barnett | david@rti.com | @rtidavid December 4, 2013

2. Challenge: Communication and Integration How Do Applications and Devices Share Data? System System of Systems Sensors Weapon Controller UI December 4, 2013 Mapping Mission Planning Vehicle Comms © 2013 RTI 2

3. Traditional Approach: Point-to-Point Integration • Explicit connections • Increasingly complex over time • Stovepipe and brittle • Poor reuse • Hard to reconfigure E.g., sockets, RPC December 4, 2013 © 2013 RTI 3

5. Solution: “Software Data Bus” S/W S/W S/W S/W Data Distribution Service • Software components are plug and play • Simple, loosely coupled architecture – No point-to-point integration logic December 4, 2013 © 2013 RTI • Scales to large projects and systems of systems – A modular, open architecture • Enables rapid reconfiguration 5

6. Foundation: Publish/Subscribe Sensor Sensor Commands Sensor Data Sensor Data Data Distribution Service Control App Display App Actuator Components are loosely-coupled, require no knowledge of each other December 4, 2013 © 2013 RTI 6

7. Data Distribution Service (DDS) Cross-vendor portability DDS API (Application Programming Interface) DDS Middleware DDS Real-Time Publish-Subscribe Wire Protocol (RTPS) • Open standard • Object Management Group (OMG) • At least 10 implementations • Designed for real-time, embedded, mission critical • Middleware and subsystem vendor independence Cross-vendor interoperability December 4, 2013 © 2013 RTI 7

8. Integration Scenarios New and Updated Applications Existing, Unmodified Applications Unmodified App DDS API App or Component App or Component DDS Library DDS Library Unmodified App DDS or other protocol Adapter DDS Routing Service Adapter DDS Routing Service DDS-RTPS Wire Interoperability Protocol • Completely decentralized • Components communicate peer-to-peer • No intermediate servers, message brokers, daemon processes December 4, 2013 © 2013 RTI 8

9. Broad Interoperability for Heterogeneous Systems • Programming languages and environments • Processor families – x86, ARM, PowerPC – 32- and 64-bit – C, C++, C#/.NET, Java, Ada – REST/HTTP • Transport types – LabVIEW, MATLAB, Simulink, UML – Shared memory • Operating systems – LAN (incl. multicast) – Windows, Linux, Unix, Mac OS – WAN – Embedded, real time, partitioned – Secure – Mobile – Low bandwidth December 4, 2013 © 2013 RTI 9

10. Future Airborne Capability Environment (FACE) Transport Services Segment (TSS) PCS Component PCS Component PSS Component PSS Component FACE TSS Transport Services API to DDS Mapping FACE Transport Services (TS) API OMG DDS API DDS Library Intraproces s Shared memor y ARINC Ports Sockets Other/ Custom Pluggable transports DDS-RTPS protocol FACE General Purpose or Security Profile (w/Connext DDS Cert) December 4, 2013 © 2013 RTI 10

11. Why Distribution Middleware? DIA DIA FIL FIL Each module talks to many other modules NAV NAV TDM TDM 3.0 Fusion CEC RIP CEC RIP MUX MUX MCP IPCC MCP IPCC aADNS TRK TRK 5.0 Communications L4 L11 L16 L4 L11 L16 7.0 Visualization ACIS HMI ACIS HMI TIS MSI MSI IPv6 Distributed Data Framework Hawkeye has functionally oriented software modules Adding new functionality cascades integration re-work across many other modules 2.0 Sensors IFF RDR IFF RDR 1.0 Common Services ESM ESM DWC 4.0 BMC2 WAC WAC SAFE SAFE TDA TDA RAIDER CHAT 6.0 Sensor Control SEN DSC SEN DSC 8.0 Training T4O Grouping the modules into functional clusters does nothing to change that reality and ease software integration 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 UNCLASSIFIED

12. Asset Tracking System Legacy Capability: 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 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 December 4, 2013 © 2013 RTI 12

13. About RTI • Communications middleware market leader – Largest embedded middleware vendor* – Over 70% commercial DDS market share* • Standards leader – Active in 15 standards efforts – OMG Board of Directors – DDS authors • Real-time pedigree – Founded by Stanford researchers – High-performance control, tools history • Maturity leader – 600+ designs. 400+ research projects – 400,000+ licensed copies – TRL 9 *Embedded Market Forecasters and Venture Development Corp (VDC) December 4, 2013 © 2013 RTI 13

14. RTI Connext DDS Product Family General Purpose, Real-Time Apps Small Footprint Apps Safety Critical Apps, up to DO178C Level A Disparate Apps/Systems DDS API Adapter General Purpose Micro Cert Routing Service DDS Superset DDS Subset DDS Subset Mediation, routing DDS-RTPS Wire Interoperability Administration Recording Monitoring Replay System Viz Logging Tools December 4, 2013 © 2013 RTI 14

15. Summary Open Architecture DDS • Cost-effective integration of larger systems and SoS • Reuse • Rapid reconfiguration • Improved data sharing and situational awareness • Software foundation for OA • Eliminates costly point-topoint integration • Provides seamless Interoperability – Subsystems – New and existing applications • Satisfies needs of missioncritical system December 4, 2013 © 2013 RTI 15

16. Your systems. Working as one. Thank You!

DDS Enabling Open Architecture

Real-Time Innovations (RTI)

DDS Enabling Open Architecture