Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DDS Enabling Open Architecture


Published on

Even though the U.S. Department of Defense budget is shrinking and the country's military footprint worldwide is receding the need for the warfighter to have accurate and actionable intelligence has never been more critical. Data from Intelligence, Surveillance, and Reconnaissance (C4ISR) systems such as radar, image processing payloads on Unmanned Aerial Vehicles, and more will be used and fused together to provide commanders with real-time situational awareness. Each system will also need to embrace open architectures and the latest commercial standards to meet the DoD's performance, size, and cost requirements. This e-cast will discuss how embedded defense suppliers are meeting these challenges.

Published in: Technology, Business
  • Be the first to comment

DDS Enabling Open Architecture

  1. 1. Your systems. Working as one. DDS: Enabling Open Architecture David Barnett | | @rtidavid December 4, 2013
  2. 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. 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
  4. 4. Cost Constrains Integration and Limits Data Sharing Time & cost of integration, maintenance and upgrades System Scale and Age December 4, 2013 © 2013 RTI 4
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Your systems. Working as one. Thank You!