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 2

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.

Use MATLAB to Leverage Your Live IoT Data Reply

leverage live data MATLAB DDS

If you have ever done any data analysis from a sensor or other type of data source, you have most likely followed a process where you collect the data, you convert the data and then use MATLAB to process and analyze the data.  Using  MATLAB to analyze the data is a very well known tool to accomplish that task.  Collecting and converting the data, so that it is usable in  MATLAB, can take an enormous amount time.  Thanks to an integration that was completed by MathWorks, it is now possible to easily connect  MATLAB up with live data that is being published and subscribed to on DDS.  With  MATLAB being one of the top tools used to analyze data and DDS quickly becoming the data communications middleware of IIoT applications, this integration will enable some very rapid prototyping and test analysis for developers.  This blog post will walk through a few examples of how to publish DDS data and also how to subscribe to DDS data using  MATLAB.

Getting Started

To get started, you will need to make sure that both  MATLAB and RTI Connext DDS are installed on your computer.  For this set of examples, the following versions were used:

Once you have those installed, just follow the video at this link to complete and verify the installation:  Installation Video

Initialization

Once you have everything installed and verified, then there are just a few steps to get DDS setup appropriately within  MATLAB.

  •  Import the datatype(s) that will be used in your project.
  •  Create a DDS Domain Participant
  •  Create a DDS DataWriter
  •  Create a DDS DataReader

Importing a datatype in  MATLAB is simple.  In DDS, datatypes are specified using IDL files.  The  MATLAB import statement can read an IDL file directly and will create the “.m” files required to work with that datatype within the  MATLAB interpreter.  The following  MATLAB call will import a datatype called “ShapeType” from the ShapeType.idl file located in the current working directory:

>> DDS.import('ShapeType.idl','matlab','f')

Now that datatype is available to use when creating your DataReaders and DataWriters of topics in DDS.  Also note, that once the import has been done, this step no longer has to be run in the future.  The type will be available in  MATLAB going forward.  The next thing to do to get DDS discovery going is to create a DDS Domain Participant.  That can be accomplished in this call:

>> dp = DDS.DomainParticipant;

Using this DomainParticipant (dp) object, you can then create both DataWriter and DataReader objects.  The following two commands will add a datawriter object and datareader object to the dp specifying its type to be the newly created “ShapeType” and their topics to be “Triangle” and “Square” respectively.

>> dp.addWriter('ShapeType','Triangle')
>> dp.addReader('ShapeType','Square')

Subscribing to Data in Shapes Demo

The ShapeType is used so that it will communicate with the standard RTI Shapes Demonstration application (Shapes) that is provided by RTI.  Shapes enables the creation of both DataWriters and DataReaders of “Square”, “Circle” and “Triangle” topics that are in turn based on the “ShapeType” datatype.  For more information on how to use the Shapes application, click here to view our video tutorial.

In Shapes, the next step is to create a subscriber of Triangle. In the next screen just leave all the other QoS options as default.

createsubscriber2

Publishing Data in  MATLAB

Now that we have the DataWriter setup in  MATLAB to send out ShapeType on the Triangle topic, and also we have the Shapes Demo setup to receive the publication, lets exercise the writer.  The following commands will populate the fields of the ShapeType and then publish out the data on the Triangle Topic:

%% create an instance of ShapeType
myData = ShapeType;
myData.x = int32(75);
myData.y = int32(100);
myData.shapesize = int32(50);
myData.color = 'GREEN';

%% write data to DDS
dp.write(myData);

The result on the Triangle Topic within the Shapes Demo will be a single Green Triangle shown here:

greentirangle

Some more interesting use cases of publishing Triangle within  MATLAB are:

%% Publish out Green Triangles in a line at 1 Hz
for i=1:10
    myData.x = int32(20 + 10*i);
    myData.y = int32(40 + 10*i);
    dp.write(myData);
    pause(1);
end

%%  Publish out Green Triangles in a Circle pattern at 20Hz
for i=1:1000
    angle = 10*pi * (i/200);
    myData.x = int32(100 + (50 * cos(angle)));
    myData.y = int32(100 + (50 * sin(angle)));
    myData.shapesize = int32(40);
    myData.color = 'GREEN';
    dp.write(myData);
    pause(0.05);
end

The resulting output on the Shapes Demo are respectively:

multigreentirangle             greentirangleincircle

Publishing Data in Shapes Demo

In the Shapes demonstration, create a publisher of Square.  In the next screen just pick a color and leave all the other QoS options as default.  The following screenshot shows the Square Publish screen.  For my demonstration, I have chosen an Orange Square.  This will publish the X,Y Position on the screen every 30 msec.

createsubscriber                orangesquare

Subscribing to Data in  MATLAB

If you remember from before we added a Square Topic DataReader to the Domain Participant in  MATLAB.  We will use this DataReader to subscribe to data that we are now publishing from the Shapes Demonstration.  The following commands in  MATLAB will read 10 samples at 1 Hz.

%% read data
for i=1:10
    dp.read()
    pause(1);
end

The resulting output in  MATLAB will be 10 reports of the following:

f8bba2cee2ff4c0ebb94080665ce894b

Something More Interesting

Now that we have both directions going, lets do something that is more creative with the data.  First we will read in the Square data and modify it to switch the X and Y coordinates and then republish it out on to a RED Triangle.  Second, we will take the resulting Position data and plot it directly within  MATLAB.  These are the commands to use in  MATLAB to accomplish that.

%% allocate an array of 100 elements
xArray = zeros(1,100);

%%  run a loop to collect data and store it into the array
%%  also switch up the X and Y coordinates and then republish onto 
%%  the Triangle topic
for i=1:100
       [myData, status] = dp.read();
       if ~isempty(myData)
            x = myData(1).x;
            y = myData(1).y;
            xArray(i) = x;
            yArray(i) = y;
            myData(1).y = x;
            myData(1).x = y;
            myData(1).color = 'RED';
            dp.write(myData(1));
       end
    pause(0.05)
end

%%  Plot the X Position Data
t = 1:100;
plot(t,xArray);
legend('xPos');
xlabel('Time'), ylabel('Position');
title('X Postions');

The resulting output in Shapes Demo will be a Red Triangle moving the opposite of the Orange Square and also a Plot will be generated within  MATLAB showing the X Position data:

orangesquare_redtriangle       xposgraph

As you can see, the integration of DDS with  MATLAB is very simple to use and makes it very easy to collect data, inject data and analyze data.  For this demonstration, we used the simple Shapes Application, but the data used can just as easily be your own application data.  If you would like to find out more about the  MATLAB Integration with RTI Connext DDS, please visit this site on MathWorks site:  MATLAB DDS Integration. If you’d like to learn more about using Connext DDS, click here to gain access to our developer resources.