ISO 26262 Standards: What is Functional Safety

Functional safety is defined as the “absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems” according to the ISO 26262 standard.

An automotive safety goal is the minimum level of protection that an automobile part must have to operate properly and not cause damage to the vehicle.

Understanding and executing functional safety concepts is crucial in the creation of modern road cars, given the growing complexity and integration of electrical and software systems into automotive design.

The ISO 26262 standard contains regulations and recommendations for the entire cycle of development of the products, from design to closure. It explains how to establish an acceptable risk level to a system or component and document the entire testing process.

Key Components of Road Vehicle Functional Safety

1. ISO 26262: This international standard provides a foundation for functional safety in the automotive industry. It covers the entire lifecycle of automotive electronics and software, from concept and design to manufacturing, operation, servicing, and decommissioning.
2. Hazard Analysis and Risk Assessment (HARA): A systematic strategy to identify potential hazards and evaluate associated risks. It aids in determining safety objectives and functional safety criteria.
3. Safety Lifecycle: This encompasses phases such as concept development, product development, production, operation, servicing, and decommissioning. Safey should be an important criterion at all these stages.
4. Safety Goals: High-level safety goals established from hazard analysis that seek to reduce or eliminate identified risks.
5. Functional Safety Requirements (FSR): These are specific requirements developed from the safety goals, describing the capability required to accomplish those safety goals.
6. Technical Safety Requirements (TSR): These convert the functional safety criteria into technical specifications for hardware and software.
7. Safety Mechanisms: These are the tactics and mechanisms used to detect and mitigate problems, such as redundancy, monitoring systems, and fail-safes.
8. Verification and Validation: These are the processes for ensuring that the safety criteria are correctly applied and that the finished product meets all safety objectives. This stage comprises testing, simulation, and review.
9. Safety Culture: Encourage a company-wide commitment to safety, ensuring that all employees understand the value of safety and their responsibility in preserving it.
10. Certification and Compliance: Ensure that items meet applicable safety standards and laws, which may involve third-party audits and certifications.

ISO 26262 Standard Structure

The ISO 26262 standard is divided into multiple parts, each of which addresses various areas of functional safety.

ISO 26262 is a comprehensive standard focusing on the functional safety of road vehicles, electronic and software systems. The ISO 26262 requires that the automotive software engineers incorporate safety concepts throughout the software development lifecycle. Here is a detailed look into how the ISO 26262 standard affects software development, which is Product Development at the Software Level (Part 6), in the diagram above. The key differences between traditional SDLC and ISO 26262 SDLC are:

• ISO 26262 promotes functional safety and risk reduction, whereas traditional SDLC focuses on the overall program functionality.
• ISO 26262 mandates tight adherence to processes, traceability, and documentation, whereas typically, SDLC is more flexible.
• ISO 26262 requires thorough testing for safety compliance, including fault injection and structural coverage, which are not normally required in standard SDLC.
• ISO 26262 highlights the value of a safety culture and specific roles, which are uncommon in traditional SDLC.

ISO 26262 for the light of software development

1. Safety Lifecycle and V-Model:

The ISO 26262 software development process often follows the V-Model, which ensures that each development step has a verification phase. The key phases include:

• Software Requirements Analysis: Determining what the software must accomplish to meet the system’s functional safety requirements.
• Software Architectural Design: Defining the program structure, including partitioning into elements, flow of data, and interfaces.
• Software Unit Design and Implementation: Designing and coding the individual software modules, in detail.
• Software Integration and Testing: Combining software components and testing their interactions.
• Software Verification: Ensuring that the software properly implements the desired safety functionality.
• Software Configuration and Change Management: Maintaining control over changes to ensure that the safety criteria are satisfied.

Phases of the V-Model:

Left Side of V-Model: Development Activities

1. Concept Phase:

• Hazard analysis and risk assessment (HARA) is used to identify dangers and set safety targets.
• The functional safety concept defines high-level safety standards.

2. System Development:

• The technical safety concept is used to determine technical safety standards.
• System design involves defining the architecture and interfaces.

