Getting Started with Connext DDS – ELI5, please. Reply

GettingStartedBlog

One of my favorite subreddits is r/ELI5. For those of you who might not know, ELI5 is a forum, dedicated to offering up explanations of user-submitted topics and concepts in a very specific way – explaining it in a way that even a 5-year old would understand, hence ELI5 (Explain it Like I’m 5).

ELI5 is a pretty popular subreddit. Why? Well, I believe it’s because there are tons of things we don’t know much about (we’re all experts in one area or another, but we don’t know everything!), and these posts give us a chance to gain some basic knowledge outside our area of expertise. Making information simple benefits everyone. Simplicity doesn’t mean a lack of complexity. Being able to take a complex subject that you’ve spent years immersed in, and distil it down to some facts and anecdotes that provide a level of working understanding is amazing – it makes information accessible.

ELI5 doesn’t mean the thing you’re describing isn’t interesting, valuable or worthy of more time and attention. Being able to ELI5 allows people with little to no domain knowledge or context on these more complex and nuanced subjects to understand the basics and to incorporate those basics into other things. It’s general, but it’s useful. If you can give a 5-year old a working understanding of things such as what is a product?, why do we have a president?, or what is middleware?, you really have to understand what you’re talking about.

From my perspective, DDS is powerful – and can be complex – and we hope we’ve made it accessible enough that you can do amazing things with it.

At RTI, we’ve been working behind the scenes to bring you something new. In the spirit of my favorite subreddit, I want to introduce you to Getting Started – all the tools and information you need to get started with DDS.

We explain how to use our products, how to go from install to helloworld, what DDS is (whitepapers), how people are using it, how you can setup the basics using our full sets of configuration files and code to address your most common and challenging use cases (case+code) and more. We’ve even curated special collections of content to meet your needs so you don’t have to wade through everything. And this is only phase 1 – we have so much more information that’s just waiting to go live, and we’re excited to share it.

Ready to take the leap? Check out the first step! Installation for Linux or Windows, take your pick!

And as part of making sure you’re getting what you need, let us know. What would you find valuable to get up and running using DDS? What questions did you need answers to, but had trouble finding? What content did you wish was available that wasn’t when you first started using our product? Tell us or leave a comment!

Standards vs. Standardization: How to Drive Innovation in Self-Driving Cars Reply

Standards BP

Authors: Bob Leigh & Brett Murphy

There was a great article in the NY Times recently that suggested self-driving cars may need some standards to foster innovation. This is certainly true, but the article confuses standards and standardization, suggesting that standardizing on a common automotive platform may instead stifle innovation. It is important to understand the difference between the decision to ‘standardize’ on a platform, and the very powerful impact an interoperability standard can have on an industry.

Common platforms spur innovation by creating an ecosystem and simplifying development efforts. One can choose to standardize on a proprietary platform, like the Apple iPhone, where the main goal is to develop an ecosystem and create applications for the platform itself. Standardizing on a walled-garden platform like this can certainly spur innovation like it did in the early days of the iPhone, but it also creates silos and rarely allows for broad interoperability outside of the, often proprietary, platform. App developers for smartphones had to develop and maintain at least three different versions early on in the market. Alternatively, standards, which are managed by an independent governing body, can be truly transformative for the entire industry and allow everyone to participate in developing the ecosystem. For example, TCP/IP, HTTPS and RESTful services have been transformative standards for networking and web applications. In this case, open standards provide a foundation for developing applications and systems that run almost anywhere. These two approaches are not always mutually exclusive, but they have different objectives and results.

For the IIoT (Industrial Internet of Things) to truly transform industrial systems, businesses and industries, a standards-based approach is necessary. For autonomous systems and especially self-driving cars, this is especially true because these systems need to bring together the best technologies from many different independent companies and research organizations, while also fostering rapid innovation. I agree with the author; the industry does not need one-size fits all solutions, or a closed, proprietary platform. This can stifle innovation, creating closed ecosystems, siloed architectures and de-facto monopolies. However, the right standards-based approach will support interoperability between different vendor solutions. The key is to identify the critical interfaces and standardize them. For example, how data is shared between applications running on different devices and systems is a key interface. The right standard will foster an open architecture driven ecosystem and act as a deterrent, or brake, to proprietary and closed ecosystems by being a neutral interface between competing interests.

Very few standards can accomplish this task. Given that IIoT is a relatively new technology and that there are many interoperability standards out there, how is one to choose? Fortunately, the Industrial Internet Consortium has done much of this work and has developed a very detailed analysis of IIoT connectivity standards and best practices (See the Industrial Internet Connectivity Framework (IICF)).  This document presents a connectivity stack to ensure syntactic interoperability between applications running across an IIoT system.  It assesses the leading IIoT connectivity standards and establishes criteria for core connectivity standards. Using a core connectivity standard is best practice and helps ensure secure interoperability. It details four potential core connectivity standards and the types of IIoT systems best addressed by each.

For Autonomous Vehicles, the choice couldn’t be more clear. Autonomous vehicles have created unprecedented demand for both the rapid innovation required for commercial technology and the performance, security and safety required of complex industrial systems. Comparing these requirements with the assessments in the IICF, it is clear the only connectivity standard that suitably addresses these challenges is the OMG’s DDS (Data Distribution Service) standard. DDS is playing a critical role in the IIoT revolution and is already disrupting in-car automotive technology as well. DDS acts as a common language between all the devices, applications, and systems, which is especially important in Autonomous Vehicles as this can hasten innovation and drastically lower the risk of integrating all these disparate systems. DDS offers next generation standards based security, control at the data level, and a proven track record in multi-billion dollar mission and safety-critical systems worldwide.

