Functional Safety
Automotive Functional Safety Requirements Mapping
The automotive industry is one where system failures are not tolerated. Any failure can lead to significant risks of lawsuits, compensation claims, and reputational damage for automakers. To prevent system failures, a rigorous and reliable development process is necessary for system developers to follow. Traditionally, the automotive industry has relied on Failure Mode and Effects Analysis (FMEA) for failure analysis and prevention. In addition to FMEA, there has been a growing trend of applying the ISO 26262 functional safety design standard to failure analysis and prevention. ISO 26262 can complement FMEA by addressing shortcomings in software analysis.
ISO 26262 Requirements
ISO 26262 is a rigorous verification system for functional safety analysis and is the mainstream method for system functional safety design analysis in the automotive industry. Globally, OEMs, Tier 1 suppliers, automotive chip manufacturers, and tool developers have started integrating ISO 26262 into their product development processes or ensuring that their software and hardware development tools comply with ISO 26262 requirements to establish a functional safety process. ISO 26262 enables companies to clearly define project initiation processes and the objectives that system, hardware, and software development related to functional safety must follow. This aids in joining large-scale international automotive system development projects and provides clear definitions for the safety thresholds required by systems.
Automotive Safety Integrity Levels (ASIL)
The goal of ISO 26262 is to enhance the functional safety of automotive E/E systems by preventing hazards caused by system failures. ISO 26262 uses Automotive Safety Integrity Levels (ASIL) to determine the functional safety level of a system. ASIL is divided into four levels: A (lowest), B, C, and D (highest). Higher ASIL levels indicate stricter functional safety evaluations, representing higher reliability in the system's ability to execute safety functions correctly or avoid errors in those functions.
V-Model Testing Cycle:
The structure of the ISO 26262 standard consists of ten guidelines and informational documents. Among these, ISO 26262-4/5/6 describes system-level, hardware-level, and software-level product development, defining the processes and corresponding work products for each development stage using a nested V-Model.
The team integrates ISO 26262 requirements during the software-level product development stage. By incorporating the ISO 26262 software testing lifecycle into the software development process, including executing software testing tasks and process control, the team ensures the quality of ECU software and meets the safety requirements of the corresponding ISO 26262 software functional safety level.
Project Definition Phase
Requirement Analysis:
This phase involves analyzing user needs and compiling system requirements. Typically, this phase includes discussions with users to create a User Requirements Document (URD) that outlines the system's functionalities, interfaces, performance, data, and security. It lists the user's expected needs.
System Design:
This phase outlines the technologies and feasibility needed to meet user requirements. Any infeasible requirements are reported back to the users, and the final resolution of these requirements is included in the URD. This phase also produces a Software Specification Document (SSD), which serves as a blueprint for the development stage, including system architecture, menu structure, and data structures.
Architectural Design:
This phase designs the computer system and software architecture, also known as high-level design. The architecture should enable all modules' functionalities, interfaces, dependencies, databases, diagrams, and technical details. This phase also defines the content for integration testing.
Module Design:
The module design phase, also known as low-level design, breaks down the system into smaller units or modules, detailing each part to allow programmers to write code directly. Low-level design documents or program specifications include logic details for modules and are often represented using pseudocode. Unit testing is planned during this phase.
Verification Phase
Unit Testing:
In the V-Model, unit test plans are devised during the module design phase. Unit test plans aim to eliminate errors at the code and unit levels. A unit is the smallest independent block of code. Unit testing verifies that the smallest code block functions correctly when isolated from other code.
Integration Testing:
Integration test plans are defined during the architectural design phase. Integration testing verifies whether independently created and tested modules can coexist and communicate with each other. Integration test results are often shared with the user's team.
System Testing:
System test plans are defined during the system design phase. System testing is different from unit and integration testing. System testing plans are carried out by the user's team to ensure the developed software meets expected requirements. It tests the software's functionality, interdependencies, and communication.
User Acceptance Testing:
User acceptance test plans are defined during the requirement analysis phase and executed by enterprise users. User acceptance testing simulates the actual product environment using real data to confirm that the delivered system meets customer needs and can function in the intended environment.
Software Tools | ISO 26262-Compliant Software Development Tools
Software development tools (design aids, simulation tools, verification tools) must be certified before they can be used in automotive functional safety projects. Besides software and hardware components, items, systems, functions, hardware products, and software products can be reused in automotive functional safety projects, but all must undergo rigorous evaluation processes before reuse.
Hardware Solutions | Hardware in Automotive Functional Safety
1. Basic hardware components (e.g., resistors, transistors) → Must be certified under ISO 16750, AEC Q100, AEC Q200, etc.
2. Hardware components (e.g., decoders, CAN transceivers) → Must be certified under ISO 16750, AEC Q100, AEC Q200, etc. If related to safety requirements, ISO 26262 Part 8 Clause 13 must also be followed.
3. Hardware elements (e.g., actuators, sensors, MCUs) → Must comply with ISO 26262 Part 8 Clause 13. If related to safety requirements, ISO 26262 Part 4 and ISO 26262 Part 5 must also be followed.
4. Complex hardware elements (e.g., ECUs) → Must comply with ISO 26262 Part 4 and ISO 26262 Part 5 requirements.