3. Hardware Development:

• Hardware Safety Requirements: Hardware safety criteria are developed from the technical safety concept.
• Hardware design and execution: Create and implement hardware components that meet safety specifications.

4. Software Development:

• Software Safety Requirements: Software safety criteria are drawn from the technical safety concept.
• Software design, development, and implementation: Design and implement software that meets safety standards.

Right Side of V-Model: Verification and Validation Activities

1. Validation of Safety Goals: Ensure that the developed system achieves the safety objectives established during the idea phase.
2. System Verification: Ensure that the system design meets the technical safety criteria.
3. Hardware Verification: Ensure that the hardware design meets the hardware safety criteria.
4. Software Verification: Ensure that the software design and implementation meet the software safety criteria.
5. Integrate and test:
   • System integration testing ensures that hardware and software interact properly to meet safety criteria.
   • Fault injection testing validates the system’s behavior under fault situations.

2. Automotive Safety Integrity Levels (ASIL):

One of the initial phases in the ISO 26262 process is to identify the ASIL for each safety target, which can range from ASIL A (lowest criticality) to ASIL D (highest criticality). ASIL increases the degree of diligence required in development and verification processes.

ISO 26262 does not specify failure criteria for software based on ASIL levels. Instead, it offers a process-oriented method for ensuring that software is built in accordance with the ASIL classification’s safety goals. This involves:

• Hazard analysis and risk assessment (HARA) are used to establish safety objectives.
• Usage of Hazard Analysis and Risk Assessment (HARA) to establish safety objectives.
• Deriving functional and technical safety needs.
• Ensuring that these standards are met.

3. Development Process:

• Software Requirements Specification (SRS): The system-level functional safety requirements (FSR) serve as the foundation for detailed requirements. The SRS should address functional behavior, performance, limitations, and safety needs.
• Software Design:
  • Architectural Design: High-level design in which software components and their interactions are specified. Consider fault-tolerant methods, redundancy, and safe state transitions.
  • Detailed Design: Low-level design specifies the behavior and interfaces of individual components.
• Implementation: Writing the code in accordance with the comprehensive design and following coding standards that increase safety (e.g., MISRA C).

4. Verification and Validation (V&V):

ISO 26262 requires intensive V&V efforts to guarantee that the software meets the safety criteria.

• Static Analysis: Code reviews and static code analysis tools can discover potential flaws without executing the code.
• Dynamic Analysis: Executing the code and comparing its behavior to expected results.
• Unit Testing: Testing separate software pieces to guarantee they work properly in isolation.
• Integration Testing: Ensure that coupled units perform as intended.
• System Testing: Testing the integrated software throughout the entire system.
• Fault Injection Testing: Introducing failures intentionally to evaluate the robustness of safety systems.

5. Supporting Processes:

• Configuration Management: Ensure that all the software modifications are tracked and maintained.
• Change Management: Evaluating and managing all the modifications to avoid creating new safety risks.
• Documentation: Documenting and maintaining the complete software development lifecycle.

6. Safety Analysis Techniques:

• Failure Mode and Effects Analysis (FMEA): Analyzing probable failure modes in the software and their consequences.
• Fault Tree Analysis (FTA): A top-down method to discover the causes of probable safety-critical occurrences.

Best Practices for Software Developers

• Adhere to Coding Standards: To limit the possibility of coding errors, follow known automotive coding rules like MISRA C/C++.
• Automate Testing: Use automated testing methods to increase efficiency and coverage.
• Continuous Integration (CI): Integrate and test code frequently to spot issues early.
• Peer Reviews: Conduct regular code and design reviews to uncover flaws that automated tools may overlook.
• Training: Ensure that all team members are familiar with ISO 26262 requirements and best practices.

Conclusion

For software developers, ISO 26262 compliance demands a disciplined approach to software development, with a significant emphasis on safety at all stages. By adhering to the standard’s requirements, automotive software developers can assist in ensuring that their solutions meet high safety standards, thereby contributing to the development of safer automobiles.