Is Your Security Tail Wagging Your Architecture Dog? 4

tail wagging the dog

Recently, as a leader in the IIoT, I seem to get a lot of questions from insurance company executives. Their common question: where is the risk in the IIoT? Their theme seems to be: connecting things is just too risky. We don’t understand the security or safety risks, so It Can’t Be Good.

I disagree.

I do agree that the IoT is a brave new world in general, and for risk management in particular. There are all sorts of new opportunities for mischief if a machine is compromised. The hack that caused a Jeep to go off the road by getting into the tire pressure monitoring system is a classic example.

That said, intelligent machines also have more opportunity to protect themselves. The sad truth today is that most systems are very poorly protected (like that Jeep). Security gets orders of magnitude more attention today than only a short time ago. Most industrial systems didn’t even consider anything beyond “eggshell” firewalls or “air gap” offline designs until recently. That has changed 100% today; everyone is thinking security, security, security. And progress is exhilarating. Put another way, I think that everyone is installing cyber “burglar alarms” much faster than the increase in burglars. Bottom line: despite the rise in connected systems, the “likely real” risk is going down in most cases.

My insurance contacts consider this an overly optimistic view of the future. I counter that they hold a too-optimistic view of the present. You see, I claim that the situation today is unacceptably, intolerably, unbelievably high risk. Entire industries run without a whit of security. It seems scarier in the future only because the risk you don’t know seems worse than the risk you do know. That’s human nature. But anyone who looks will see that the current risks are very high, and the new designs are much better.

That said, my real optimism stems from the opportunity to change. In my experience (and this may shock security wonks), security is not a change driver. By that, I mean that industrial systems are usually not willing to implement a new architecture (just) to improve security. The power industry is my favorite example. The industry has been screaming for 20 years that security is a problem. And, imho, they will go right on screaming…unless something else drives the change.

The good news: the IIoT is that change driver. And security today is absolutely a change gate. Every application insists on security when they do implement a new architecture for other reasons. Since the IIoT is motivating many, many industrial applications to redo their architectures, security is getting better. Of course, implementing a new architecture for a major industrial application, or for that matter an entire industry, is daunting. But this is the magic of the sweeping changes offered by the IIoT. The IIoT is compelling. Change is coming, and it’s coming fast.

While we’re on the topic of change, let’s not discount improvements in technology to enable that gate. For instance, many potential IIoT systems primarily face scalability and system integration challenges. With a little thought, the architects figure out that IIoT systems are all about the data, and then that they really have a high-performance data flow and data transparency challenge. The best way to provide transparent flow is a “peer to peer” or “publish subscribe” design. This is the architecture “dog”: systems need the simplicity and performance of a communications pattern that simply sends the data where it’s needed, right now. That data transparency makes the huge future IIoT system manageable.

Of course, although data transparency is an integration dream, it’s a security nightmare.

The “dog” side of the dialog goes something like this:

Hey! Let’s just send the data right where we need it. Pervasive data availability makes systems fast, reliable, and scalable. And look how much simpler the code is!

But, then comes the security “tail”:

We can’t maintain thousands of independent secure sessions! How do we keep such a system secure?

Only last year, that was a damn good question. It blocked adoption of IIoT technologies where they are really needed. But then, the DDS standard developed a security architecture that exactly matches its data-centric data flow design. The result? The data-centric dog wags its perfectly-matched data-centric security tail. Security works seamlessly without clouding data transparency. Advances like this—that span industries—will make future IIoT systems much more secure than today’s ad-hoc industry-specific quagmire of afterthought security hacks. Security that matches the architecture is elegant and functional.

This argument leaves my insurance correspondents searching for Tao in their actuarial tables. So, I can’t resist adding that it’s not really what they should worry about.

Safety engineering will be a much bigger impact on insurance. For instance, I expect the $200b auto insurance industry to disappear in the next 10-20 yrs as ADAS and autonomous cars eliminate 90+% of accidents. Most hospital errors can also be prevented (hospital error is currently the 3rd leading cause of death in the US). In factories, and plants, and oil rigs, and mining systems, and many more applications, automated systems (somewhat obviously) don’t have humans around, thus removing a significant current risk today. Accidents, in general, are mostly the result of human folly. Machines will soon check or eliminate the opportunity for folly. I see this as an extremely positive increase in the quality and preservation of life. Insurance execs see it as an existential threat.

