Presentation of the DDS Interoperability demo performed in Washington DC between RTI, TwinOaks and PrismTech.
This demonstration shows the use of the DDS-RTPS interoperability protocol in 9 different scenarios.
Jamie Clark's preso on cloud computing and legal issues at the OASIS International Cloud Symposium (#intcloudsymp) at Ditton Manor, Windsor, UK, October 2011
This presentation provides 10 reasons why you should choose OpenSplice DDS as you OMG DDS compliant technology. It analyzes standard compliance, technology, service, use cases and pedigree.
OpenSplice DDS v6 is a major leap forward with respect to the state of the art of DDS implementations; v6 is the first DDS implementation on the market to introduce (1) multiple deployment options, namely daemon-based and library-based, and (2) multiple programming paradigms, such as Pub/Sub, Distributed Object Caches and Client/Server, (3) universal connectivity to over 80 communication technologies via the new OpenSplice Gateway. All of this combined with an Open Source model, an active community and a strong technology ecosystem.
In the Loop - Lone Star Ruby ConferenceLourens Naudé
The Reactor Pattern's present in a lot of production infrastructure (Nginx, Eventmachine, 0mq, Redis), yet not very well understood by developers and systems fellas alike. In this talk we'll have a look at what code is doing at a lower level and also how underlying subsystems affect your event driven services.
Below the surface : system calls, file descriptor behavior, event loop internals and buffer management
Evented Patterns : handler types, deferrables and half sync / half async work
Anti patterns : on CPU time, blocking system calls and protocol gotchas
These slides describe the scenario that were demonstrated during the OMG DDS Interoperability demo that was held in Washington DC on the 14th of July 2009, during the last OMG Real-Time Workshop.
The DDS specification provides fine-grained control over the real-time behaviour, dependability, and performance of DDS applications by means of a rich set of QoS Policies. The challenge for many DDS users is that the specifications explains very clearly how each QoS allows to control very specific aspects of data distribution yet it provides no hints on how different QoS should be composed to control complex properties such as the consistency model, or to impose end-to-end real-time scheduling decision. This half-day tutorial will fill this gap by providing attendees with (1) an explanation of how the various QoS compose, and (2) providing attendees with a series of QoS-composition Patters that can be used to control macro-properties of an application, such as the consistency model.
Jamie Clark's preso on cloud computing and legal issues at the OASIS International Cloud Symposium (#intcloudsymp) at Ditton Manor, Windsor, UK, October 2011
This presentation provides 10 reasons why you should choose OpenSplice DDS as you OMG DDS compliant technology. It analyzes standard compliance, technology, service, use cases and pedigree.
OpenSplice DDS v6 is a major leap forward with respect to the state of the art of DDS implementations; v6 is the first DDS implementation on the market to introduce (1) multiple deployment options, namely daemon-based and library-based, and (2) multiple programming paradigms, such as Pub/Sub, Distributed Object Caches and Client/Server, (3) universal connectivity to over 80 communication technologies via the new OpenSplice Gateway. All of this combined with an Open Source model, an active community and a strong technology ecosystem.
In the Loop - Lone Star Ruby ConferenceLourens Naudé
The Reactor Pattern's present in a lot of production infrastructure (Nginx, Eventmachine, 0mq, Redis), yet not very well understood by developers and systems fellas alike. In this talk we'll have a look at what code is doing at a lower level and also how underlying subsystems affect your event driven services.
Below the surface : system calls, file descriptor behavior, event loop internals and buffer management
Evented Patterns : handler types, deferrables and half sync / half async work
Anti patterns : on CPU time, blocking system calls and protocol gotchas
These slides describe the scenario that were demonstrated during the OMG DDS Interoperability demo that was held in Washington DC on the 14th of July 2009, during the last OMG Real-Time Workshop.
The DDS specification provides fine-grained control over the real-time behaviour, dependability, and performance of DDS applications by means of a rich set of QoS Policies. The challenge for many DDS users is that the specifications explains very clearly how each QoS allows to control very specific aspects of data distribution yet it provides no hints on how different QoS should be composed to control complex properties such as the consistency model, or to impose end-to-end real-time scheduling decision. This half-day tutorial will fill this gap by providing attendees with (1) an explanation of how the various QoS compose, and (2) providing attendees with a series of QoS-composition Patters that can be used to control macro-properties of an application, such as the consistency model.
A presentation on a few of the fundamental concepts behind distributed data stores. Presented at Devnation Portland 2010 http://devnation.us/events/10.
Interoperability demonstration between 6 different products that implement the OMG DDS Interoperability Wire Protocol (DDS-RTPS).
The demonstration took place at the March 2012 OMG technical meeting in Washington DC.
The following companies demonstrated interoperability between their products: RTI (Connext DDS). TwinOaks Computing (CoreDX), PrismTech (OpenSpliceDDS), OCI (OpenDDS), ETRI (ETRI DDS), IBM.
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.
Introduction to the OMG Data Distribution Service and its use for Unmanned Vehicle Interoperability. Salient features of the standard and the protocol specially beneficial to this application domain.
Interoperability demonstration between 5 different products that implement the OMG DDS Interoperability Wire Protocol (DDS-RTPS).
The demonstration took place at the March 2011 OMG technical meeting in Washington DC.
The following companies demonstrated interoperability between their products: RTI (Connext DDS). TwinOaks Computing (CoreDX), PrismTech (OpenSpliceDDS), Gallium Visual Systems/Kongsberg (Compass DDS), IBM.
Easing Integration of Large-Scale Real-Time Systems with DDSRick Warren
Webcast (sorry, audio not included) on system integration design patterns from July of 2010 pertaining mostly (but not exclusively) to Data-Distribution Service (DDS) technology.
A presentation on a few of the fundamental concepts behind distributed data stores. Presented at Devnation Portland 2010 http://devnation.us/events/10.
Interoperability demonstration between 6 different products that implement the OMG DDS Interoperability Wire Protocol (DDS-RTPS).
The demonstration took place at the March 2012 OMG technical meeting in Washington DC.
The following companies demonstrated interoperability between their products: RTI (Connext DDS). TwinOaks Computing (CoreDX), PrismTech (OpenSpliceDDS), OCI (OpenDDS), ETRI (ETRI DDS), IBM.
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.
Introduction to the OMG Data Distribution Service and its use for Unmanned Vehicle Interoperability. Salient features of the standard and the protocol specially beneficial to this application domain.
Interoperability demonstration between 5 different products that implement the OMG DDS Interoperability Wire Protocol (DDS-RTPS).
The demonstration took place at the March 2011 OMG technical meeting in Washington DC.
The following companies demonstrated interoperability between their products: RTI (Connext DDS). TwinOaks Computing (CoreDX), PrismTech (OpenSpliceDDS), Gallium Visual Systems/Kongsberg (Compass DDS), IBM.
Easing Integration of Large-Scale Real-Time Systems with DDSRick Warren
Webcast (sorry, audio not included) on system integration design patterns from July of 2010 pertaining mostly (but not exclusively) to Data-Distribution Service (DDS) technology.
Outsourcing your TDM Gateways: SIP Trunking as a Service Provider Cloud Service Cisco Canada
SIP Trunking is beginning to become a widely deployed offering from SP. One way of looking at SIP Trunking is outsourcing the essential feature of TDM interconnection from an "on premise" TDM gateway to a service from your SP. With more and more customers deploying SIP Trunking, it is important to understand what is required to successfully deploy this service and where the future of SIP Trunking is heading. In this presentation you will learn about how SP offer SIP Trunking Services and what is required for customers to successfully deploy this new Cloud service.
Welcome to the first webinar in the series of Cyclone DDS Unleashed.
In this session, our CEO and CTO, Angelo Corsaro, and our DDS Head of Technology, Erik Boasson, will share their expertise on how the DDS technology evolved to become the OMG standard we have today, the ZettaScale's approach to DDS and why during the ROSCon in Kyoto from 2022, we kept hearing from users that Cyclone DDS was their favourite OMG implementation.
If you have any questions and you want to reach out, you can send us an email at contact@zettascale.tech or join our Discord channel: https://discord.gg/6GwdBxntxt
You can read more about Cyclone DDS on our website: https://www.zettascale.tech/product/cyclone
Stay up to date with the latest news:
Twitter: https://twitter.com/zettascaletech
LinkedIn: https://www.linkedin.com/company/zettascaletech/
Website: https://www.zettascale.tech/
Newsletter: http://eepurl.com/igPw31
What are the issues integration in integrating sensor nets and other distributed systems collecting and sharing real time data? How does RTI's Data Distribution Service address the integration needs without sacrificing the real-time collaboration constraints?
Presentation on the OMG Data-Distribution Service (DDS) Interoperability demo held during the Santa Clara OMG meeting on December 8, 2010.
Four vendors demonstrated the wire-protocol interoperability of their DDS Implementations: RTI, PrismTech, Gallium Visual Systems, and Twin Oaks Computing.
This is a demonstration of the use of the DDS Interoperability Wire Protocol standard (DDS-RTPS)
Similar to OMG DDS Interoperability Demo 2009 (20)
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
Introduction to DDS: Context, Information Model, Security, and Applications.Gerardo Pardo-Castellote
Introduction to the Data-Distribution Service (DDS): Context and Applications.
This 50 minute presentation summarizes the main features of DDS including the information model, the type system, and security as well as how typical applications use DDS.
It was presented at the Canadian Government Information Day in Ottawa on September 2018.
There is also a video of this presentation at https://www.youtube.com/watch?v=6iICap5G7rw.
This Object Management Group (OMG) RFP solicits submissions identifying and defining mechanisms to achieve integration between DDS infrastructures and TSN networks. The goal is to provide all artifacts needed to support the design, deployment and execution of DDS systems over TSN networks.
The DDS-TSN integration specification sought shall realize the following functionality:
● Define mechanisms that provide the information required for TSN-enabled networks to calculate any network schedules needed to deploy a DDS system.
OMG RFP
● Identify those parts of the set of the IEEE TSN standards that are relevant for a DDS-TSN integration and indicate how the DDS aspects are mapped onto, or related to, the associated TSN aspects. Examples include TSN- standardized information models for calculating system-wide schedules and configuring network equipment.
● Identify and specify necessary extensions to the [DDSI-RTPS] and [DDS- SECURITY] specifications, if any, to allow DDS infrastructures to use TSN- enabled networks as their transport while maintaining interoperability between different DDS implementations.
● Identify and specify necessary extensions to the DDS and DDS- XML specification, if any, to allow declaration of TSN-specific properties or quality of service attributes.
A NEW ARCHITECTURE PROPOSAL TO INTEGRATE OPC UA, DDS & TSN.
Suppliers and end users need a complete solution to address the complexity of future industrial automation systems. These systems require:
• Interoperability to allow devices and independent software applications from multiple suppliers to work together seamlessly
• Extensibility to incorporate future large or intelligent systems
• Performance and flexibility to handle challenging deployments and use cases
• Robustness to guarantee continuity of operation despite partial failures
• Integrity and fine-grained security to protect against cyber attacks
• Widespread support for an industry standard
This document proposes a new technical architecture to build this future. The design combines the best of the OPC Unified Architecture (OPC UA), Data Distribution Service (DDS), and Time-Sensitive Networking (TSN) standards. It will connect the factory floor to the enterprise, sensors to cloud, and real-time devices to work cells. This proposal aims to define and standardize the architecture to unify the industry.
Technical overview of the DDS for Extremely Resource-Constrained Environments (DDS-XRCE) specification.
This specification was adopted by the OMG in March 2018.
Demonstrates interoperability of 5 independent products that implement the Data-Distribution Service (DDS) Security Standard
(https://www.omg.org/spec/DDS-SECURITY/).
Tests the following implementations: RTI Connext DDS, Twin Oaks Computing CoreDX DDS, Kongsberg InterComm DDS, ADLink Vortex DDS Cafe, and Object Computing Inc OpenDDS.
This demonstration was performed at the OMG Meeting held in Reston, VA, USA in March 2018
Applying MBSE to the Industrial IoT: Using SysML with Connext DDS and SimulinkGerardo Pardo-Castellote
The benefits of Model-Based Systems Engineering (MBSE) and SysML are well established. As a result, users want to apply MBSE to larger and more complex Industrial IoT applications.
Industrial IoT applications can be very challenging: They are distributed. They deploy components across nodes spanning from small Devices to Edge computers to the Cloud. They often need mathematically-complex software. Moreover, they have strict requirements in terms of performance, robustness, and security.
SysML can model requirements, system components, behavior, interactions, and more. However, SysML does not provide a robust way to connect components running across different computers, especially when the security and quality of service of individual data-flows matter. SysML also does not provide all the tools needed to model and generate the (mathematical) code for complex dynamic systems.
A new “DDS + Simulink” MagicDraw SysML plugin has been developed to addresses these needs. It brings to MagicDraw users the capabilities of Connext DDS from RTI and Simulink from Mathworks:
The OMG Data-Distribution Service (DDS) is a secure and Qos-aware connectivity “databus”. DDS is considered the core connectivity framework for Software Integration and Autonomy by the Industrial Internet Consortium. Connext DDS is the leading implementation of the DDS standard, proven in 1000s of critical deployments.
Simulink is a tool for modeling and implementing the code needed for complex dynamic systems. It is widely deployed in many application domains including Automotive, Robotics, and Control Systems.
The new MagicDraw plugin defines a “DDS profile” for SysML that can model a distributed application connected using the DDS databus. The plugin can also generate the artifacts that configure the DDS databus (Topics, Data Types, Qos, etc.) and the adapters to Simulink and native code (e.g. C++ or Java).
By integrating three best-of class technologies: SysML, DDS and Simulink it is now possible to do MBSE for a wide range of Industrial IoT applications.
One of the most important challenges that system designers and system integrators face when deploying complex Industrial Internet of Things (IoT) systems is the integration of different connectivity solutions and standards. At RTI, we are constantly working to accelerate the Industrial IoT revolution. Over the past few years, we have developed standard connectivity gateways to ensure that DDS systems can easily integrate with other core connectivity frameworks.
This year, we developed a standard OPC UA/DDS Gateway, a bridge between two of the most well-known Industrial IoT connectivity frameworks. We are excited to announce that the gateway was just adopted by the Object Management Group (OMG).
In this webinar, we will dive deeper into the importance of choosing a baseline core connectivity standard for the Industrial IoT and how to ensure all system components are fully integrated. Attendees will also learn:
How the OPC UA/DDS Gateway specification was developed and how it works
How to leverage the Gateway to enable DDS and OPC UA applications to interoperate transparently
About the first standard connectivity gateway released with RTI Web Integration Service in Connext DDS 5.3
Gateways are a critical component of system interoperability and we will keep working to help companies accelerate Industrial IoT adoption.
This is the Beta 1 version of the OPC UA / DDS Gateway specification released by the Object Management Group in March 2018.
This specification defines a standard, vendor-independent, configurable gateway that enables interoperability and information exchange between systems that use DDS and systems that use OPC UA.
Data Distribution Service (DDS) is a family of standards from the Object Management Group (OMG) that provide connectivity, interoperability, and portability for Industrial Internet, cyber-physical, and mission-critical applications.
The DDS connectivity standards cover Publish-Subscribe (DDS), Service Invocation (DDS-RPC), Interoperability (DDS-RTPS), Information Modeling (DDS-XTYPES), Security (DDS-SECURITY), as well as programing APIs for C, C++, Java and other languages.
The OPC Unified Architecture (OPC UA) is an information exchange standard for Industrial Automation and related systems created by the OPC Foundation. The OPC UA standard provides an Addressing and Information Model for Data Access, Alarms, and Service invocation layered over multiple transport-level protocols such as Binary TCP and Web-Services.
DDS and OPC UA exhibit significant deployment similarities:
• Both enable independently developed applications to interoperate even when those applications come from different vendors, use different programming languages, or run on different platforms and operating systems.
• Both have significant traction within Industrial Automation systems.
• Both define standard protocols built on top of the TCP/ UDP/IP Internet stacks.
The two technologies may coexist within the same application domains; however, while there are solutions that bridge between DDS and OPC UA, these are based on custom mappings and cannot be relied to work across vendors and products.
This is the DDS-XRCE 1.0 Beta specification adopted by the OMG March 2018.
The purpose of DDS-XRCE is to enable resource-constrained devices to participate in DDS communication, while at the same time allowing those devices to be disconnected for long periods of time but still be discoverable by other DDS applications.
DDS-XRCE defines a wire protocol, the DDS-XRCE protocol, to be used between an XRCE Client and XRCE Agent. The XRCE Agent is a DDS Participant in the DDS Global Data Space. The DDS-XRCE protocol allows the client to use the XRCE Agent as a proxy in order to produce and consume data in the DDS Global Data Space.
Demonstrates interoperability of 5 independent products that implement the Data-Distribution Service (DDS) Security Standard
(https://www.omg.org/spec/DDS-SECURITY/).
Tests the following implementations: RTI Connext DDS, Twin Oaks Computing CoreDX DDS, Kongsberg InterComm DDS, ADLink Vortex DDS Cafe, and Object Computing Inc OpenDDS.
Demonstrates interoperability of 3 independent products that implement the Data-Distribution Service (DDS) Security Standard
(https://www.omg.org/spec/DDS-SECURITY/).
Tests the following implementations: RTI Connext DDS, Twin Oaks Computing CoreDX DDS, and Kongsberg InterComm DDS.
This specification provides the following additional facilities to DDS [DDS] implementations and users:
* Type System. The specification defines a model of the data types that can be used for DDS Topics. The type system is formally defined using UML. The Type System is de- fined in section 7.2 and its subsections. The structural model of this system is defined in the Type System Model in section 7.2.2. The framework under which types can be modi- fied over time is summarized in section 7.2.3, “Type Extensibility and Mutability.” The concrete rules under which the concepts from 7.2.2 and 7.2.3 come together to define compatibility in the face of such modifications are defined in section 7.2.4, “Type Com- patibility.”
* Type Representations. The specification defines the ways in which types described by the Type System may be externalized such that they can be stored in a file or communi- cated over a network. The specification adds additional Type Representations beyond the
DDS-XTypes version 1.2 1
one (IDL [IDL41]) already implied by the DDS specification. Several Type Representa- tions are specified in the subsections of section 7.3. These include IDL (7.3.1), XML (7.3.2), XML Schema (XSD) (7.3.3), and TypeObject (7.3.4).
* Data Representation. The specification defines multiple ways in which objects of the types defined by the Type System may be externalized such that they can be stored in a file or communicated over a network. (This is also commonly referred as “data serializa- tion” or “data marshaling.”) The specification extends and generalizes the mechanisms already defined by the DDS Interoperability specification [RTPS]. The specification in- cludes Data Representations that support data type evolution, that is, allow a data type to change in certain well-defined ways without breaking communication. Two Data Repre- sentations are specified in the subsections of section 7.4. These are Extended CDR (7.4.1, 7.4.2, and 7.4.3) and XML (7.4.4).
* Language Binding. The specification defines multiple ways in which applications can access the state of objects defined by the Type System. The submission extends and gen- eralizes the mechanism currently implied by the DDS specification (“Plain Language Binding”) and adds a Dynamic Language Binding that allows application to access data without compile-time knowledge of its type. The specification also defines an API to de- fine and manipulate data types programmatically. Two Language Bindings are specified in the subsections of section 7.5. These are the Plain Language Binding and the Dynamic Language Binding.
This specification defines the Security Model and Service Plugin Interface (SPI) architecture for compliant DDS implementations. The DDS Security Model is enforced by the invocation of these SPIs by the DDS implementation. This specification also defines a set of builtin implementations of these SPIs.
* Authentication Service Plugin. Provides the means to verify the identity of the application and/or user that invokes operations on DDS. Includes facilities to perform mutual authentication between participants and establish a shared secret.
* AccessControl Service Plugin. Provides the means to enforce policy decisions on what DDS related operations an authenticated user can perform. For example, which domains it can join, which Topics it can publish or subscribe to, etc.
* Cryptographic Service Plugin. Implements (or interfaces with libraries that implement) all cryptographic operations including encryption, decryption, hashing, digital signatures, etc. This includes the means to derive keys from a shared secret.
* Logging Service Plugin. Supports auditing of all DDS security-relevant events Data Tagging Service Plugin. Provides a way to add tags to data samples.
This document specifies the OMG Interface Definition Language (IDL). IDL is a descriptive language used to define data types and interfaces in a way that is independent of the programming language or operating system/processor platform.
The IDL specifies only the syntax used to define the data types and interfaces. It is normally used in connection with other specifications that further define how these types/interfaces are utilized in specific contexts and platforms.
This the the formal version 1.0 of the DDS Security specification released September 2016. OMG document number formal/2016-08-01.
DDS-Security defines the Security Model and Service Plugin Interface (SPI) architecture for compliant DDS implementations.
The DDS Security Model is enforced by the invocation of these SPIs by the DDS implementation. This specification also defines a set of builtin implementations of these SPIs.
* The specified builtin SPI implementations enable out-of-the box security and interoperability between compliant DDS applications.
* The use of SPIs allows DDS users to customize the behavior and technologies that the DDS implementations use for Information Assurance, specifically customization of Authentication, Access Control, Encryption, Message Authentication, Digital Signing, Logging and Data Tagging.
This specification is a response to the OMG RFP "eXtremely Resource Constrained Environments DDS (DDS- XRCE)"
It defines a DDS-XRCE Service based on a client-server protocol between a resource constrained, low-powered device (client) and an Agent (the server) that enables the device to communicate with a DDS network and publish and subscribe to topics in a DDS domain. The specifications purpose and scope is to ensure that applications based on different vendor’ implementations of the DDS-XRCE Service are compatible and interoperable.
This is the Joint submission by RTI, TwinOaks, and eProsima. Updated September 2017, OMG document number mars/2017-09-18.
DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)Gerardo Pardo-Castellote
The next wave of Industrial Internet applications will connect machines and devices together into functioning, intelligent systems with capabilities beyond anything possible today. These systems fundamentally depend on connectivity and information exchange to derive knowledge and make "smart decisions". They require a much higher level of reliability and security than "Consumer" IoT applications. OMG's Data-Distribution Service for Real-Time Systems (DDS) is the premier open middleware standard directly addressing publish-subscribe communications for Industrial IoT applications. It provides a protocol that meets the demanding security, scalability, performance, and Quality of Service requirements of IIoT applications spanning connected machines, enterprise systems, and mobile devices.This presentation will use concrete use cases to introduce DDS and examine why energy, advanced medical, asset-tracking, transportation, and military systems choose to base their designs on DDS.
DDS - The Proven Data Connectivity Standard for the Industrial IoT (IIoT)
OMG DDS Interoperability Demo 2009
1. DDS Interoperability Demo
OMG Real-Time Workshop,
Washington DC, July 2009
Real-Time Innovations, Twin Oaks Computing, PrismTech
1
2. History: DDS the Standards
! Data Distribution Service for Real-Time Systems
API for Data-Centric Publish-Subscribe distributed systems
Adopted in June 2003
Finalized in June 2004
Revised June 2005, June 2006
Spec version 1.2: formal/07-07-01
! Interoperability wire protocol
Adopted in July 2006
Revised in July 2007
Spec version 2.1: formal/2009-01-05
! Related specifications
UML Profile for DDS
DDS for Light-Weight CCM
! Multiple (7+) Implementations
2
3. Who is participating
! Real-Time Innovations, Inc.
! TwinOaks Computing, Inc.
! PrismTech Corp.
3
5. About Twin Oaks Computing
! Small business based in Colorado
! Specializing in high-performance data communications
DDS, RTPS
Networking protocols
Device drivers
Embedded computing environments
Tactical data links
! CoreDX DDS implementation
Targeted at high-performance, space-constrained, embedded
environments
! Staff with over 30 years experience developing and
supporting DoD systems
! http://www.twinoakscomputing.com
5
7. What you will see today
! #1 Interoperability works!
! #2 This is not a “trivial” scenario or “toy” demo!
You will see interoperability along many dimensions:
Discovery
Different platforms (Linux, Windows, MacOS, Gumstix)
Different Data-Types
Different Topics
Different Qos
Unicast & Multicast, both reliable and best efforts
One to Many and Many to one communications
Filters: time, content, …
! #3 Interoperability does not compromise performance
Direct communication. No bridges!!
7
8. Nine demo scenarios
1. Basic connectivity
2. Request / Offered QoS
3. Quality of Service: DURABILITY
4. Quality of Service: RELIABILITY
5. Network Interruption
6. Multiple Topics & Instances
7. Partitions
8. Exclusive Ownership
9. Time and Content Filters
All this and more between multiple vendors
across different platforms!!
8
9. 1. Basic Connectivity
S2!
S1!
S1!
S2!
DDS
Global Data Space
You will see:
S3! ! Discovery
! Multi Platform
! Data
Interoperability
9
10. 2. Request/Offered QoS
S2!
S1!
S1!
S2!
DDS
Global Data Space
You will see:
S2! ! QoS Mis-match
! QoS Agreement
10
11. 3. Durability
S2!
S1!
S2!
DDS
Global Data Space
You will see:
S2! ! Volatile late
S1! joiner just gets
new data
! Transient late
joiner getting
history
11
12. 4. Reliability
S3!
S2!
S1!
DDS
Global Data Space
S3! You will see:
S4!
S2! ! High data rate
S1! ! Best-effort can
lose some data
! Reliable gets all
data!
12
13. 5. Robustness to network interruption
S3!
S1!
S2! S4!
DDS
Global Data Space You will see:
! Still-connected
nodes are not
S4! S3! effected by
node leaving
S1! the network
! Node is re-
discovered
automatically
13
14. 6. Multiple Topics, Instances
DDS
Global Data Space
You will see:
! Multiple Topics
(shapes)
! Multiple Keys
(colors)
14
15. 7. Partitions
A
B DDS
Global Data Space
C
You will see:
! Three partitions
! Subscribers see
data only on
the requested
partition
15
16. 8. Exclusive Ownership
DDS
Global Data Space
You will see:
! Multiple
publishers of an
instance
(orange square)
! Automatic
ownership
determination
16
17. 9. Time and Content Filters
DDS
Global Data Space
You will see:
! You get the
data you want
at the rate that
you want
17
18. Interoperability demonstrated along many dimensions
Today we demonstrated:
! Discovery
! Different platforms (Linux, Windows, MacOS, Gumstix)
! Different Data-Types
! Different Topics
! Different Qos (RELIABILITY, DURABILITY, OWNERSHIP)
! Unicast & Multicast, both reliable and best efforts
! One to Many and Many to one communications
! Time Based Filters, Content Based Filter
! Robustness to network interruption
18
19. Conclusions
! DDS Interoperability Works!!
We will continue working on additional scenarios
Vendors are committed to interoperability
! The DDS Standard and DDS-RTPS Interoperability
standards are complete and usable
A non-OMG vendor was able to use the OMG standard
documents and produce an interoperable DDS product
! DDS truly is the most open interoperable publish-
subscribe communications infrastructure
! Come see more at the booths!
19