DDS, JMS, REST APIs
Data-Centric Publish/Subscribe
Pluggable Discovery
Reliability, Serialization, Transport
Persistence Service
Monitoring, Logging, Replay
Connext Messaging adds:
- Request/reply
- Guaranteed messaging
- JMS API
- Persistence
- Additional transports
- Security
- Future: REST API
It is built on top of Connext DDS for data distribution.
<XML>
Industrial Internet of Things: Protocols an StandardsJavier Povedano
Presentation for the Distributed Systems Master at the University of Cordoba (Spain). In this presentation we review the state of the art in communication middlewares for Industrial Internet of Things
Industrial Internet of Things: Protocols an StandardsJavier Povedano
Presentation for the Distributed Systems Master at the University of Cordoba (Spain). In this presentation we review the state of the art in communication middlewares for Industrial Internet of Things
Software Defined Networking (SDN) Technology BriefZivaro Inc
An overview of Software-Defined Networking (SDN) and the key benefits of moving to a virtualized network, including:
- Improved time to market through automation
- Optimal trafficking with a global view of the network
- Quicker enablement of new services
- Reduced operating costs
- Improved management and visibility
- Simplified operation of network devices
From "Introduction to Software Defined Networking" webinar presented by GTRI CTO Scott Hogg on March 10, 2016. Webinar recording: https://youtu.be/gRXnctYDBjE
Introduction to SDN: Software Defined NetworkingAnkita Mahajan
SDN is the next big thing in networking. It focuses on separating the intelligence from the hardware. OpenFlow is one of the ways (currently the open standard followed by all Datacenters) to implement SDN.
- SDN : Software defined network : Introduction & Basics
- Why we need SDN & Features of SDN
- SDN Role in Data and Forwarding Plane , Control Plane & Management Plane
- SDN Framework & Architecture
- Openflow Architecture
- Need of SDN
Introduction to SDN and Network Programmability - BRKRST-1014 | 2017/Las VegasBruno Teixeira
Jason Davis, Distinguished Services Engineer , Cisco Software-Defined Networking (SDN) is an exciting new approach to network IT Service Management. If you are trying to understand what SDN is and want to understand more about Controllers, APIs, Overlays, OpenFlow and ACI, then this introductory session is for you! We will cover the genesis of SDN, what it is, what it is not, and Cisco's involvement in this space. You may also be wondering what products and services are SDN-enabled and how you can solve your unique business challenges by enhancing and differentiating your services by leveraging network programmability. Cisco's SDN-enabled Products and Services will be explained enabling you to consider your own implementations. Since SDN extends network flexibility and functionality which impacts Network Engineering and Operations teams, we'll also cover the IT Service Management impact. Finally, we'll explore what skills and capabilities are needed to take advantage of SDN and Network Programmability. Network engineers, network operation staff, IT Service Managers, IT personnel managers, and application/compute SMEs will benefit from this session.
Class lecture by Prof. Raj Jain on Introduction to OpenFlow. The talk covers Planes of Networking, Data vs. Control Logic, OpenFlow: Key Ideas, History of OpenFlow, Separation of Control and Data Plane, OpenFlow V1.0, Matching, Counters, Actions, Hardware OpenFlow Switches, Software OpenFlow Switches, Open vSwitch, Open vSwitch Features, OVSDB, OpenFlow V1.1, OpenFlow Hardware Implementation, OpenFlow V1.2, OpenFlow 1.3, OpenFlow V1.4, Implementation Issues, Current Limitations of OpenFlow, OpenFlow Current Activities, Introduction to OpenFlow, Planes of Networking, Data vs. Control Logic, OpenFlow: Key Ideas, History of OpenFlow, Separation of Control and Data Plane, OpenFlow V1.0, Matching, Counters, Actions, Hardware OpenFlow Switches, Software OpenFlow Switches, Open vSwitch, Open vSwitch Features, OVSDB, OpenFlow V1.1, OpenFlow Hardware Implementation, OpenFlow V1.2, OpenFlow 1.3, OpenFlow V1.4, Implementation Issues, Current Limitations of OpenFlow, OpenFlow Current Activities. Video recording available in YouTube.
This presentation is an overview of OpenFlow and why it is relevant in creating programmable networks. Included are details on the protocol and examples of how applications and services can benefit from this.
View On Demand: http://ecast.opensystemsmedia.com/375
Top Three Reasons to Develop Your Next Distributed Application with DDS
Developing applications that can run over multiple cores, nodes or networks typically requires a significant amount of network-level programming. This low-level coding detracts from the implementation of application logic, introduces complexity, and is hard to maintain as requirements evolve and systems grow in scale. The challenges are particularly acute for real-time and embedded systems, which often have to address stringent timing, resource and reliability constraints.
Just as high-level programming languages and operating systems simplified application development by eliminating hardware dependencies, the Data Distribution Service (DDS) standard does the same for networking. DDS provides application developers with simple publish-subscribe programming interfaces that abstract out all the networking details. Application components simply publish the data they produce and subscribe to the data they consume. The DDS middleware handles all the networking and real-time Quality of Service details. Components can seamlessly communicate across different programming languages and processor families. Applications are also independent of the underlying transport protocol and network type, be it shared memory, a local area network, wide area network or even radio link.
View On-Demand :
http://ecast.opensystemsmedia.com/340
As distributed system scale up, so does their integration time and cost. This integration challenge is particularly acute for real-time and intelligent systems: increased connectivity cannot come at the expense of performance, reliability or resource consumption.
Adopting an inherently scalable architecture is the secret to agilely and affordably building systems that encompass ever more applications, nodes and real-time data. This webinar will review how you can apply proven integration techniques—such as loose coupling and service orientation—to demanding real-time systems. Unlike approaches designed for conventional business applications, the architecture we'll introduce is appropriate for systems that span embedded, high performance and IT applications.
This webinar targets software architects, chief engineers and development leads in all industries that design real-time and intelligent systems. This includes defense, industrial, transportation, medical and aerospace applications.
Better integration is increasingly the key to competitive advantage. It provides end-users with higher situational awareness, responsiveness and resource utilization. Don't let your architecture hold you back.
Software Defined Networking (SDN) Technology BriefZivaro Inc
An overview of Software-Defined Networking (SDN) and the key benefits of moving to a virtualized network, including:
- Improved time to market through automation
- Optimal trafficking with a global view of the network
- Quicker enablement of new services
- Reduced operating costs
- Improved management and visibility
- Simplified operation of network devices
From "Introduction to Software Defined Networking" webinar presented by GTRI CTO Scott Hogg on March 10, 2016. Webinar recording: https://youtu.be/gRXnctYDBjE
Introduction to SDN: Software Defined NetworkingAnkita Mahajan
SDN is the next big thing in networking. It focuses on separating the intelligence from the hardware. OpenFlow is one of the ways (currently the open standard followed by all Datacenters) to implement SDN.
- SDN : Software defined network : Introduction & Basics
- Why we need SDN & Features of SDN
- SDN Role in Data and Forwarding Plane , Control Plane & Management Plane
- SDN Framework & Architecture
- Openflow Architecture
- Need of SDN
Introduction to SDN and Network Programmability - BRKRST-1014 | 2017/Las VegasBruno Teixeira
Jason Davis, Distinguished Services Engineer , Cisco Software-Defined Networking (SDN) is an exciting new approach to network IT Service Management. If you are trying to understand what SDN is and want to understand more about Controllers, APIs, Overlays, OpenFlow and ACI, then this introductory session is for you! We will cover the genesis of SDN, what it is, what it is not, and Cisco's involvement in this space. You may also be wondering what products and services are SDN-enabled and how you can solve your unique business challenges by enhancing and differentiating your services by leveraging network programmability. Cisco's SDN-enabled Products and Services will be explained enabling you to consider your own implementations. Since SDN extends network flexibility and functionality which impacts Network Engineering and Operations teams, we'll also cover the IT Service Management impact. Finally, we'll explore what skills and capabilities are needed to take advantage of SDN and Network Programmability. Network engineers, network operation staff, IT Service Managers, IT personnel managers, and application/compute SMEs will benefit from this session.
Class lecture by Prof. Raj Jain on Introduction to OpenFlow. The talk covers Planes of Networking, Data vs. Control Logic, OpenFlow: Key Ideas, History of OpenFlow, Separation of Control and Data Plane, OpenFlow V1.0, Matching, Counters, Actions, Hardware OpenFlow Switches, Software OpenFlow Switches, Open vSwitch, Open vSwitch Features, OVSDB, OpenFlow V1.1, OpenFlow Hardware Implementation, OpenFlow V1.2, OpenFlow 1.3, OpenFlow V1.4, Implementation Issues, Current Limitations of OpenFlow, OpenFlow Current Activities, Introduction to OpenFlow, Planes of Networking, Data vs. Control Logic, OpenFlow: Key Ideas, History of OpenFlow, Separation of Control and Data Plane, OpenFlow V1.0, Matching, Counters, Actions, Hardware OpenFlow Switches, Software OpenFlow Switches, Open vSwitch, Open vSwitch Features, OVSDB, OpenFlow V1.1, OpenFlow Hardware Implementation, OpenFlow V1.2, OpenFlow 1.3, OpenFlow V1.4, Implementation Issues, Current Limitations of OpenFlow, OpenFlow Current Activities. Video recording available in YouTube.
This presentation is an overview of OpenFlow and why it is relevant in creating programmable networks. Included are details on the protocol and examples of how applications and services can benefit from this.
View On Demand: http://ecast.opensystemsmedia.com/375
Top Three Reasons to Develop Your Next Distributed Application with DDS
Developing applications that can run over multiple cores, nodes or networks typically requires a significant amount of network-level programming. This low-level coding detracts from the implementation of application logic, introduces complexity, and is hard to maintain as requirements evolve and systems grow in scale. The challenges are particularly acute for real-time and embedded systems, which often have to address stringent timing, resource and reliability constraints.
Just as high-level programming languages and operating systems simplified application development by eliminating hardware dependencies, the Data Distribution Service (DDS) standard does the same for networking. DDS provides application developers with simple publish-subscribe programming interfaces that abstract out all the networking details. Application components simply publish the data they produce and subscribe to the data they consume. The DDS middleware handles all the networking and real-time Quality of Service details. Components can seamlessly communicate across different programming languages and processor families. Applications are also independent of the underlying transport protocol and network type, be it shared memory, a local area network, wide area network or even radio link.
View On-Demand :
http://ecast.opensystemsmedia.com/340
As distributed system scale up, so does their integration time and cost. This integration challenge is particularly acute for real-time and intelligent systems: increased connectivity cannot come at the expense of performance, reliability or resource consumption.
Adopting an inherently scalable architecture is the secret to agilely and affordably building systems that encompass ever more applications, nodes and real-time data. This webinar will review how you can apply proven integration techniques—such as loose coupling and service orientation—to demanding real-time systems. Unlike approaches designed for conventional business applications, the architecture we'll introduce is appropriate for systems that span embedded, high performance and IT applications.
This webinar targets software architects, chief engineers and development leads in all industries that design real-time and intelligent systems. This includes defense, industrial, transportation, medical and aerospace applications.
Better integration is increasingly the key to competitive advantage. It provides end-users with higher situational awareness, responsiveness and resource utilization. Don't let your architecture hold you back.
NADS presents SimWare HLA. The one and only HLA that runs over DDS without gateways. Use main simulation architecture over the best real time communication layer.
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.
From its first use case that enabled distributed communications for US Navy ships to the autonomous systems of today, the DDS family of standards has enabled new generations of applications to run reliably, rapidly and securely, regardless of distance or scale.
To commemorate the 20th year milestone, the DDS Foundation is creating presentations that highlight the 14 specifications in the DDS standard, along with selected real-world use cases.
This presentation introduces some of the original use-cases and experiments, along with a brief history of the Standards.
A recorded video of the presentation is available at this URL
https://www.brighttalk.com/webcast/12231/602966
Communication Patterns Using Data-Centric Publish/SubscribeSumant Tambe
Fundamental to any distributed system are communication patterns: point-to-point, request-reply, transactional queues, and publish-subscribe. Large distributed systems often employ two or more communication patterns. Using a single middleware that supports multiple communication patterns is a very cost-effective way of developing and maintaining large distributed systems. This talk will begin with an introduction of Data Distribution Service (DDS) – an OMG standard – that supports data-centric publish-subscribe communication for real-time distributed systems. DDS separates state management and distribution from application logic and supports discoverable data models. The talk will then describe how RTI Connext Messaging goes beyond vanilla DDS and implements various communication patterns including request-reply, command-response, and guaranteed delivery. You will also learn how these patterns can be combined to create interesting variations when the underlying substrate is as powerful as DDS. We’ll also discuss APIs for creating high-performance applications using the request-reply communication pattern.
Fundamental to any distributed system are communication patterns: point-to-point, request-reply, transactional queues, and publish-subscribe. Large distributed systems often employ two or more communication patterns. Using a single middleware that supports multiple communication patterns is a very cost-effective way of developing and maintaining large distributed systems. This talk will begin with an introduction of Data Distribution Service (DDS) – an OMG standard – that supports data-centric publish-subscribe communication for real-time distributed systems. DDS separates state management and distribution from application logic and supports discoverable data models. The talk will then describe how RTI Connext Messaging goes beyond vanilla DDS and implements various communication patterns including request-reply, command-response, and guaranteed delivery. You will also learn how these patterns can be combined to create interesting variations when the underlying substrate is as powerful as DDS. We’ll also discuss APIs for creating high-performance applications using the request-reply communication pattern.
Watch on-demand here:
http://ecast.opensystemsmedia.com/339
Distributed systems work by sending information between otherwise independent applications. Traditionally, that communication is done by passing messages between the various nodes. This "message-centric" approach takes many forms, from simple direct transmissions to more complex message queue and transactional systems. All have a common premise: the unit of information exchange is the message itself. The infrastructure's role is to ensure that messages get to their intended recipients.
Recently, another paradigm is becoming popular. In this approach, the distributed infrastructure takes more responsibility; it offers to the distributed system a single version of "truth." The fundamental unit of communication is a data-object value; the infrastructure has done its job not when a message is delivered, but when all nodes have the correct understanding of that value. Because the focus is on the data itself, this is termed "data-centric" infrastructure.
While both types of middleware serve to connect distributed systems, the approaches are quite different. And the single most important decision you make when designing your distributed system – whether to go with the message-centric or data-centric approach – will result in different system capabilities, strengths, and weaknesses. In this webinar, we will examine both, discuss the differences and clarify which application use cases are best served by data- and message-centric designs.
Reactive Systems with Data Distribution Service (DDS)Abdullah Ozturk
The principles of reactive systems and how OMG's Data Distribution Service (DDS) middleware supports them.
Based on the blog post: http://tech.aozturk.me/reactive-systems-with-dds/
MBSE meets Industrial IoT: Introducing the New MagicDraw Plug-in for RTI Co...Istvan Rath
Slides of the talk at the MBSE Cyber Experience Symposium 2019 (https://mbsecyberexperience2019.com/speakers/abstracts/item/mbse-meets-industrial-iot-introducing-the-new-magicdraw-connext-dds-plug-in)
Interoperability and the Internet of Things – To standardize or not to standardize?
Originally presented on March 12, 2015.
Watch On-Demand: http://ecast.opensystemsmedia.com/520
To view this webcast on-demand, visit http://ecast.opensystemsmedia.com/337
How to Minimize Cost and Risk for Developing Safety-Certifiable Systems
Designing modern avionics systems, for manned as well as unmanned aircraft, requires a challenging and unique integration of safety-critical components, including processors, operating systems, communication media and application software. The requirement to meet RTCA DO-178 Level A or other safety certification criteria makes designs for these systems even more demanding.
In this webinar, learn how the use of one common integration platform in your designs lowers development and certification costs and reduces overall project risk. We will discuss testability of distributed systems, how to avoid sources of non-determinism, design alternatives to reliable communication and more.
As an innovator of safety-certifiable communications software based on the world's leading implementation of the OMG Data Distribution Service (DDS), we are working with dozens of teams developing safety-critical distributed systems. Our position renders a unique perspective spanning very different designs that we will share with you during the webinar. The intended audience includes architects and chief engineers for safety-critical systems.
As a leading innovator, you selected DDS to solve a complex communications challenge. Good choice! Now you recognize that your challenge is evolving: you need to consider adding more mobile and embedded devices into the network. The resource requirements of your DDS middleware are becoming a crucial factor. Even if you wanted your vendor to port to the rapidly expanding field of hand-held and mobile embedded devices, you wonder - will your applications still fit and run with needed performance levels within the memory footprint and CPU cycle constraints?
Your management or your client is now requesting you handle some new and interesting hardware and software, mobility solutions while bringing in data from new sources. To do this you might be able to select higher memory versions and/or faster CPU versions of the new devices in order to achieve the performance you need. Or you might be forced to drop features and functionality so that your DDS enabled application fits and provides acceptable performance. Either your costs go up or you leave out features. Do you really want to make that trade off? What options exist now?
Fortunately, one of the great strengths of the DDS standard is that it is open and provides interoperability between DDS versions from other suppliers. That’s one of the reasons your choice of DDS was a good one!
Twin Oaks Computing (www.twinoakscomputing.com) has designed its implementation from the ground up especially for resource constrained environments. CoreDX DDS is a high-performance implementation of the OMG Data Distribution Service (DDS) standard. The CoreDX DDS Publish-Subscribe messaging infrastructure provides high-throughput, low-latency data communications in an extremely small footprint.
CoreDX DDS applications can easily communicate with applications based on DDS from other vendors. This multi-vendor interoperability is enabled by multiple standards managed by the Object Management Group (OMG), including specifications of the application programming interface (API), real-time publish subscribe wire protocol (RTPS), and quality of service (QoS) features. CoreDX DDS includes proven support across all of these interoperability aspects. Twin Oaks has publicly demonstrated CoreDX DDS interoperability with RTI DDS and OpenSplice DDS.
Interoperability is particularly important for systems that are deployed for long periods of time, often measured in the decades, before they can be upgraded or replaced. Maintaining these systems through individual component failures, and ever changing and expanding requirements is hard. Interoperable middleware technologies like DDS make this challenge easier. System
Figure 1: Examples of Supported Hardware
4
Interoperable DDS Strategies 4
Integrators, faced with the challenge of integrating components from diverse sources, demand interoperability.
The Data Distribution Service (DDS) technology may not be as well known or understood as other middleware communications technologies like Corba, JMS, Web Services or even traditional sockets that are key components of nearly all distributed applications. Developers everywhere are familiar with these conventional data communications solutions, and may be comfortable customizing them to their particular domain and application. However, the flexibility and configurability of DDS makes it a better solution for applications in a wide variety of industries, from enterprise servers to deeply embedded applications.
This paper focuses on the DDS technology in embedded environments and compares it with Sockets, Corba, JMS, and SOA Web Services.
Real-Time Innovations (RTI) is the largest software framework provider for smart machines and real-world systems. The company’s RTI Connext® product enables intelligent architecture by sharing information in real-time, making large applications work together as one.
Originally presented on April 11, 2017
Watch on-demand: https://event.on24.com/eventRegistration/EventLobbyServlet?target=reg20.jsp&referrer=&eventid=1383298&sessionid=1&key=96B34B2E00F5FAA33C2957FE29D84624®Tag=&sourcepage=register
By John Breitenbach, RTI Field Applications Engineer
Contents
Introduction to RTI
Introduction to Data Distribution Service (DDS)
DDS Secure
Connext DDS Professional
Real-World Use Cases
RTI Professional Services
3. DDS: The Interoperability Standard for
Mission Critical Systems
• Data Distribution Service from OMG
• OMG: world’s largest systems
software standards org
– 470+ members
– UML, DDS, CORBA, more
• No vendor lock-in
– ~12 implementations
– Proven interoperability
– Choice of middleware vendors
– Choice of subsystem vendors
4. Navy Embraces OA
• Next-generation of the
U.S. Navy Aegis Weapon
System, by Lockheed
• Highly distributed system
including radar, weapons,
displays and controls
• Standards-based, high-
performance middleware
avoids vendor lock-in and
future-proofs the
architectural design
5. Government Adopts Standards
• Dominant in military
– DISA: DISR mandated
– Navy: Open Architecture,
FORCEnet
– Air Force, Navy and DISA: NESI
– Army, OSD: UCS
– NATO, UK MOD, South Korea,
many more
• Many other applications
– Air traffic control, industrial
automation, transportation,
medical
• Hundreds of active programs
– Multiple interoperable
implementations
9. Agenda
• DDS standard
– Motivation
– Applicability
• RTI Connext
– Overview
– What’s new
• RTI’s Infrastructure Community (IC) model
– RTI DDS free as Open Community Source
– Low-cost commercial licenses and support
10. Trend: Increasing System Scale
Drivers
• Increased situational
awareness, information sharing
• Responsiveness, timeliness,
speed of command
System of
systems
Implications
• More CPUs, nodes, apps, data
• More developers, teams,
suppliers, integration
11. Cost Constrains Scale
Limits Information Sharing & Connectivity
O(n2)
Time & cost of
integration,
maintenance
and upgrades
System Scale and Age
12. Challenges
• Business
– Cost reduction: lifecycle and procurement
Development, integration, maintenance, upgrades
Legacy system integration and modernization
– Agility: timely fielding of new capabilities
• Technical
– Scalability: information volume
– Reliability and availability
13. Solution
• Interoperability
– Easily share data across (sub)systems
– Minimize need for integration
– Goal: “plug and play”
• Modularity
– Decompose systems into interoperable
components
– Components can evolve and be
competed independently
– Reduces complexity
• Decentralization
– Systems of systems are inherently
distributed, span organizations
– Eliminates performance bottlenecks
14. Achieving Interoperability
• Communicate via explicit, well-defined interfaces
– Independent of:
• Implementation
• Programming language
• Platform (operating system, CPU type)
• Physical location, proximity (edge, data center, cloud, same server)
– Standard network protocol
• Integration requires no knowledge of internals
– No need for reverse engineering, code inspection
• A lingua franca
– Integration effort is O(1) to O(n), not O(n2)
• Components are
evolvable, interchangeable, swappable, shareable, reus
able
• Foundation of SOA, OA
15. DDS Enables Interoperability
Independently developed and loosely coupled
software modules, applications, subsystems and systems
S/W S/W S/W S/W
Data Distribution Service
16. DDS Overview
• Standardizes: Cross-vendor source portability
– Means to define domain- and
system-specific interfaces
– Network protocol
– Programming interface Standard API Schema
• Designed for mission-critical
systems, systems of systems DDS Implementation
Data centricity, QoS
– Decentralized
– Scalability Standard Protocol
– Availability
– Disparate Quality of Service
requirements Cross-vendor interoperability
17. DDS Applicability
Composition, Systems of Systems Decomposition
Mission Vehicle
Mapping
Planning Comms
Data Distribution Service Data Distribution Service
Increase: • Enable reuse, sharing,
• Information sharing competition
• Responsiveness • Simplify maintenance, upgrades
– Decouples components
– Eliminates complexity
18. Deployment
Integration Bus Native Interoperability Interface
Disparate Disparate
Component Component
Natively Natively
DDS or other protocol
Interoperable Interoperable
Adapter Adapter Component Component
API
DDS Library DDS Library DDS Library DDS Library
DDS-RTPS Wire Interoperability Protocol
• Alternative to traditional Enterprise Service Bus (ESB)
• Open: integration logic not specific to an ESB implementation
• Decentralized for high scalability and availability
19. Paradigm:
Data-Centric Publish/Subscribe
Subscribe
Publish Line
Fligh
Dest Arv
t
UA 567 SFO 7:32
Lin Fligh
AA 432 LAX 9:15 Squawk
e t
Lon 1234 UA 567
Squawk Lat Alt
g
7654 AA 432
1234 37.4 -122.0 500.0
7654 40.7 -74.0 250.0
Virtual Global Data Space
• Components:
– Publish the data they produce
– Subscribe to the data they consume
• DDS middleware:
– Routes data between matching publishers and subscribers
– Maintains consistent shared state
20. DDS Data Centricity
Component Component Component Optional
Persistence
DDS DDS DDS
Like a database
• Simple integration
– Data and schema are discoverable
– Producers and consumers are decoupled
– New components don’t impact existing ones
– Standard, application-independent CRUD operations: Create, Read, Update, Delete
– …not specific to data source, type of processing/algorithms, or business processes
• Fosters information sharing
• Single source of truth
– Robust
– Temporal decoupling
– Automatic state synchronization
21. DDS Data Centricity
Component Component Component Optional
Persistence
DDS DDS DDS
Unlike a database
• Event driven for real-time and low-latency processing
• Decentralized
– Highly scalable: no performance bottlenecks or expensive servers
– No single point of failure: non-stop availability
– Peer-to-peer communication: low latency
• Data cached locally for instant access
22. DDS Quality of Service
Reliable, 2 Hz,
Reliable, Western U.S.
100 Hz Fligh
Line Dest Arv
t
Reliable
UA 567 SFO 7:32
Lin Fligh
AA 432 LAX 9:15 Squawk
e t
Lon Best Effort,
Squawk Lat Alt 1234 UA 567
g 1 Hz, SAN area
7654 AA 432
1234 37.4 -122.0 500.0
Best Effort, 0.2 Hz, 7654 40.7 -74.0 250.0
UA flights
• Each component specifies its QoS capabilities and requirements
– Data volatility: Durability, History, Lifespan
– Data delivery: Reliability, Time based filter, Content filter, Deadline
– High availability: Liveliness, Ownership, Ownership Strength
• DDS implements and enforces contracts
23. DDS QoS Benefits
Reliable, 2 Hz,
Reliable, Western U.S.
100 Hz Fligh
Line Dest Arv
t
Reliable
UA 567 SFO 7:32
Lin Fligh
AA 432 LAX 9:15 Squawk
e t
Lon Best Effort,
Squawk Lat Alt 1234 UA 567
g 1 Hz, SAN area
7654 AA 432
1234 37.4 -122.0 500.0
Best Effort, 0.2 Hz, 7654 40.7 -74.0 250.0
UA flights
• Reduces complexity and • Efficiently scales with data volumes
associated lifecycle costs – Only required data is distributed, delivered
– Decoupling: publishers don’t need – Reduces network and processor overhead
to know subscribers’ requirements • Fault tolerance
– Disparate subscribers almost
always have different requirements – Redundancy management
– Moves logic from applications to – Components notified if QoS not satisfied or
DDS middleware connectivity lost
– Can take remedial action
24. Support for Mission-Critical Systems
• Autonomous operation
– Automatic discovery of applications
– Requires no system admin or
centralized infrastructure
• Non-stop: no single point of failure
• QoS provides visibility into real-time
behavior and system health
• Embeddable
• TRL 9 implementations
25. Integration Approaches
Point-to-point, application-centric
Tightly coupled: complex, stovepipe, brittle
Integration logic embedded in apps
High lifecycle costs: development, integration, maintenance & upgrades
Poor information sharing, robustness (state maintained in each app)
Centralized
ESB
Poor scalability and performance
Database Single point of failure: slow failover
Broker Ill-suited for autonomous systems
ESB integration logic is vendor-
specific, can be complex within ESB
DDS
Database’s simplicity, information sharing & robustness
Highly scalable, available, performant
Suitable for critical, autonomous, real-time, embedded
Integration logic is vendor independent
26. Asset Tracking
Legacy design:
• 12,000 tracks
• 11 servers with 88 cores
• Poor reliability and uptime
• 1.5M SLOC
• 2-8 years to develop
• Custom, proprietary
DDS design:
• 250,000 tracks
• 80% of a single core
• Full redundancy
• 50k SLOC
• Proof of concept in under a week
• 100% standards based
27. DDS Summary
• Enables interoperability and
portability by standardizing: Cross-vendor source portability
– Interface definitions
– Network protocol
– Programming interface
• Applicable to system composition and Standard API Schema
decomposition
• Data-centric publish/subscribe
DDS Implementation
– Simplifies integration Data centricity, QoS
– Fosters information sharing
– Improves robustness, particularly as
systems scale Standard Protocol
• Satisfies scalability, reliability and QoS
requirements of mission-critical
system
Cross-vendor interoperability
28. RTI Connext
Reduce the time, cost and risk of system development and integration
with the most proven, mature and comprehensive DDS solution
29. RTI Connext Product Family
Disparate
New and Upgraded Apps with Native Interoperability Apps/Systems
API: Full DDS DDS++ & JMS DDS Subset Adapters
Connext Connext Connext Connext
DDS Messaging Micro Integrator
DDS-RTPS Interoperability
Administration Recording
Monitoring Replay
System Viz Logging
Connext Tools
30. Connext DDS
• World’s leading DDS implementation
• 70+% market share
• 500+ customers
• 315+ university and IR&D projects
• 350,000+ deployed copies
• Most versions are TRL 9
• Includes library source code
• DDS core is free as Open Community Source
31. Example Customers
U.S. Defense International Defense Automotive
Boeing – AWACS Base10 – RoboScout Audi
Boeing – B-1B Cassidian – GCS VW
General Atomics – GCS QinetiQ – test & evaluation
Medical
Lockheed Martin – Aegis QinetiQ – vehicle integration
DocBox
Northrop Grumman – CLIP Rheinmetall – camp protection
Mevion
Raytheon – DDG 1000 Saab – naval CMS
Varian
Raytheon – SSDS Samsung –naval CMS
Raytheon – LPD-17 Ultra Electronics – OA platform Industrial Control
Nikon – semi mfg
NASA Transportation
Schneider - PLCs
Constellation launch control ATLANTIDA – ATM
Siemens Wind Power
Human Robotic Systems City of Tokyo – Highway
Robonaut Wi-Tronix – asset tracking Simulation
CAE – flight simulator
Science IT
Force Technology – tugboat
ESO – Telescope Paremus – cloud platform
Max Planck – nuclear fusion PIMCO – bond trading Telecom
Schilling – UUV Xuenn - sports betting Harmonic – video
IPC – VoIP
32
32. Application Code
<XML>
Data Types
Interface Dynamically
Generated Custom Pre-defined
Compiler defined (API)
Interface Definitions APIs – event-driven, polled & SQL query
• IDL
• XML / XSD DDS: C, C++, C#, Java, Ada*
• WSDL
Data-Centric Publish/Subscribe
Local API & remote
Quality of Svc
Monitoring*
API & file-based
Pluggable Discovery <XML>
Automatic History
Peer-to-peer Discovery Cache
File-based*
Custom Reliability • Serialization • DDS-RTPS Wire Protocol
ucast & mcast
ucast & mcast
Memory
Custom
Shared
UDPv4
UDPv6
TCP
Pluggable Transport Interface
Operating System and Network Stack
Windows, Linux, Unix, embedded, RTOS *Add-on
34. New with 5.0: Type Extensibility
• DDS Topics are strongly typed struct Track {
long id; //@key
– Safety float range;
float bearing;
– Wire efficiency }
• New XTypes interface allows types to
be extended Compatible
– Dynamically or not?
– While retaining type safety
• Subtype relationships match struct AirTrack {
long id; //@key
float range;
publications and subscriptions float bearing;
float elevation;
– Subscriptions to Track match }
publications of AirTrack
35. New Experimental Feature:
XML-Based Application Creation
• Use XML for complete system definition
– Data Types
– Quality of Service settings
– Topics
– All Entities: DomainParticipants, Publishers, Subscribers,
DataWriters and DataReaders.
• Benefits
– Share system configuration
– Reduce code size and errors
– Simplify & Speedup development
– Let developers focus on application the behavior
– Prototype and execute without writing any code!!
36. Replaces Configuration and Setup Code
Create
Participant
Register type
Static Create Topic
Create
Create Publisher
Subscriber
Create Writer Create Reader
Do the
Behavioral important
work
37. New Experimental Feature:
Connext Prototyper
• Command-line tool included with XML
Application Creation SDK
• Try out scenarios directly from their XML
descriptions, without writing any code!
– Directly see applications execute on the network
– See impact of QoS, Topic Designs, Data Type
definition…
– Specify data-values/ranges and publication rates
per topic
38. Connext Messaging:
Built on Connext DDS
• Additional enterprise integration patterns
– Request/reply
– Guaranteed messaging
• Persistence service
• Java Message Service (JMS) API
• Additional transports
– Secure (TLS, DTLS)
– WAN
• Future:
– New security plugins
– REST API
39. Application Code
<XML>
Data Types
Dynamically
Generated Custom Pre-defined
Interface defined (API)
Compiler
Request/reply, Guaranteed Messaging
Interface Definitions APIs – event-driven, polled & SQL query
• IDL
• XML / XSD DDS: C, C++, C#, Java, Ada* JMS
• WSDL
Data-Centric Publish/Subscribe
Local API & remote
Quality of Svc
Monitoring*
API & file-based
Pluggable Discovery <XML>
Automatic History
Peer-to-peer Discovery Cache
File-based*
Custom Reliability • Serialization • DDS-RTPS Wire Protocol
TLS & DTLS
ucast & mcast
ucast & mcast
Memory
Custom
Shared
UDPv4
UDPv6
WAN
(SSL)
TCP
Pluggable Transport Interface
Operating System and Network Stack
Windows, Linux, Unix, embedded, RTOS *Optional
40. New with 5.0: Integration Patterns
• Request/Reply: • Guaranteed Messaging:
Process commands Ensure action
– Remote method invocation – Persistent publications
– Request/async reply – Durable subscribers
– Request/multiple-reply – Application
– Request/multiple repliers acknowledgement
Reply
Replier A
Publisher Subscriber
Message Message
Durable
Requester Replier B Subscriber
Message
Request
Replier C Message
41. New with 5.0: Enhanced Scalability
• Optimized writer-side filtering
– Unlimited remote readers
– Greatly optimized protocol*
• Ultra-scalable request-reply Subscriber
– 1000s of clients Temperature
Update Turbine 1
Publisher Subscriber
Publisher
Temperature Temperature
…
Updates Update Turbine 2
Subscriber
Temperature
Update Turbine N
* Still DDS compliant, backwards compatible
42. Persistence Service
Publisher Subscriber
Domain
Subscriber
Persistence
Service
• Data availability, even if publisher fails
• Reduced load and memory for data writers
43. OpenSSL for TLS and DTLS
• OpenSSL: dominant industry solution for TLS
• Point-to-point: TLS over TCP, DTLS over UDP
• Integrity, authentication and encryption
– Authentication: X.509 based
– Encryption: wide selection
• FIPS 140 Level 1 certified
• Applied at the DDS DomainParticipant level
44. Future Security Support
• Finer grained access control
– Topics
– Read/write
• Multicast encryption
– One encryption per sample
– …not per subscriber
• Built-in key distribution
45. OMG Secure DDS Submission
certificates application component App.
App.
App.
Authentication Secure DDS Key
Plug-in middleware Management
? Plug-in Other
Other
Access Control Other
DDS
DDS
Plug-in DDS Entities Cryptography DDS
System
System
Plug-in System
Auditing Protocol Data
Plug-in Engine cache
Secure Transport
TAG Encrypted Data
Network
46. Future: REST Interface
Preview Available Now
• Web interface to DDS
• Access DDS from any
application, platform or language that
can invoke a Web Service DDS-RTPS
– Web applications, e.g., Google Maps
– JavaScript, Flash, Perl, PHP, Python, CGI
scripts
• Lightweight
– Clients do not need to link or load HTTP
special libraries
• Basis for RTI submission to OMG
Web-Enabled DDS standard
49. Platform Support
• Mainstream 32/64-bit processors
• 16-bit micro-controllers with 32-bit integer
support
• Operating system support
– Windows, Linux
– VxWorks, VxWorks Cert, VxWorks 653, FreeRTOS
– Preview: iOS, Android
• Source code included for easy porting to other
platforms
• Platform plug-in API
50. Compatibility
• Interoperable with general-purpose edition
– RTPS 2.1 compliant
• Directly compatible with
– rtiddsgen
– Wireshark
– Routing Service
• Compatible when using dynamic discovery or via
Routing Service
– Spreadsheet Add-in for Microsoft Excel
– Real-Time Connect
– Recording Service
51. Connext Integrator
Compose Systems of Systems
• Adapts non-DDS applications to DDS (e.g.,
legacy)
• Transforms between incompatible data models
to achieve interoperability
• Bridges DDS systems
– Across networks – LAN and WAN
– Across security domains
55. Recording
• Applications: • Record high-rate data arriving in
– Future analysis and debugging real-time
– Regulatory compliance • >15,000 messages/updates per
– Replay for testing and simulation second per disk
purposes • Non-intrusive
Publisher Subscriber
Domain
Publisher Subscriber
Status Control
Topic Topic
Recorder File DB
56. Playback
• Real-time playback of data
– Captured by RTI Recorder
– From any number of topics
DDS
• Applications:
– Debugging – replay what happened
– Live post-mission analysis, e.g., UAV
– Replay for simulation and training Playback
Data
• Non-intrusive Log
– Just another publisher
– Transparent to subscribers
57. RTI Analyzer
Detailed system topology display
Displays QoS settings
Helps debugging Writer to
Reader connections
Helps to Track and tune QoS
parameters
Helps in diagnosing unusual
behavior
58. Application Monitoring Features
• Detailed statistics on traffic,
errors, and resource usage
• Detailed system topology display
• Configurable alerts and thresholds
• Helps to Track and tune
performance
• Helps in diagnosing unusual
behavior
59. Admin Console
• 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 Connext Integrator
• GUI interfaces for sending remote commands
• Retrieving and updating current configurations
• Built-in XML editor for modifying configuration files
• Built on top of Eclipse
61. RTI Connext Add-on Products
• Limited bandwidth transport
• CORBA compatibility kit
• Ada 2005 language support
• Add-on for National Instruments LabView
62. Limited-Bandwidth Transport
• Designed specifically for wireless or satellite comms
• Limited-Bandwidth RTPS Transport Plug-in
– Increases data to packet ratio
• Compression Transport Plug-in
– Further optimizes data to packet ratio
• Quasi-static Discovery Plug-in
– Reduces meta-data traffic
– Minimizes system set-up and reconnection times
• Simulator
– Packet drops, limited bandwidth
64. Infrastructure Community
Business Model
• Facilitates adoption of a DDS software
infrastructure and interoperability interface
• …across development projects and
organizations
• Community members get RTI DDS for free
– Open Community Source license
– Modifiable
– Redistributable
65. What Is an Infrastructure Community?
• Any community sharing software
– Seeking a common or interoperable
software infrastructure
– Across projects, divisions, companies,
programs
• Examples
– Software supply chains
– Enterprises or corporate divisions
– Government or industry standards
communities (FACE, UCS, COE, ICE)
– Large projects
• “Everyone you care about”
66. Infrastructure Community Model
• Free core RTI DDS for entire IC
– Full source & binary for latest RTI DDS
• Windows & Linux pre-built binaries
• Share source & binaries within IC (original and modified)
– Royalty free
– Optional support on a time and materials basis
• Low-cost commercial product for projects
– Subscriptions start at $1,000 per developer (U.S.)
– Adds tools, advanced functionality, platforms, transports
– Warranty & bounded support costs
– Still no royalties or deployment fees
68. Summary
• DDS delivers the interoperability, scalability and
availability required to cost-effectively integrate
mission-critical systems of systems
• RTI provides the most proven, mature and
comprehensive DDS solution
• RTI’s Open Community Source makes it easy to
realize DDS’ benefits by facilitating sharing of
infrastructure across organizations
Editor's Notes
This chart illustrates the impact of system scale on the time and cost required for integration. Integration time goes up exponentially as the number of applications and system components increases. With two applications, there are only up to two data flows to handle, from A to B and B to A. With five applications, there are 20 potential connections in a system. With 25 applications, there are 600 potential connections. With 100 applications, which is not unusual in a system of systems, there are nearly 10,000 potential connections. That’s why integration and upgrades can take years.Costs also increase over time as the systems themselves become larger, more complex and less maintainable.
Interoperability reduces the integration burden:Components that are directly interoperable don’t need to be integratedComponents that provide a well-defined interoperability interface can be easily composed without having to do any reverse engineering or code inspection
Interoperability reduces the integration burden:Components that are directly interoperable don’t need to be integratedComponents that provide a well-defined interoperability interface can be easily composed without having to do any reverse engineering or code inspection
Composition – compose systems of systemsDecomposition – decompose systems/subsystems/applications into modules, monolithic open architecture
-Goal is obtain writers and readers needed to do the important work-The process is clearly defined
Scalability enhancements include the following.Enhanced writer-side filtering, now supporting unlimited remote readersGreatly reduced gap and heartbeat messagesOptimized writer-side filtering that is independent of the number of remote readers
This is the OMG Secure DDS architecture. The DDS security design allows plugins for all key functionsAll vendors will implement interoperable plugins (the spec includes wire & plugin API)Security specialists can build advanced pluginsThe proposed security architecture will be configurable via newly added QoS polices, while remaining open and extensible via “plug-in” APIs so that customers can integrate with pre-existing Identity Management Mechanisms, Access Control Policy repositories, or cryptographic libraries which might be program or project specific. TAn interoperable implementation of the plug-ins will also be part of the OMG standard. The plug-ins can be enabled or not. RTI is going to implement standard plug-ins, so that interoperability with other vendors is maintained. When security is enabled, customers can use the interoperable plug-ins as the base level security or their own custom based ones. The standard plug-ins will provide authentication, access control, encryption, key management and data tagging capabilities. High security systems may want to implement custom plugins. We're working with people like Tresys to develop some higher security and more complex plug-ins for systems that require more than the typical off-the-shelf interoperability security.
The baseline configuration provides a minimal feature set.The problem is that the required minimal feature set is application-dependent.The solution is to offer a user-configurable feature set.Note RTPS is not in the baseline configuration, enabling efficient intra-process communication.
Additional features and QoS (beyond the baseline configuration) are selectively enabled either at compile-time or run-time. This is done to minimize the library size.The optional feature sets are the main theme of the next EAR.QoS management includes getting/setting QoS and changing default QoS.Entity management includes getting, deleting and ignoring entities. This includes getting remote entity information. Note the baseline configuration only supports deleting all contained entities at once.
This slide lists the discovery protocols supported by the baseline configuration.The protocols are plug-in components.Dynamic and quasi-static discovery are supported by the current EAR.