Modern-day connected vehicles are perceived as “servers on wheels.” Even without fully autonomous systems, advanced driver-assistance systems (ADAS) provide the driver with a set of comprehensive driving aids such as traffic-sign detection and adaptive cruise control that generate megabytes of data per second. Routing, direction guidance, and traffic alerts based around global navigation satellite systems (GNSS) are now ubiquitous in most vehicles. Coupled with the increased use of infotainment systems, vehicle-to-vehicle (V2V), and vehicle-to-infrastructure (V2I) applications, the cars of today depend heavily on connectivity.
As more technology is used to assist the driver, or to drive the car autonomously, the need to make it completely safe is paramount. Systems must be reliable throughout the time the vehicle is in use, and the majority of them need to conform to functional safety standards such as ISO 61508 and ISO 26262. This includes failures due to component breakdown or malfunction due to hacking.
As many articles have revealed, the hacking of vehicles can take many forms. Adversaries have become adept at hacking cars through unanticipated vulnerabilities such as accessing a vehicle's network through a mirror's blind-spot detection network link, or through its internal Wi-Fi router. Security is a fundamental requirement for every electronics-based system in a vehicle.
Top Security Considerations
Figure 1 highlights some of the core security principles applied to automotive systems design. They equally apply to other electronic systems, such as those used for industrial applications. The key is maintaining a strict separation of the car's external interfaces from the internal domain. Within the vehicle, a plethora of electronic control units (ECUs) are used for discrete functions such as anti-lock brakes, comfort, drive train, etc.
Another consideration of securing every ECU—there may be up to 100 ECUs in a vehicle—is that they might collectively have 100 million lines of code, which presents significant software test and reliability challenges. An in-vehicle gateway is a prudent method of securely and reliably interconnecting all systems across the heterogeneous vehicle networks. Such an approach provides both physical, process, and protocol isolation between all functional domains within a vehicle.
Gateways provide the means to allow only the applications that need to communicate externally to do so, which can be applied on a case-by-case basis. This is particularly the case when systems need to update themselves using an over-the-air (OTA) firmware update. Systems aren’t only vulnerable to being hacked and their safe operation compromised, but the intellectual property, such as code, passwords, and machine-learning (ML) algorithms contained within the ECUs, represent significant value.
Personally identifiable information (PII) is a significant concern, with many nation-states having strict penalties for companies that fail to protect information entered by the vehicle user. Total PII may include not only the usernames and passwords we all regularly use to access online services, but it can extend to biometric information employed by vehicle systems to identify the driver or owner. As the system complexity increases within the vehicle, it’s highly likely that ML techniques may be incorporated to detect and prevent user anomalies, penetration techniques, and potential adversarial attacks.
Automated-System Safety
As automotive manufacturers already know exceptionally well, safety is a board-level topic due to the legal responsibilities placed upon them. Owners put their trust in the manufacturer that the vehicle will always behave as intended when driving the car. However, as we move beyond the SAE autonomy Level 2 (Fig. 2), the responsibility for the operation and the real-time appraisal of the driving environment shifts away from the human driver to the automated systems that are operating the car.
Automotive Safety Integrity Levels (ASIL) are a core part of the ISO 26262 functional safety standard as it applies to automotive systems. They define the severity, exposure, and controllability of hazards that can be encountered within any system. A “V” model requires that the behavior of each software component is fully specified, verified, and fully traceable. It also covers the potential for enhancements and the requirement for them to conform with and meet the initial specification. When it comes to ML-based systems, for example, conducting inference to determine if the object detected is another car, a human, or a signpost, the software’s behavior isn’t easy to model since it’s incredibly dynamic.
There’s the belief that autonomous systems need to move beyond the traditionally static nature of functional safety and embrace the concept of behavioral safety. Systems need to be able to learn how to interact with non-automated vehicles and pedestrians, whose behavior is not necessarily predictable. Being able to anticipate the behavior of other road users, pedestrians, and other road hazards is crucial to deliver a genuinely autonomous driving experience.
SOTIF
To bridge the gaps where ISO 26262 falls short of the requirements for a more behavioral approach to safety, automotive safety experts have collaborated to create the ISO/PAS 21448 Safety of the intended functionality (SOTIF) standard. To facilitate safe and secure autonomous mobility, any automotive system needs to exhibit certain key characteristics. This includes their manufacture using automotive-grade components that offer a low rate of failure, maintaining a high level of reliability, and fail-safe.
Being able to detect the potential for failure according to the requirements of ISO 26262 ASIL D is also a priority. Furthermore, systems must always be available and be able to prioritize between safety and non-safety related tasks. In that context, the systems need to be fault-tolerant, too, so that they can continue operation even in the event of a failure. Finally, systems must be dependable, with the ability to predict a potential failure before it occurs.
In the lower levers of autonomy (Fig. 3), most systems are required to be fail-safe, meaning that the driver must be readily alert to take over should a system detect a fault occurring and safely stop operation. As we progress through to Level 2- and Level 3-based systems, the expectation is that should an error be detected, there’s enough capability in the system for it to continue to operate, albeit in a degraded state and that the driver has already been notified to be alert.
There’s a case for redundancy of systems in Level 4 and Level 5 systems, where the emphasis is on failing operationally—a state that alerts the driver—and that the vehicle can bring itself back to a safe condition promptly. This process may involve hand-off to the driver, as in the case of Level 0 to Level 3 systems.
In regard to handing off the control of the vehicle back to the driver, a fair amount of research has gone into the time it takes for the human to take back control. Notable research by Eriksson and Stanton found that the completion time for humans to grasp the situation and actively respond adequately can take anything from 2 to 26 seconds.
Bearing in mind that, at speed on a highway with the best-case reaction time, the vehicle could travel half the length of a football field. In the worst-case scenario, nearly six football field lengths would be covered. The likelihood of accidents occurring during either of these scenarios is exceptionally high. It’s for this reason that NXP firmly believes that the requirements of Level 2 and above should be that the vehicle fails operationally, and that at a minimum, the vehicle is brought to a safe stop (Fig. 4).
The concept that any safe autonomous vehicle is one that always follows the rules is a tricky one. As drivers, we know that societal norms apply in several situations while driving, and these often are contrary to the rules we might apply to systems. Under certain conditions, we have all crossed into the opposite oncoming lane of traffic to overtake a stopped or broken-down vehicle. These are deviations from the rules we all learn to deal with to prevent further accidents. From a systems perspective, ISO/PAS 21448 SOTIF is highly relevant to such driving scenarios.
Safety and security go hand-in-hand as the foundations for any autonomous system. NXP believes that together, ISO 26262 and ISO/PAS 21448 SOTIF will advance the design, test, and deployment of safe autonomous systems.
Ali Osman Ors is Director of AI Strategy and Strategic Partnerships, Automotive, and Brian Carlson, Director of Global Product and Solutions Marketing at NXP Semiconductors.