Ensuring safety is very important for self-driving cars. Autonomous driving safety can be viewed from two perspectives: Functional Safety (FuSa) and Safety of Intended Function (SOTIF). FuSa ensures that the system has an acceptable risk in the event of failure of electrical and electronic components, while SOTIF ensures that the system has an acceptable risk in the event of insufficient functionality and performance limitations.
ISO 26262 and ISO 21448 are advanced international standards for ensuring FuSa and SOTIF compliance for autonomous vehicle systems, respectively. The ISO 21448 standard mentions the need to align ISO 26262 development activities with ISO 21448 development activities and describes the mapping relationship at a very high level. However, given the iterative nature of the SOTIF development activities in ISO 21448, there is not a direct one-to-one mapping of the workflow between the two standards. Therefore, we need a clear understanding of how to align ISO 26262 and ISO 21448 development activities and how analysis performed in one standard affects the other.
To achieve this goal, we propose in this paper a detailed workflow between the ISO 26262 and ISO 21448 standards. We discussed how to determine whether a design change due to a SOTIF change would affect the FuSa analysis and vice versa. We also discussed security process considerations for agile development.
introduce
Safety is one of the important aspects we need to consider when developing automotive systems. As many companies move to autonomous driving, the complexity of the systems has been increasing, adding to the complexity of safety and security. Safety standards such as ISO 26262, ISO 21448, and ANSI/UL 4600 provide guidance on how engineers and analysts can ensure the safety of automotive systems.
ISO 26262 is a functional safety standard that provides guidance on how to demonstrate that electrical and electronic components of a system do not present unacceptable risks. ISO 21448, the Safety of Intended Functions (SOTIF) standard, provides guidance on how to ensure that systems do not present unreasonable risks due to insufficient functionality and performance limitations of components in the system. SOTIF standards are designed to reduce known and unknown risks. Unlike the ISO 26262 and ISO 21448 standards, UL 4600 is a standard that provides guidance on building a safety profile for unmanned systems. All three standards can help improve the safety of self-driving cars.
Although UL 4600 is a stand-alone standard, clause 4.4 of ISO 21448 mentions the need to align its development activities with those of ISO 26262. While ISO 21448 Annex A.2.3 provides top-level information on the alignment of ISO 21448 and ISO 26262 development activities, we do not have sufficient information on how these development activities interact. Furthermore, ISO 26262 limits its analysis to electrical and electronic components relevant to safety systems. However, ISO 21448 applies to the entire autonomous vehicle as well as any human-machine interface. Therefore, it is necessary to understand what is the preferred workflow for activities at the system, hardware and software level, and how to develop a systematic process that not only ensures safety from the perspective of ISO 26262 and ISO 21448, but also helps to identify unknown risks.
To address this limitation, we detail in this paper a workflow for aligning development activities between ISO 26262 and ISO 21448. We also discuss the reasoning behind the processes considered in workflow and give an illustrative example to show the workflow. We believe our workflow will help create better processes in organizations and facilitate better communication between teams working together.
Background and related work
ISO 26262
ISO 26262 is the functional safety standard for road vehicles. Functional safety refers to the absence of unreasonable risks due to failure of electrical and electronic systems. ISO 26262 follows the V model of system level development, hardware development and software development. The process model followed by ISO 26262 and the part numbers associated with each phase are shown in Figure 1.
We start with the concept phase (ISO 26262 part 3), where we define the relevant items to be analyzed for functional safety. Create a functional block diagram and identify the functionality associated with each block. Once dependencies are defined, we will identify failures of modules within the project boundary. Based on these failures, we identify the corresponding hazards and perform a Hazard Analysis and Risk Assessment (HARA). During HARA, we assign severity (S), controllability (C) and exposure (E) ratings to each fault and determine the corresponding Automotive Safety Integrity Level (ASIL). The highest level determined is the ASIL level assigned to the entire system. We also defined safety goals corresponding to each hazard during HARA. After HARA is complete, we will create functional safety requirements and aggregate all findings into a Functional Safety Concept (FSC).
After the FSC is generated, we move to the next phase: system specification and design (Part 4 of ISO 26262). In this phase, we define the system specification, architecture, technical safety requirements, hardware-software interface requirements and summarize findings into a technical safety concept (TSC). After defining the TSC, we started to develop it at the hardware level (Part 5 of ISO 26262). In this phase, we create hardware (HW) safety specifications and HW design, analyze and evaluate HW architectural metrics, calculate random hardware failure rates, and perform HW integration and testing.
Figure 1 - Workflow for ISO 26262 (Functional Safety)
Our software phase (part 6 of ISO 26262) is developed in parallel with the hardware development phase. In this phase, we first define the software (SW) security specification, SW architecture and design. We then implement the software and perform unit, integration and requirements-based testing.
After development at the hardware and software level, we move into the system testing and safety verification phase (Part 4 of ISO 26262), during which we develop plans for integration testing of hardware, software, systems and vehicles, as well as safety verification. After testing, we move into the production, operations, service and retirement phase (ISO 26262 part 7), during which we execute production and maintenance plans, create repair instructions and prepare user manuals. While following the ISO 26262 process model, we may use other supporting processes detailed in ISO 26262 Part 8, such as tool qualification and configuration management.
ISO 21448
Unlike ISO 26262, ISO 21448 does not address failures of electrical and electronic components in vehicles, nor is it limited to safety-critical systems. ISO 21448 is a safety standard for intended functions, mainly applicable to unmanned systems. It deals with security issues that arise from insufficient functionality, performance limitations, and foreseeable misuse.
The process suggested by ISO 21448 is shown in Figure 2. The diagram shows each stage in the process and its corresponding clause number in the standard. As shown, we start by gathering the specification and design of the unmanned system (clause 5 of ISO 21448). Based on the functions defined in the specification, we perform Hazard Identification and Risk Evaluation (HIRE) (Article 6) by identifying potentially hazardous actions.
During HIRE, we evaluate the controllability (C) and severity (S) of each harmful action, and if C=0 or S=0, we define them as reasonable and acceptable risks. If both C and S are greater than zero, the risk is considered unacceptable.
Also during the HIRE phase, we can begin to develop acceptance criteria specifications for hazards with unacceptable risk. To define acceptance criteria, we need to have a rationale such as GAMAB (global at least as good, from French "globalement au moins aussi bon"), ALARP (as low as reasonably practicable) and MEM (minimum endogenous mortality), and data sources containing accident or fatality information. Using this information, we propose an acceptance criterion to ensure that the number of potential accidents that could result is less than a human driver, or less than or similar to previous versions of the vehicle.
After HIRE is complete, we will perform an analysis of triggering events and lack of functionality (clause 7). At this stage, we identify sensor limitations, algorithm limitations, actuator limitations and possible misuse cases. Then we analyze the trigger conditions with unacceptable risk, such as high residual risk and the corresponding acceptance criteria may not be met. For triggering conditions with unacceptable risks, we define SOTIF-related functional modifications (Article 8). If the trigger condition does have C = 0 or S = 0, the acceptance criteria can be reached, then we can consider it a tolerable risk and proceed to the definition of the verification and validation strategy (clause 9).
Figure 2 - ISO 21448 (SOTIF) workflow
After defining the verification and validation strategy, we perform an evaluation of known scenarios (clause 10), during which we perform sensor verification, algorithm verification, actuator verification, and vehicle verification. Once we have completed the evaluation of known scenes, we move to the evaluation of unknown scenes (Item 11). We conduct safety validation in the real world and ensure that residual risk is at an acceptable level.
After completing the evaluation of the unknown scenario, we turn to the SOTIF release (clause 12), where we determine whether the system has been rigorously and sufficiently analyzed to ensure that SOTIF is acceptable. If not, a SOTIF function modification needs to be performed. If the evaluators find SOTIF acceptable, then we can proceed to production and operations. During the operational phase (clause 13), mechanisms such as runtime monitoring are still required to identify any new events or conditions that may cause problems with SOTIF.
related work
We propose a complete general workflow covering system, hardware and software development.
Workflow between ISO 26262 and ISO 21448
Figure 3 illustrates the detailed workflow between our proposed ISO 26262 and ISO 21448. Rectangles represent ISO 26262 activities and their relevant parts. Rounded rectangles indicate SOTIF activities and their corresponding clause numbers. A single directional arrow indicates a one-way association—meaning it is the intended sequence flow of activities. A double-headed arrow indicates a bidirectional association, which means that based on an update to one of the activities, the other activity may need to be performed again or the corresponding work product needs to be modified. The bidirectional dotted arrows indicate bidirectional influences between ISO 26262 activities and ISO 21448 activities. Bidirectional influence means that information found in one standard may affect activities or work products in another standard.
As shown in Figure 3, ISO 26262 starts with item definition, while ISO 21448 starts with specification and design. Note that it may not be possible to have a complete specification and design at first. Therefore, SOTIF is a highly iterative process. From the specification and design, we can generate a high-level functional architecture (similar to FuSa's functional block diagram, but for unmanned systems). The terms used in ISO 26262 do not need to exactly match the unmanned systems we analyze in ISO 21448.
Between FuSa systems and unmanned systems, we can consider three different types of architectures, as shown in Figure 4. For type 1 architecture, we have a separate protected system and unmanned system. For example, if we consider equipping vehicles with remote monitors to ensure system security. Then we consider the functional safety of the system in relation to remote operators and controls, while for SOTIF we consider unmanned as well as human-machine interaction. In these architectures, SOTIF and functional safety aspects do not interact as much and it is easier to perform change impact analysis.
The second architecture we consider is the Type 2 architecture, where functional safety systems are a subset of unmanned systems. An example is where the emergency braking system is considered a FuSa system, but the vehicle has additional perception algorithms which are not included in the FuSa system. In these systems, we need to map any updates related to FuSa components and their interfaces to SOTIF and vice versa. It helps to make the design better and consider both FuSa and SOTIF when we need to provide functional modification in SOTIF.
Figure 3 - Workflow between ISO 26262 and ISO 21448
Figure 4 - Possible architectural types
The third architecture, called Type 3 in the figure, requires the same architecture that complies with both FuSa and SOTIF. An example is a vehicle using an end-to-end machine learning (ML) model, i.e. an ML model that takes sensor data as input and produces wheel motor speeds as output.
Following the definition of related items in ISO 26262, we perform HARA. For ISO 21448 we implement HIRE. Note that during HARA, issues related to SOTIF may be discovered, and also during HIRE, we may find failures. Therefore, we need to keep track of them and update the analysis accordingly.
After HARA, in ISO 26262, we created a Functional Safety Concept (FSC), which contains functional safety requirements, safety goals, ASIL information, and any findings from HARA. We do not have an FSC equivalent in ISO 21448. After creating the FSC in ISO 26262, we enter the system development phase, during which we first create the system specification and design. While there is no equivalent phase to ISO 21448, the architecture (and FuSa system architecture, if it is part of an unmanned system) can be updated in the specification and design.
After the system architecture and design phase in ISO 26262, we complete the technical safety concept (TSC), which contains the technical safety requirements, hardware-software interface specification, and any other observations made as part of the system safety analysis. The equivalent of the TSC phase to the activities in ISO 21448 is the analysis of system-level functional deficiencies and triggering conditions. At this stage, similar to how we predict functional safety issues based on the hardware and software details in ISO 26262, we identify potential deficiencies and their causes based on the list of sensors, algorithms and actuators. However, these deficiencies could not be conclusively determined because we do not know exactly what the component deficiencies are, and the trigger conditions that lead to them. A bottom-up analysis is necessary to understand whether the underlying deficiencies we hypothesize actually occur at the system level.
After developing the TSC in ISO 26262, we move to the hardware (HW) security analysis phase. Note that although we specify a hardware security analysis phase, hardware and software development can begin in parallel after the TSC is complete. In the hardware analysis phase, we generate hardware specifications, design, evaluate hardware architectural metrics and perform FMEDA. For ISO 21448, the equivalent analysis we perform is to analyze functional deficiencies and trigger conditions specific to HW components. At this stage, we estimate sensor limits, actuator limits, and ECU, or any other conditions where hardware performance may be affected.
Figure 5 - Type 2 architecture including attitude, localization, prediction, planning and control functions
Following the hardware safety analysis to ISO 26262, we conduct a hardware safety verification, during which we integrate the hardware and test it. The equivalent in ISO 21448 is to validate hardware components against scenarios that can occur in the operational design domain (ODD). By doing this, we can verify that the system is operating safely as expected in the presence of triggering conditions.
Following hardware (HW) safety verification in ISO 26262 is software safety (SW) analysis, where we define the software specification, design and execute a software FMEA to identify issues at the software level. The equivalent in ISO 21448 is the analysis of software functional deficiencies and triggering conditions. At this stage, we identify algorithmic limitations. Note that for machine learning (ML) algorithms, we need to analyze not only the ML models, but also the ML libraries that support these models.
Following the software safety analysis in ISO 26262, we perform software verification through unit testing, integration testing and requirements-based testing. The equivalent step in ISO 21448 is to validate software against scenarios in ODD. During this analysis, we may be able to discover new triggers for the algorithm. Bottom-up analysis is performed to update system-level deficiencies and vehicle-level hazards if updating hardware or software triggers. Note that during analysis or validation we may discover new FuSa or SOTIF issues and need to map across standards accordingly. If we propose modifications to address SOTIF issues, we should also consider whether the newly added changes will lead to any new functional safety issues.
After software validation in ISO 26262, we do integration and testing, and then full vehicle level testing. The corresponding equivalents in ISO 21448 are scenario-based integration verification and vehicle verification. During this campaign, if we discover any new issues, we map them to trigger conditions and under-featured system-level analysis. Additionally, the test plan is updated if we are able to identify any new triggers for system-level events based on hardware and software-level verification. Note that risk acceptance for vehicle-level validation is done according to our acceptance criteria and corresponding validation goals.
Table 1 - Workflow Description for Type 2 Architecture
After ISO 26262 vehicle-level testing, we conduct safety confirmation. The equivalent of this activity in ISO 21448 is the assessment of unknown scenarios where we deploy the vehicle onto the road and calculate the residual risk. Any new issues discovered in the unknown are used to perform SOTIF functional modifications and update the specification and design as needed.
After ISO 26262 safety validation, we move into production, operation, decommissioning and service, during which we develop production and maintenance plans, upgrade and repair procedures, and develop user manuals. An equivalent in ISO 26262 is the operational phase, during which we monitor vehicles deployed in the real world to see if potentially unknown triggering conditions may arise. If a new trigger condition is identified, we add it to the existing list and repeat the SOTIF process.
case analysis
To provide clear guidance on the proposed detailed workflow shown in Figure 3 and the different types of architectures shown in Figure 4, consider the following Type 2 architecture shown in Figure 5 for the implementation of drive, brake and steering actuators automatic control.
An example workflow is provided in Table 1. The first column in the table refers to the part number of ISO 26262 and the clause number of ISO 21448, which we consider to be consistent. The symbol PX means part number X and the symbol CY means item number Y.
Conclusions and future work
In this paper, we propose a detailed workflow between ISO 26262 and ISO 21448, showing which stages need to be harmonized. We also discuss the need to ensure that design changes that address SOTIF problems do not lead to new FuSa problems, and vice versa. We discussed the workflow through an example architecture with automated control of drive, brake, and steering actuators. Although we discussed the alignment of phases, we did not discuss how to consider quality management and change management when aligning the two standards. We intend to include such analyzes as part of our future work.