Functional Safety (FuSa) standards such as ISO 26262 have proved their immense importance to make the electronic components more reliable in today’s cars by delivering consistent performance and reducing critical system failures. However, with the rise of ADAS features, the autonomous driving capabilities in vehicles come with an even higher engineering challenge regarding safety and reliability. Sensors, and other components that are working as a designed part, are falling short of capabilities when running in real-time scenarios resulting in dangerous conditions. To address these types of challenges, a new standard safety of the Intended Functionality (SOTIF), ISO 21448 safety standard, will be soon introduced to identify shortfalls in the performance that can occur even when the system is in failure-free condition. It raises the expectation of every component works as designed, and the design is adequate to work to fulfill its goal with the required performance. On the other side, the new SOTIF standard requires a full range of safety analysis & engineering simulation solutions to enable autonomous vehicle development teams to build flawless performance into their designs right from the early stages of product development. The development team can validate the performance before the vehicle launch in the market.
- What is ISO 21448: Road Vehicles – SOTIF?
SOTIF is abbreviated Safety of The Intended Functionality and, in short for ISO/ PAS 21448, applies to functionalities that need a proper awareness of the situation to be safe. This standard concerns how to ensure the safety of the functionality even in the absence of a fault/failure. This is quite in contrast with the traditional Functional Safety (FuSa), which is majorly concerned with the risk associated with system failure.
- How is ISO 21448 related to ISO 26262?
ISO 26262 covers the functional safety of the system in the event of failures and has no coverage of safety hazards that result in the absence of system failures. That is the reason ISO 21448 is
mandatory in analyzing the situations where ensuring safety without system failure is so complex and complicated.
- Why is SOTIF (Safety of the Intended Functionality) important?
In today’s world, vehicle electronics provides features like comfort, communication, and navigation assistance, mission-critical functionality such as steering and braking & more. The global automotive standard helps engineering teams to uncover and address FuSa hazards such as software bugs and hardware failures. Safety stakes have grown even higher, and if a crucial component, let’s say the sensor is not fulfilling its needed functionality or it fails to deliver the performance needed to handle a situation – for example, failing to recognize a pedestrian in the road ahead; the application of ISO 21448 helps us to ensure that the perception algorithm systems (a combination of sensors and software algorithms) will recognize pedestrians in all situations that are part of the Operational Design Domain (ODD). This enables the systems to trigger a safe response in consideration of performance under various ODDs. SOTIF ensures robust design against any disturbances and hazards due to flawed Human-Machine Interactions.
Fig: Limited contrast resolution images in the presence of blinding sun
2. A Model-Based Workflow Integrating FuSa and SOTIF:
To successfully conduct autonomous vehicle development in compliance with both ISO 21448 and ISO 26262 there is a unique model that combines a linear process, V-shaped progression with feedback loops of evaluation and improvement to incorporate the learning and as well as comply with the standard. This model-integrated safety workbench offers all required analysis options for
Functional Safety (FuSa), Safety of The Intended Functionality (SOTIF).
The following is a step-by-step look at the workflow:
- Features of the Automated Driving (AD) functionality and the Operational Design Domain (ODD) are defined. From the above-portrayed functionalities, the requirements are derived or transferred from the Original Equipment Manufacturer (OEM) to the supplier. The initial architecture developed on a functional level, and this will begin the integrated FuSa and SOTIF process.
- Performing the hazard analysis and investigating the causes of potential hazards strengthens the feedback loop to identify the issues during the analysis stage and rectifies them straight from the initial level to the architecture level. Ultimately, this will enhance the requirements and architecture.
- Engineers execute the refinement and technical concretization of hardware, software, and sensor requirements and solutions, again handled in a model-based way, with a corresponding feedback loop.
- Performing model-based control software generation will help the engineer to generate safety compliant code, Automotive Safety Integrity Level (ASIL). Moreover, level D. Camera and radar sensor technologies and perception algorithms are validated, sent for evaluation, and improved in a cyclical process until an acceptable performance level for all foreseeable situations has reached.
- The integrated AD functionality is validated under realistic road conditions to prove that its behavior is appropriate in every situation. This step includes closed-loop simulation, supported by optimized scenario variation and parameter assignment, as well as automatic identification of “edge cases.” All insights are imported back into the safety tool, closing the validation loop.
- Hardware, software, and the Electronic Control Unit (ECU) that support AD functionality undergo thorough integration testing on Hardware-In-Loop (HIL) benches.
- All the insights will get mentioned in a convincing safety case that includes a graphical view of requirements refinement and traceability of all artifacts in the model-based process to demonstrate safety.
To maximize efficiency and financial returns, hardware, software, models, requirements, test cases, and other artifacts are available for re-use in future development efforts, typically with extended ODDs or extended functional capabilities.
3. Medini Analyze as a Single Source for meeting SOTIF and FuSa Standards:
ANSYS medini analyze is a software tool, which has been recognized by a different industrial standard for analyzing varied aspects of functional safety, technical safety, and compliance with the standards. Performing SOTIF analysis individually, as a stand-alone activity, will empower the product operational safety analysis and make use of architecture models, vehicle-level malfunctioning behavior analysis, and hazardous event assessments. This can eliminate redundancies and ensure consistency among all the results.
ANSYS medini analyze has enhanced the model-integrated safety approach with new modeling elements for limitations, weaknesses, and triggering conditions, as specified in ISO 21448.
The integrated FuSa and SOTIF workflow start with an initial hazard analysis and an investigation for potential hazards – caused by failures or limitations of the nominal performance – across the system architecture. For example, fog, snow, rain, and other weather conditions can confuse the sensor’s perception capabilities into “viewing” a physical object where there is none. It can trigger risky behavior such as strong braking, which results in a rear collision with another vehicle. Even more disastrous, a sensor might interpret an actual physical object on the road as an illusion, which results in the crash of a vehicle with the physical object. Medini analyse focus at every identified hazard and utilizes key parameters like “incident severity” to classify the risk level. Additionally, it distinguishes critical safety hazards and addresses them accordingly.
ANSYS medini analyze can also address causal analysis, looking at the example, “Why is this critical performance flaw occurring?” This analysis is similar to the functional safety analysis that automotive engineering teams have been conducting for a decade and includes well-known techniques from functional safety analysis, such as fault trees and guideword analysis.
Fig: Effects of the SOTIF-caused malfunctions are added by the safety analyst in medini analyze.
ANSYS medini analyze also allows traceability linkage between safety analysis and complete system architecture. It automates the allocation of the malfunctioning behavior to a specific functional block or multiple blocks. Whatever the cause, whether it is performance shortfall or a software bug, or a sensor performance limitation – medini analyze defines the areas where sensors functionality is not delivered. Because medini analyse model limitations and triggering conditions can be used in causal nets or fault tree analysis. Over this period, engineers can accumulate knowledge and lessons learned. Integrating all these findings with the previous validation activities, simulations, or virtual road tests could trigger conditions that may express in one or two words, like “sun glare” or “snow.” Others are much more complex, such as “metal object on the pavement causing a reflection from the headlights in night-time conditions” or “driving out of a tunnel at high speed.” These more complex triggering conditions can be modeled by medini analyze as scenarios. These scenarios are modeled in medini using SysML diagrams, where scenes and events are represented through pictograms.
Triggering conditions and scenarios will also be exported from medini analyze into different formats, and then it can be imported into scenario generators for simulation. Scenarios that have been identified as potential triggers for risky behavior provide valuable inputs to product developers, simulation experts, and physical testing team members. It will enable them to investigate and address every causal effect and provides the outcomes to safety analysts, and determine parameters (e.g., critical position, speed, and distance, weather conditions).
The new SOTIF standard will also cover Human-Machine Interaction (HMI) and hazards arising from misunderstandings and even intentional misuse of the HMIs. Medini analyze can also address these concerns, general cybersecurity issues that fall outside the scope of ISO 21448 but may still be important in the horizon of autonomous vehicle development.
The work of safety engineers from the past has been very much isolated and non-collaborative and used manual analysis and reporting techniques to communicate the findings in a significant amount of time with cost under consideration. But the race to commercialize Autonomous Vehicle designs and standards to regularize those where increasing, the delays and inefficiencies are no longer acceptable. Unifying the development and verification and a shared platform to introduce the upcoming SOTIF standard can guarantee the functionality of every component to the real-time driving challenges. It enables all functions involved in Autonomous vehicle development to share data and work to collaborate. From Electrical Engineers designing Perception Modules to Software Engineers developing Critical Software to safety, experts should come together to deliver complete FuSa and SOTIF compliance in the ANSYS Medini analyze.