It is an exciting time to be involved in this industry. The complexity of the problem, and the speed of innovation is going to create clear winners while others will struggle to stay relevant. As we have seen in the storage, computing and networking industries in the past, winning often depends on choosing the right standard. So, how will you ‘standardize’ to foster innovation?

You can learn more about DDS’s role in IIoT, or if you want to learn about using DDS in Autonomous Vehicles See RTI’s white paper titled Secret Sauce of Autonomous Cars and learn more about adding data-flow security with our DDS Secure product.

Industrial Internet Connectivity Document Evaluates Core Standards: DDS, OPC-UA, WebServices 3

The Industrial Internet Consortium has released an important part of its Reference Architecture guidance: its Connectivity Framework document. This is actually pretty important; this document dives into the detail on connectivity for IIoT systems, establishes criteria for evaluating connectivity technologies/standards and puts forward some likely technologies for core connectivity standards, including DDS, OPC-UA and WebServices. In other words, there is some really valuable guidance here.

What is Connectivity for IIoT Systems?

According to the Industrial Internet of Things Connectivity document, “connectivity provides the ability to exchange information amongst participants within a functional domain, across functional domains within a system and across systems. The information exchanged may include sensor updates, events, alarms, status changes, commands, and configuration updates.” More concretely, connectivity is the critical, cross-cutting function that supports interoperability within and across IIoT systems. Moving beyond the current mish-mash of proprietary and vertical-industry-specific standards to an open IIoT standards-based framework is the goal of this work.

Looking at Connectivity from a technical viewpoint, figure 1 shows where the Connectivity function lies on a Network, Connectivity, and Information stack, and it divides Connectivity into 2 different layers: Transport and Framework. The Transport layer provides technical interoperability, with “Bits and Bytes shared between endpoints, using an unambiguously defined communication protocol.” The Framework layer provides syntactic interoperability, with “Structured data types shared between endpoints. Introduces a common structure to share data; i.e., a common data structure is shared. On this level, a common protocol is used to exchange data; the structure of the data exchanged is unambiguously defined.” Addressing connectivity needs up through the syntactic interoperability provided by the connectivity framework layer and assessing connectivity framework standards is one of the important contributions of this document.

iicf_connectivity_stack

Figure 1. Connectivity, using the Networking functions below – Internet Protocol, provides the layers for communicating messages and data between system participants.

The Concept of a Core Connectivity Standard.

To ensure interoperability within and across IIoT systems, the Connectivity Framework document recommends the use of a core connectivity standard. Figure 2 shows how this core standard becomes the connectivity bus for the system, integrating native devices and applications directly and legacy, or non-core-standard devices and applications through protocol gateways or bridges. In this way non-standard entities can be “normalized” into the core connectivity standard. This core connectivity reference architecture is central to the IIC’s guidance on ensuring secure, device to device to application interoperability for IIoT systems.

connectivity_ref_arch

Figure 2. Using a Core Connectivity Standard provides for interoperability and streamlined integration within and across IIoT systems.

Evaluating Connectivity Standards.

To reduce the integration and interoperability challenge across different IIoT systems, a key goal of the IIC, the document provides a method and template for evaluating connectivity technologies and standards for the IIoT. It includes assessments of most IIoT standards like DDS, OPC-UA, HTTP/WebServices, OneM2M, MQTT and CoAP. Many of these standards turn out to address different levels of the connectivity stack as you can see in figure 3. Further details on each standard are provided in the document.

iiot_protocol_stds

Figure 3. IIoT connectivity standards and their location on the connectivity stack.

DDS as a Core Connectivity Standard.

From figure 3, you can see that the document assesses 4 connectivity framework standards including DDS. In addition, the Connectivity Framework document provides guidance on requirements for choosing core connectivity framework standards. A core connectivity framework must:

  • Provide syntactic interoperability
    • Provide way to model data, a type-system (e.g. DDS, OPCUA)
    • Can’t be just a “simple” messaging protocol (MQTT, COAP, etc)
  • Be an open Standard with strong governance:
    • from SDOs like IEEE, OASIS, OMG, W3C, IETF
  • Be horizontal & neutral
  • Be stable and deployed in many industries
  • Have standards-defined core gateways to all other connectivity core standards
  • Provide core functions like publish-subscribe, request-reply, discovert, etc.
  • Meet non-functional requirements: performance, scalability, security, …
  • Meet business criteria: not require single components from single vendors, have supported SDKs, have open source implementations, etc.

In figure 4, you can see the 4 potential core connectivity framework standards assessed against these requirements. DDS supports all the requirements and is a promising standard for IIoT systems across all industries.

core_connectivity_table

Figure 4. IIoT Connectivity Core Standards Criteria applied to key connectivity framework standards.

In particular, if you compare DDS with another promising connectivity framework standard, OPC-UA, from figure 5 below, you can see that they address very different system use cases. If your primary challenge is integrating software applications across an IIoT system, then DDS is a good choice. If you challenge is to provide an interface for your edge device to allow system integrators to later integrate it something like a manufacturing workcell, then OPC-UA is a good choice.

system_aspects

Figure 5. Non-overlapping system aspects addressed by the core connectivity framework standards.

As you can see, this IIC document provides a lot of important guidance and clarifying concepts for IIoT connectivity. You can use it’s IIoT connectivity standards assessment profile to assess other standards you may be interested in for your system, or use its guidance to choose among the leading standards. For more detail download the document for yourself.