State of the Industry Report Series
Operational Safety for Increasingly Automated Vehicles
As the automotive industry continues to develop vehicles that feature greater levels of autonomy, building systems that meet functional safety standards is increasingly challenging. Advanced driver assistance systems (ADAS) are moving toward evolving into highly autonomous driving (HAD) systems. While ADAS systems are normally used with supervision, systems with higher levels of automation may not be.mTherefore, the requirements on both the technology and safety are different.
In order to gain insight into the current state-of-the-art in operational safety as well as to understand the respective challenges facing the automotive industry, Intrepid Delta conducted a meeting - Operational Safe Systems for Automated Driving – in Berlin from September 25-27, 2018. This event brought together a distinguished group of international experts from OEMs, major suppliers, as well as safety and security consultancies and academia. The results of a survey conducted in the leadup to the meeting, in cooperation with ARM, also contributed to this report.
From ISO 26262 to ISO PAS 21448
In its survey, Intrepid Delta posed the question, “How does your organization encompass the requirement for functional safety management and levels of independence?” Most of the responses made it clear that functional safety is handled or overseen by a person or team independent from the project group. Generally, safety seems to be considered throughout the development process.
The industry has now had several years to get used to working with the requirements of the current ISO 26262 standard. The current standard deals with hazards from malfunctions in E/E system. It defines requirements for functional safety management, verification and validation as well as ASIL classification and metrics for hardware faults. However, ISO 26262 does not address a system’s intended performance where a violation of safety requirements could occur even in a fault-free state. To address this shortcoming, the ISO PAS 21448 state of the intended function (SOTIF) is under development and should be published by the end of 2018 with the intention of becoming a full standard around 2022. It is designed to help address potential hazards of new, more automated features. The two standards are meant to complement one another.
Assessing the safety of a system’s intended function is particularly important with black box technologies and methods such as deep learning networks. These technologies helping to enable greater autonomy are potentially a conundrum for existing standards and analysis techniques. The ISO PAS 21448 will be important for guidance on safe design, verification and validation of Level 1 and Level 2 systems. According to Nicolas Becker, Functional Safety Senior Expert, PSA Group, and Chairman of the PAS 21448 working group, there is an intention to extend guidance to Level 3 and 4 systems.
Complying with the SOTIF was mentioned by a number of survey respondents when asked what they consider are the biggest challenges. This is likely to remain a challenge until companies have had the opportunity to perform SOTIF-related activities and determine how best to organize their compliance efforts. Also, unlike the ISO 26262, the end user may see the effects of the ISO PAS 21448, as manufacturers are likely to differ in their approach to intended behavior and risk.
There is no current clear definition for what constitutes ‘acceptable risk’ and different OEMs are likely to have different characterizations of what is deemed acceptable. Some of the newest players within the automotive industry have already taken a more liberal position with regard to how much risk they are willing to introduce to road users in contrast to more traditional companies. As more autonomous functions are integrated, each company will probably have their own approach to how it wants its own vehicle to behave and those characteristics will help to distinguish one brand or car model from another. Issues of liability become particularly important at automation level 3 as the driver also assumes the role of a passenger in certain situations. Clarifying who is liable must be answered as all parties involved in transportation, from the manufacturers, to regulators, to insurance companies, to the vehicle owners themselves have an interest.
One additional consideration is that the ISO PAS 21448 does not provide a grading system for hazardous events the way the ISO 26262 does using ASIL. Since triggering events can have different initiators, the risk reduction measures may also differ. Simone Fabris, Director – System Safety, at Mobileye, presented a system safety strategy for automated driving that uses a transparent set of rules to define asafety envelope in which the automated vehicle is allowed to operate and maneuver. Industry players could theoretically come together to decide on an acceptable definition for a safety envelope.
How safe does an autonomous system need to be?
There are different schools of thought on this question. Some experts believe that a system needs to be at least an order of magnitude safer than a Level 2 system with a driver. Others use the metric of aiming to be statistically 1000 times safer than a human driver. Regardless of the metric that is used, the public needs to feel confident in the safety of the system in order for it to achieve acceptance. Similar to defining a safety envelope, developing some common targets for safety through a consortium or working group may help.
In order to cover for both random and systemic failures, diverse redundancy is needed. The automotive industry does not have the luxury of utilizing triple redundancy for safety critical components where a 2 out of 3 (2oo3) concept is used with an external voter. Automotive manufacturers operate on much tighter margins and development budgets and do not have the luxury of utilizing that level of full redundancy in their systems. One interesting proposal to satisfy the need for redundancy without the high cost would be to use quasi-homogenous redundancy to implement fail-operational systems. This type of redundancy would utilize two separate ECUs but from the same supplier, reducing cost, allowing for reusability of the software stack. The downside would be the potential for a systemic fault occurring and creating a problem. This may be able to be mitigated by introducing so-called diversity points within the system.
Testing is also critically important for designing operational-safe systems. When asked, “What methods do you use to validate safety mechanisms?” nearly all survey respondents included “fault injection” in their responses. Other methods commonly noted were functional testing, analysis, and engineering judgment. While fault injection is still by far the most common method for testing, experts are starting to be critical of too great a reliance on it. In his presentation, Riccardo Vincelli of Renesas guided participants through specific considerations for semiconductor components with regard to the ISO 26262 and noted that a future editions of the ISO 26262 is likely to include guidelines on fault injection and failure rates for hardware.
OEMs ask semiconductor suppliers that develop ADAS system-on-chips (SoCs) and modules to certify that their technology complies with the ISO 26262 standard. The Intrepid Delta survey asked, “How easy is it to find a robust functional safety solution for automotive IP?” Nearly a third of those surveyed replied that it is not easy at all. This implies both a challenge and an opportunity for application tool developers.
Challenges of meeting both safety and security requirements
Safety and security are sometimes complementary of one another but can, in other cases, be at odds. In the past, security was often viewed as an afterthought in the development process. The security community recommends building security into development from the very beginning of the process as it may impact the system architecture. Such impacts can be costly or impossible to reconcile in late stages of development.
In the survey, one respondent noted that, “Security engineers are not expert about safety and safety engineers are not expert about security. But they are often not talking, ending up in conflicting solutions.” Given the greater level of connectivity of current and future vehicles, it is no longer an option to include security as an afterthought. For example, over-the-air updates pose security risks that were previously inconceivable in the context of a vehicle. Much like traditional software firms, automotive manufacturers may have to provide updates and incident response for their vehicles’ software as security risks are revealed beyond the dates of production. A joint ISO/SAE standard (21434) aimed at cyber engineering for road vehicles will address this and is due to be published in mid-2020.
Vehicles that rely on fewer mechanical connections must have dependable measures in place if a system fails (or is hacked or corrupted due to a security breach). The term fail-safe is being complemented by fail-operational. Developing fail-operational systems was also mentioned as a challenge for the industry in the survey and was the topic of several presentations at the meeting in Berlin. It is likely that case studies and best practices for building fail-operational systems will be a subject of focus for future automotive conferences.
Functional safety engineers and consultants continue to stress the need for building a robust safety argument explaining why a particular function or system is as safe as reasonably practical. As a best practice, John Birch, Chief Engineer Functional Safety, with HORIBA MIRA recommends that the safety argument should be framed to now include the SOTIF, functional safety, and cybersecurity requirements.
Intrepid Delta aspires to produce interactive, well researched, high profile and distinct conference formats that provide a memorable and educational experience for participants. High quality presentations by industry thought-leaders and distinguished speakers, interactive sessions designed to enable discussion, and comfortable opportunities to network, are at the core of the Intrepid Delta concept.