I tell them not to feel bad; most industries will be greatly disrupted by smart machines. Navigating that transition well will make or break companies. Insurers certainly understand that losses are easier to grasp than gains; that principal underwrites their industry. But, that perception is not reality. The IIoT’s impact on the economy as a whole will be hugely positive; the analysts measure it in multiple trillions of dollars in only a few years. So, there will be many, many places to seek and achieve growth. The challenge to find those paths is no less or greater for insurance than for any other industry. But, fundamentally, the IIoT will drive a greener, safer, better future. It Is Good.

To learn more about our security solutions, visit

DDS Proof Points for Autonomous Cars Reply

autonomous car design rti connext dds

While implementation details for autonomous cars are still tightly guarded design secrets, deployment examples in adjacent markets provide a wealth of information about DDS and its ability to solve the most challenging connectivity problems.

The following use cases have one or more connectivity issues in common with autonomous cars. Autonomous car requirements span three main areas: performance, safety, and integration. Systems must ensure performance to successfully connect components, optimize safety at every level of a fully autonomous system, and make it easier to reliably integrate complex software from diverse components.

Performance: Revised Approach to Automotive System Testing

Familiar names such as Audi and Volkswagen are among the carmakers that have already introduced RTI Connext DDS to enable high-performance connectivity for testing and enhancing today’s smart cars.

  • Audi replaced a proprietary fiber network and test rig with a DDS databus, for a more flexible way to connect multiple simulation vendors’ systems. RTI middleware enables a modular test environment with the speed to handle data coming from all of the electronic systems in a vehicle during simulated. Additional details can be found here: A New Architecture for Hardware-in-the-Loop Test via ATZ Elektronik
  • At Volkswagen, autonomous vehicle algorithms are part of the company’s efforts to evolve driver assistance and integrated safety. The system combines radars, laser range finders, and video to assist safe operation. VW uses RTI Connext DDS to help drivers avoid obstacles, detect lane departures, track eye activity, and safely negotiate turns. The DDS protocol connects all of the required components to create a single, intelligent machine with driver-assistance features and integrated. Read more…
  • Volkswagen has also used DDS technology in an electric vehicle capable of autonomously driving to and from a recharging station after dropping off

Resilience and Safety: Unmanned Aircraft

Engineers of aeronautic and defense systems have long relied on RTI’s award-winning infrastructure technology to develop unmanned aircraft as well as unmanned vehicles for deployments on land and under water.

DDS aligns with many open architecture initiatives including the Future Airborne Capability Environment, UAS Control Segment Architecture, and Open Mission Systems. Connext DDS Cert also helps developers of Unmanned Air Systems prepare for integration into the National Air Space. Connext DDS Cert accommodates communication requirements while minimizing the amount of custom code that must be certified.

Stringent safety requirements within this industry segment closely resemble automotive compliance specifications. The certification process depends on close collaboration between technology vendors and solution designers – and in the case of autonomous cars, RTI has already established working relationships with vehicle manufacturers. These joint efforts and investments will ensure the required certifications and safety levels the automotive industry requires.

System Integration: Healthcare

Advanced device connectivity is changing medical practices, lowering costs, and improving patient outcomes. Current medical applications of RTI Connext DDS Autonomous Cars White PaperDDS demonstrate how it can help integrate complex distributed subsystems and devices in a manner that ensures the required performance. For example, RTI Connext DDS provides precise, distributed control for the subsystems within leading-edge computed tomography (CT) imagers. In hospital infrastructures, RTI’s DDS implementations are also in use to connect a myriad of technologies for patient monitoring and diagnostics that power modern hospital equipment.

If you’re interested in discovering how you can use Connext DDS in autonomous car design to gain an undeniable competitive edge, download our latest white paper (here).

The Future of Automotive Reply

We’re working with our customers to share with you their stories and insights, to offer you a rare glimpse into the future of systems from some of the world’s most exciting and innovative industries and development teams. Enjoy!

rti - blog - future of - banner - AUDI

constantin - HIL AUDI AG

By Constantin Brueckner, Hardware-in-the-Loop Functional Test, AUDI AG

