Home > Analysis > Safety and security: the core of critical system design

Safety and security: the core of critical system design

Michael Nash talks to Dan Mender from Green Hills Software about the importance of considering safety and security when designing connected vehicle features

Advances in connected car technology has led to OEMs designing into vehicles a host of new connected features, linked in a variety of ways including Bluetooth and, increasingly, Wi-Fi. According to a report by consulting firm McKinsey & Company, the global market for connected car components and services will rise from €30bn (US$32.63bn) to €170bn by 2020.

However, consumers are ever more concerned about the security of connected cars. The McKinsey report includes results from a survey in which 54% of respondents said they would not even consider buying a connected car for fear of hacking.

From the ground up

This reflects the need for OEMs and Tier 1 suppliers to ensure safety is at the top of the list when it comes to designing new connected car features. “Safety and security is not being considered from the beginning, which is a big cause for concern,” Dan Mender, Vice President of Business Development at Green Hills Software, explained to Megatrends. “It simply cannot be an afterthought for any connected system, but instead must be the very core of the design. This means that safety measures can’t be patched-in at a later date like they are on a desktop computer.”

Some of the operating systems that are being used by Tier 1s and OEMs to design new connected car features are inherently unsafe, he continued. Linux, for example, has around 5,000 security vulnerabilities that are widely known. “Every three days, a new vulnerability in Linux is reported. To use this as the basis for connectivity in a critical application is suicide. I’m not suggesting that companies shouldn’t use Linux, but they need to use it in the manner for which it was intended – and that’s absolutely not the operation of safety-critical systems.”

Safety and security is not being considered from the beginning, which is a big cause for concern

Tier 1 suppliers provide electronic control units (ECUs) to OEMs for various different systems, from the brake controls to the human-machine interface (HMI). ECU is a generic term for an embedded system that controls an electric system or subsystem, with most new cars having around 80 in total.

While Tier 1s are extremely good at developing these ECUs with certain functions and offering them to their customers, said Mender, there is a need for an adjoining system that differentiates between all the various types of ECU in a vehicle. “One of the major trends that we’re seeing is ECU consolidation and mixed criticality functions,” he revealed. “Non-critical features, like infotainment systems, are being put alongside critical features such as advanced driver assistance systems (ADAS) within a single system, interacting and working together. We need to provide a platform that can deliver freedom from interference and separation of critical and non-critical features.”

Essentially, ensuring ADAS technology runs smoothly and reliably is vitally important, or ‘critical’, because failure or malfunction could have fatal consequences for the driver, passengers and other road users. Other features, such as infotainment systems or telematics, are non-critical.

Essential in autonomous

The number of critical systems will rise dramatically with the rollout of autonomous vehicle technology. This is because most, if not all, of the systems in the car will be connected in some shape or form to ensure they can function without physical input.

“When you start getting to Level 4 and Level 5 autonomy, there will be challenges we haven’t addressed yet in designing those systems,” Mender observed. “For example, there may not be a licensed driver in the vehicle when it is driving down the road. This means that we must be absolutely sure that the system can work safely, reliably and without failure, because otherwise the car could get stuck in the middle of a very busy and dangerous highway.”

Level 4 autonomous vehicles and beyond must be connected to the Internet, he continued, as they will need to access the Cloud to obtain data and information. This makes them inherently vulnerable to hacking, unless each of the systems used in the car is designed and developed with security and safety in mind from the very beginning.

We are seeing a major trend of OEMs migrating to use embedded virtualisation for mixed-criticality ECU consolidation

The number of companies already demonstrating autonomous driving technology on public roads today, and autonomous car concepts at trade shows, “is all the result of prototyping,” Mender emphasised. “They are not production-ready cars, even if they have the ability to drive down the highway or navigate through busy city streets.”

Many of these demonstration vehicles, he added, use a Linux operating system. “This means that the cars won’t have the level of safety and security needed for Level 4 and 5 autonomous driving,” said Mender. “Instead, it’s just a way for OEMs and Tier 1s to show that they have some fancy hardware.”

Software and simulation

Various approaches could help to ensure critical systems are reliable, robust and safe from hacks, said Mender. “The hardware-centric nature of traditional Tier 1s is evolving, and some are doing better than others by taking a more software-centric view,” Mender acknowledged. “As a software company, we are working with global OEMs and Tier 1s to help them make that transition from being hardware-centric to software-centric.”

Green Hills Software, he continued, has experience in providing a platform that can help differentiate critical from non-critical systems. Much of this experience was gained in the medical industry, and Mender thinks the same methods are applicable to the automotive industry.

“Virtualisation is the basis for this,” he stated. “We’ve been focused on embedded virtualisation for over 15 years, which is based upon our real-time operating system called Integrity. It’s not a whole new product or area for us, but it’s absolutely vital. We are seeing a major trend of OEMs migrating to use embedded virtualisation for mixed-criticality ECU consolidation.”

Integrity provides vehicle manufacturers and Tier 1 suppliers with a single platform for the development of both critical and non-critical systems. It relies on a technology called microkernel, which ensures the various different ECU functions in a vehicle can be safely separated.

As a software company, we are working with global OEMs and Tier 1s to help them make that transition from being hardware-centric to software-centric

Numerous other suppliers also offer virtualisation for product development, but in a very different form. Mender thinks many of these companies have developed virtualisation “in a way that hasn’t been designed with safety and security as a forethought.” Instead, he sees these tools as merely adding complexity, and also “adding another attack surface for hackers, because it comes with a new code that hasn’t been certified.”

Written in regulation

One of the main problems surrounding the development of connected and autonomous car features is that they are not regulated from a security standpoint. In October 2016, the US Department of Transportation’s (DOT) National Highway Traffic Safety Administration (NHTSA) issued a proposed guidance document that highlights best practices to address cyber security issues in the automotive industry.

The document outlines a number of key areas, such as information sharing, vulnerability reporting and self-auditing. The scope is broad, said NHTSA, and is “intended to cover cybersecurity issues for all motor vehicles and therefore applicable to all individuals and organisations manufacturing and designing vehicle systems and software.”

Mender thinks this broad scope essentially means that the guidelines are “open to interpretation.” Also, the best practices are merely guidelines as opposed to written in legislation. They are not mandated, which means there is no penalty for companies that disregard them.

It could take a long time for authorities to enforce an effective and accurate set of regulations that govern cyber security in the automotive industry. Such regulations, said Mender, need to be “strong enough to really dictate the exact level of security that is put in place for both critical and non-critical systems.” However, he believes that much can be learned from other sectors, such as the aviation industry. “The US government already uses a set of well-known and established standards around safety and security here, making sure that all systems are designed, tested and verified with security at the forefront,” Mender said. “The automotive industry does not have to solve this problem from scratch. Instead, it needs to take advantage of the lessons learned in other industries before reusing and re-purposing the architectures and techniques.”