/Note/ The content of this article is based on the oral statements of automotive functional safety industry engineers and reference industry materials, representing personal views. If you have better suggestions or supplements, please leave a message for interaction!
This article mainly discusses the following issues, and personal views are for learning reference only. Interested parties can share and communicate in the comment area.
ISO 26262, as a functional safety standard, specifies abstract and general requirements. This means that software development teams cannot apply it directly but need to carefully assess the relevance of each requirement to specific projects. For example, in automotive autonomous driving software projects, the risk assessment section related to system failures in the standard requires software development teams to consider specific scenarios of autonomous driving, such as the control authority and potential risks of vehicles under different levels of autonomous driving functions (L1 – L5), to determine how to apply the risk assessment requirements in the standard to the project. For model-based software development, it is necessary to consider whether the failures of various modules in the model (such as perception module, decision module, execution module) meet the safety requirements of the standard.
Since ISO 26262 covers both code-based software development and model-based software development, and also includes requirements that apply only to one of the solutions, the software development team must conduct a comprehensive assessment.
For example, in the software verification phase, code-based software development may focus more on static analysis of the code and unit testing, while model-based software development emphasizes model verification and consistency checks after code generation from the model. The team needs to determine the applicable standard requirements based on the actual development method used (whether primarily model-based, code-based, or a combination of both) and carry out corresponding development activities. For instance, in a car electronic stability program (ESP) software project that uses both code development and model development, for the model-based development part (such as vehicle dynamics model), syntax and semantic verification of the model must be conducted according to the standard requirements; for the code-based development part (such as low-level drivers), code standard checks and unit testing must be performed.
Additionally, taking automotive engine control software as an example, if primarily code-based development is adopted, it is essential to focus on the safety of the code structure, such as preventing memory leaks, buffer overflows, and other issues; if model-based development is utilized, such as using tools like Simulink to build engine control models, more attention needs to be paid to the accuracy and verifiability of the model, including whether the model accurately reflects the physical characteristics of the engine, whether the control logic is correct, etc. When combining both solutions, it is also necessary to consider how to ensure consistency between the code and the model and how to coordinate safety requirements under both development methods.
Problems Encountered in Projects?
When applying the ISO 26262 standard, the interpretation, assessment, and implementation of requirements depend on the latest methodological knowledge, market-available tools, and specific project circumstances. For example, the emergence of new automotive software architectures (such as service-oriented architecture SOA) requires teams to understand the latest implementation methods for functional safety under this architecture to accurately interpret and apply the standard. Additionally, the updating and replacement of tools in the market can also affect the implementation of the standard. If the team uses new model development tools, it needs to understand whether the tool meets the requirements of the ISO 26262 standard and how to utilize the tool to satisfy the standard requirements. Specific project circumstances such as project time constraints, budget, and functional safety target levels (ASIL levels, etc.) can also affect the application of the standard. For instance, for an ASIL D grade automotive brake system software project, stricter adherence to the standard requirements for development and verification may be needed, potentially requiring more advanced tools and additional resources.
The uncertainties in the advantages and disadvantages of various software development methods and corresponding tools make it challenging to utilize project budgets effectively. For example, some advanced model-based development tools may have powerful features, such as automatic code generation and model verification, but are expensive. Furthermore, different tools have their strengths and weaknesses in terms of functional coverage, ease of use, and support for ISO 26262 standards. The software development team needs to weigh the cost of the tool against the benefits it can bring to the project (such as improved development efficiency, enhanced functional safety assurance). Choosing an unsuitable tool for the project may lead to budget overruns or failure to meet functional safety standard requirements. For example, in an automotive embedded software project, to meet the ISO 26262 standard’s model verification requirements, a powerful but costly model verification tool with a high learning curve was purchased, yet team members were unable to fully utilize its advantages due to unfamiliarity with the tool, resulting in budget waste and project delays.
During the software development process, it is essential to clarify the roles and responsibilities of different personnel, as well as the interfaces between different teams and departments. In model-based software development, multiple roles are involved, such as model designers, software engineers, and testing engineers. For instance, model designers are responsible for constructing accurate software function models, software engineers convert models into high-quality code, and testing engineers validate and test the models and code. If roles and responsibilities are not clearly defined, there may be overlaps or omissions in work. At the same time, the definition of interfaces between different teams (such as software development teams, hardware development teams, system integration teams) and departments is also crucial. For example, the software team and hardware team need to clarify the software’s interface requirements with hardware (such as hardware register access, interrupt handling, etc.) and the division of responsibilities in joint testing (such as hardware-in-the-loop testing).
1. In the development of automotive embedded software standards, the first step is to refine safety goals based on the ISO 26262 standard. For example, for automotive brake system software, the ISO 26262 standard requires ensuring the safety of the braking function. This abstract goal can be refined to “ensure that the brake system can safely decelerate the vehicle to a stop in the event of any single hardware failure (such as sensor failure, actuator failure) and software failure (such as control algorithm errors, communication failures).” Then, these refined safety goals are mapped to software requirements, clarifying the functions the software should possess in different fault scenarios, such as fault detection, fault isolation, and safe state transitions.
Integrating the functional safety requirements from ISO 26262 with the general functional requirements in automotive embedded software standards. For instance, in automotive adaptive cruise control (ACC) software, general functional requirements include automatically adjusting vehicle speed based on set speed and distance to the vehicle in front, while functional safety requirements include safely exiting ACC mode and alerting the driver in case of sensor failure. In the requirements document, these two types of requirements need to be integrated, clarifying the priority and interrelationship of each requirement to ensure that the software meets basic functionality while ensuring functional safety.
2. In software architecture design, it is crucial to build an architecture that ensures functional safety according to ISO 26262 standards. For example, adopting redundant designs; for the critical sensor signal processing module of automotive electronic stability program (ESP) software, dual sensor inputs can be designed, and reliability can be improved through comparison and arbitration mechanisms. At the same time, fault isolation between software modules must be considered to prevent faults from propagating between modules. For instance, isolating the safety-critical brake control module from the non-critical information display module through reasonable interface design and access control ensures that the brake control module is not affected by faults in the information display module.
Utilizing model-based design methods (such as using tools like Simulink) to meet the safety requirements in ISO 26262 standards. During the design process, establish functional models and fault models of the system, and verify the effectiveness of safety mechanisms through model simulation. For example, for automotive power system control software, establish an engine control model, including models for normal operating conditions and various fault conditions (such as clogged fuel injectors, spark plug failures). By simulating these faults in the model, verify whether the fault diagnosis and handling mechanisms in the software can correctly guide the system to a safe state.
3. During the code development process, follow the requirements of ISO 26262 standards and automotive embedded software standards. Adopt safe coding standards, such as avoiding code structures that may lead to memory leaks, buffer overflows, and other security risks. For safety-critical code segments, detailed comments and documentation should be provided for subsequent maintenance and review. Additionally, when using code generation tools to generate code from validated models, ensure that the code generation process meets functional safety requirements, such as consistency between code and model, and traceability of the code.
Select development toolchains that comply with ISO 26262 standards. These tools include compilers, debuggers, and code generation tools. For example, choose compilers that have been functionally safety certified, which can provide code optimization while ensuring the safety of the code. When using the toolchain, follow the functional safety manual provided by the tool vendor for configuration and operation, ensuring that the tools meet functional safety requirements at every stage of the development process.
In the Bosch ESP project, the ESP software is crucial for vehicle driving safety. Bosch must strictly adhere to automotive embedded software standards and ISO 26262 standards when developing ESP software. Since the ESP system needs to monitor and control the vehicle’s dynamic stability in real-time, Bosch refines the safety requirements in ISO 26262 to specific software modules. For example, for the wheel speed sensor signal processing module, the safety goal is “to ensure the accurate acquisition and processing of wheel speed signals, and to timely detect and take measures in case of signal anomalies (such as interference, loss, or errors) to prevent the vehicle from losing control due to incorrect wheel speed information.”
Bosch mainly adopts a model-based development approach to construct the control logic of ESP software. By establishing vehicle dynamics models, they simulate the vehicle’s motion under different driving conditions (such as straight driving, turning, braking, acceleration), thereby designing software algorithms that can accurately control vehicle stability. During model development, they use specialized model development tools, such as Matlab/Simulink, and customize these tools to meet ISO 26262 standards. For example, in the model verification phase, they utilize the functions provided by the tools to conduct comprehensive verification of the model, including syntax checks, semantic checks, boundary value testing, etc., ensuring the accuracy and safety of the model. Moreover, after generating code from the model, strict code reviews and testing are conducted to ensure consistency between the code and the model.
This integrated development approach allows Bosch’s ESP software to be widely used globally and plays a key role in enhancing vehicle driving safety. The ESP software can accurately control the braking and driving force of each wheel based on the vehicle’s real-time status and the driver’s intentions, effectively preventing dangerous situations such as skidding and tailspin. By strictly adhering to standard development methods and ISO 26262 standards, Bosch’s ESP software is fully guaranteed in terms of reliability and functional safety.
1. Incorrectly applying the safety goals in ISO 26262 standards in a simple and vague manner without refining them in conjunction with the specific functions of automotive embedded software. For example, for automotive autonomous driving systems, merely setting the broad safety goal of “ensuring safe driving” without specifying safety goals in specific scenarios, such as “being able to safely hand over control to the driver in case of sensor failure” or “the vehicle can automatically decelerate and pull over in case of software algorithm anomalies.” Such vague goal setting can lead to a lack of targeted safety measures in the subsequent development process, failing to effectively ensure the functional safety of the system.
2. When designing software architecture, not fully considering the requirements of functional safety. For instance, not adopting appropriate redundancy designs, relying solely on a single sensor to obtain brake pressure information in automotive brake system software, and lacking backup measures to ensure the safe operation of the brake system in case of sensor failure. Or not reasonably dividing the safety levels of software modules, leading to a lack of effective isolation between safety-critical modules and non-critical modules, which may allow faults in non-critical modules to propagate to critical modules, affecting the overall system’s safety.
3. In model-based design, the model construction is inaccurate or not updated in a timely manner to reflect changes in the actual system. For instance, in the automotive power system control model, certain physical characteristics of the engine (such as the response time of the fuel injector in the fuel injection model) are not modeled correctly, resulting in the code generated from the model being unable to accurately control the engine’s operation in actual applications. Or after hardware upgrades, the software model is not modified accordingly, causing the results of model verification to fail to reflect the performance and safety of the software in the actual hardware environment.
4. When using code generation tools to generate code from models, the tools are not correctly configured, or the generated code is not sufficiently checked. For instance, failing to ensure the compatibility of the code generation tool version with the model may lead to syntax errors or non-compliance with safety requirements in the generated code. Or neglecting to optimize and review the generated code, overlooking possible semantic differences between the code and the model, which could negatively impact the software’s functionality and safety.
5. Test cases do not cover all functional and safety requirements. For example, in the testing of automotive electronic stability program (ESP) software, only focusing on vehicle stability control testing under normal driving conditions while neglecting functional testing of the ESP system under extreme road conditions (such as slippery roads, rugged mountain roads) or hardware failures (such as sensor failures, actuator failures). This lack of comprehensive testing may cause safety vulnerabilities in the software to go undetected, increasing the risk of safety incidents during actual operation of the vehicle.
