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.

Security for IoT: What can Industrial IoT learn from the recent DDoS attack? Reply


screen-shot-2016-11-02-at-1-48-06-pmThe Mirai DDoS (Distributed Denial of Service) attack last Friday revealed a fundamental weakness of current IoT deployments and showed the absolute necessity of new security models. The DDoS attack was against consumer IoT device, but there are many parallels between Consumer IoT and Industrial. This attack involved 10s of millions of IP addresses[i], a massive and unprecedented number of devices. Unfortunately, it seems like it was fairly easy to carry-out, especially since the source code for the Mirai botnet is easily accessible. The primary tool to hack into an array of consumer IoT devices (internet enable cameras, DVRs, etc) was a set of default, manufacturer-set passwords. [ii] How many have run into default passwords on operational industrial devices? Or perhaps it would be better to ask, how many have ever run across a password that has been changed? The latter would probably be easier to count.

It is easy to think that this particular attack may not take the same form in an industrial network. There are a variety of differences in network design, types of devices used, network management, and access control. However, the strategy used in this attack is very relevant to industrial applications. Exploit one or many compromised devices, which are not the main target, to take down another device or the entire network – we need to plan for a defense against this type of an attack.

There are some key characteristics of this attack, especially with regard to the devices they were launched from:

  1. The devices are deployed to remote and difficult to manage locations. Software updates are sporadic if they happen at all.
  2. The devices run without direct maintenance or operator involvement. ‘Administrators’ if involved at all, just set it and forget it.
  3. Devices have access to a wider network and are sharing data in the network.
  4. The device can be easily compromised.
  5. The data on the network relies on a level of network or transport security, and is not inherently secure.
  6. The compromised devices weren’t the end target, but tools to achieve a different objective. This implies there is little incentive for the device manufacturers to spend money to design secure systems.

Does this sound like an industrial network you have worked with? It does to me.


Although we’d like to think that industrial devices and networks have better security than this, unfortunately this is not the case. We only need to look to the 2015 attack on Ukraine electricity distribution SCADA systems for proof. Industrial networks have relied primarily on anonymity and isolation from public networks for their security. But as more devices are deployed in industrial applications, and more private networks are connected to the web this is no longer nearly adequate. Access to these networks is not always a direct attack but could be from a physical breach (e.g. the Stuxnet attack), which can open up a hole in security firewalls to further compromise devices. Not to mention unintentionally compromised networks due to poorly designed software. IoT system should be designed with the assumption that there will be bad actors within the network that we can’t keep out. Technology and standards used must be designed to mitigate potentially adverse impact of such actors. So what is the solution?

The first requirement is securing the devices themselves; the industry needs to improve and develop systems for signing and securing everything from the hardware chips up through the OS, libraries and applications that have permission to run. This is fundamental. Bottom-up security must be the norm for these networks. Chain of trust, secure boot, and secure operating systems using trusted, signed software must be a requirement to operate in industrial networks.


However, we can’t assume all devices on a network are secure and must plan for operation when devices or applications are compromised. Data is critical to the operation of an industrial network and security should be a fundamental quality of any data.

Is there a standard that makes security part of the infrastructure, and is simple to implement yet highly robust? Yes, the OMG Secure DDS standard and RTI Connext® DDS Secure is just such a solution.  RTI Connext DDS is based on the OMG Secure DDS standard and include features such as:

  • Discovery authentication
  • Data-centric access control
  • Cryptography
  • Tagging & logging
  • Non-repudiation
  • Secure multicast

Not only that, but it is transport agnostic, and is built with a plug-in architecture. This means that security of data and communication is independent of the network transport used and the standard security libraries can be replaced (using standard APIs) to suit the application’s security requirements.


There are key differences between the Secure DDS approach and other network security solution. With DDS:

  1. Security is part of the infrastructure and included in the Quality of Service metrics.
  2. It enables fine-grained access control of the data, what we call data-flow security, at a data topic level.
  3. It allows for a combination of security functions that can include encryption, authentication and access control so security can be fine-tuned to the needs of the data topic.
  4. All of this is done by configuration, so the application programmer does not need to understand or manage the security implementation, it can be handled by the system architect.

Secure DDS a fundamentally different approach to security that builds security into the infrastructure from the start. This has many positive benefits to ease of use, performance and robustness of the security architecture. But don’t take our word for it, ask our customers that are using DDS Secure on some of the most critical network applications.

The tools exist, we just need to use them and plot a path to migrate into this new secure paradigm. You can learn more about RTI Connext DDS Secure here and please contact me if you want to learn more about RTI’s solutions for securing the IIoT.




Join RTI and Mentor Graphics to Discuss System Security and the Industrial IoT Reply


On November 2, 2016, Warren Kurisu, Director of Product Management at Mentor Graphics, and I will be discussing how to implement reliability and security in Industrial IoT (IIoT).  We know these qualities are important for IIoT, but the scale of the problem, and the scale of the networks involved, can present a challenge to anyone trying to implement real-world solutions. Although nothing is easy in this new hyper-connected, innovative, data-driven world, when you understand the right approach, the problem isn’t nearly so daunting.

Warren and I will be discussing some of the issues regarding the scaling of large, heterogeneous systems and how to address security and scale with a layered databus architecture. We will touch on the recent work by the Industrial Internet Consortium (IIC) on the IISF (Industrial Internet Security Framework) and the IIRA (Industrial Internet Reference Architecture).

Mentor Graphics is investing in the operating system, security and the platforms needed for IIoT. RTI is leading the charge with standards-based dataflow security and a connectivity framework — or databus — needed for the IIoT. I am looking forward to the discussion with Mentor Graphics and working with them to deliver real-world solutions.

You can read the webinar abstract and register for the event on Mentor’s website.