Your car is probably the most compute-intensive thing that you own. It will have at least 40-50 Electronic Control Units (ECUs) for a recent economy vehicle and well over 100 for a top of the range car. In the past, each of these ECUs had one dedicated function to perform. This evolved over time and most of the ECUs now perform more than only one single function or group of functions. Despite this evolution of ECU use, there is still an increasing need to reduce the number of ECUs and the cabling between them with the ultimate aim of increasing fuel economy and reducing CO2 emission, whilst providing the customer even greater functionality in the car. These additional demands are being met by a shift towards functional integration and communication between ECUs and between the car and its environment. This is one of many more reasons why the future of automotive test is becoming distributed and interconnected. Furthermore our test systems have to evolve as fast as the car functionality to encompass this change. To address these challenges Audi founded a pre-development department for test systems, which currently develops a real-time capable bus system based on RTI DDS for the future test systems.

But first, let us have a look in more detail at the shift towards ‘functional integration’ and explain it with following examples:

  • A simple former “air bag computer” fired the air bags at the time of a crash. This now becomes an integral element of the complex safety system with more safety functions to avoid great injury to the passengers in case of a crash. The new, so called, ‘safety computer’ has an automatic crash detection capability (“Audi pre-sense”) and it has to perform, for example, fully automated braking support, deploy the air bags, pre-tension the seat belts, close the windows and roof and move seats into an upright position.
  • Dedicated ECUs for radio, navigation and rear seat entertainment are evolving into a “main entertainment unit.”
  • Dedicated ECUs for body electronics like head light, interior light, and air conditioning, are combined into one “body control module” and enriched with new capabilities such as bending light, LED head light, parking assist, air condition and rain-sensing wipers.

Furthermore there is a new automotive safety assurance standard to comply with that reflects this change to a function-centric system view, ISO26262. Functional Safety is intrinsically end-to-end communication in scope. It has to treat the function of a subsystem as part of the function of the whole system. This means that whilst Functional Safety Standards focus on Electronic and Programmable Systems (E&PS), the end-to-end objectives for the approval process means that in practice functional safety review has to extend to the non-E&PS parts of the system that the E&PS actuates, controls or monitors.

Functional integration and this regulatory change are the issues driving a fundamental shift in how the HIL (Hardware-in-the-Loop) tool chain of automotive test departments has to be developed.

In the past, we would have to determine one HIL vendor before we set up a new HIL test bench to ensure that every particular subsystem can seamlessly work together with each other. Today we are moving from this all-in-one solution with monolithic HIL test benches provided by one single vendor towards heterogeneous and distributed test benches, which consist of several hardware modules from different HIL vendors, connected via the real-time capable HIL-Bus.

Why? Because no single HIL vendor has this previously mentioned all-in-one-solution, which meets all our test demands regarding distributed functions and highly integrated ECUs. As a result, we must choose the best-in-class solution for each sub-system and use those to develop a new test platform in which we have a high degree of confidence. The challenge is in how we go about integrating this set of HIL platforms from all of these different vendors in order to produce a new generation test bench for next generation cars and functions.

DDS-based HIL-Bus

Audi HIL test lab – showing how we integrate multi-vendor HIL systems together

The communication in cars has already moved from dedicated wire-based communication to a data-oriented bus communication using for example CAN bus or FlexRay. We have now transferred this bus-based approach from our cars to our next generation HIL architecture. We call this new approach ‘HIL-Bus based’.

Architectural view of the distributed HIL environment

Architectural view of the distributed HIL environment

To realize this bus-based approach for HIL-test-benches we need a data-centric bus representation mechanism to be the conduit of state information.

For the technical realization Audi decided to use RTI Connext DDS with integration points for HIL vendor systems.

RTI not only provided us a market leading implementation of DDS with their Connext DDS product, but their OCS (Open Community Source) license model gave us the ideal commercial framework to work within to develop an open market ecosystem for the HIL-Bus concept. OCS enables our HIL-Bus partners to have free access to RTI Connext DDS for their development and deployment. It thus removes a major inhibitor to adoption across the industry. It allows partners to focus resources on integration and quality.

Additionally we drive and focus on open international standards like the ASAM XIL-API to seamlessly integrate test automation software for 24/7 automated and deterministic tests and experimental software tools for manual testing.

Today we are working with multiple HIL system vendors to evolve this ecosystem and to instantiate the HIL-Bus as the ideal method for end-to-end functional system test.

For more information on HIL-Bus testing, we suggest this joint Audi/RTI article by Bettina Swynnerton of RTI and myself that was published in ATZ Elektronic in July 2014.

To learn more about ASAM XIL-API visit the ASAM website