Article 3: From Safety Goals to System Design – Diving into the System Phase of ISO 26262

The journey from high-level safety goals to a fully functional safety-critical system begins with the system phase. This phase transforms the abstract into the tangible by translating safety goals into technical requirements and system architectures. In today’s article, we’ll continue building our Level 4 Autonomous Emergency Braking System (AEB) case study by diving into the system phase, where we design a fault-tolerant architecture that ensures safety and reliability.

Recap of Previous Steps

In the previous article, we:

• Defined the AEB system through the item definition, describing its purpose, functionality, and operational environment.
• Identified potential hazards and assessed their risks using HARA, leading to the derivation of safety goals.
• Translated these goals into functional safety requirements that lay the groundwork for system design.

Now, let’s take these requirements to the next level in the system phase.

System Phase Overview

Purpose of the System Phase: The system phase focuses on:

1. Translating safety goals into technical safety requirements (TSRs).
2. Designing a system architecture that incorporates fault tolerance and safety mechanisms.
3. Defining interfaces between hardware and software components to ensure seamless integration.

This phase ensures that every part of the system is designed with safety in mind.

Step 1: Deriving Technical Safety Requirements (TSRs)

The safety goals from the concept phase are now broken down into actionable technical requirements that guide the system design.

Example TSRs for AEB:

• Obstacle Detection:

1. Redundant sensors (radar + camera) must detect obstacles within a 100-meter range under all operational conditions.
2. Sensors must self-diagnose malfunctions and notify the system within 1 second.

• Braking Response:

1. Braking commands must be executed within 0.5 seconds of obstacle detection.
2. The braking system must ensure deceleration rates of at least 3 m/s².

• False Positive Mitigation:

1. Decision-making software must validate detections using sensor fusion before issuing a braking command.
2. The system must log false positive events for future algorithm refinement.

Step 2: Designing the System Architecture

The system architecture implements the technical safety requirements by defining how hardware and software components interact.

High-Level Architecture for AEB:

1. Sensors:Radar and camera for obstacle detection, with LiDAR as an optional backup.Diagnostic units integrated into each sensor to detect failures or miscalibrations.
2. Braking Controller:Executes braking commands received from the decision-making module.Includes redundancy to handle potential hardware failures.
3. Decision-Making Module:Processes sensor data and classifies obstacles.Applies safety rules to determine when braking is necessary.
4. Interfaces:Well-defined communication protocols between sensors, decision-making modules, and the braking controller to ensure seamless data flow.

Key Architectural Considerations:

• Redundancy: Dual sensors and controllers to ensure system reliability.
• Diagnostics: Real-time monitoring to identify and respond to failures.
• Isolation: Safety-critical components (e.g., braking controller) are isolated from non-critical systems to avoid interference.

Step 3: Defining Interfaces

Clear and robust interfaces are essential for the system to function seamlessly.

Example AEB Interfaces:

• Sensor-to-Decision-Making Interface:

1. Data Format: Obstacle coordinates, speed, and classification.
2. Communication Protocol: CAN or Ethernet.

• Decision-Making-to-Braking Interface:

1. Command: Deceleration rate and duration.
2. Safety Mechanism: Timeout feature to prevent braking delays.

• Diagnostic Interface:

1. Reports: Sensor status, fault logs, and system health indicators.

Verification and Validation in the System Phase

To ensure that the system design meets the technical safety requirements, verification and validation (V&V) activities are conducted.

Key V&V Activities:

• Requirement Traceability: Confirm that each TSR is implemented in the design.
• Simulations: Test the system architecture under various operational scenarios (e.g., sudden pedestrian crossing).
• Fault Injection Testing: Introduce sensor failures to validate redundancy and diagnostic mechanisms.

Practical Example: Applying the System Phase to AEB

Let’s illustrate the process with an example:

Scenario: A pedestrian unexpectedly crosses in front of the vehicle.

• Obstacle Detection: Both radar and camera detect the pedestrian at 50 meters.
• Decision-Making: Sensor data is fused, confirming the pedestrian’s presence. The system determines braking is necessary.
• Braking Response: The braking controller receives the command and begins deceleration at 3.5 m/s², avoiding the collision.

What if a Sensor Fails?

• If the radar malfunctions, the camera continues to detect the pedestrian. Diagnostic checks identify the radar fault and alert the system, but redundancy ensures braking proceeds without delay.

Key Takeaways

1. The system phase bridges the gap between safety goals and tangible designs, ensuring every safety requirement is actionable.
2. Technical safety requirements guide system design, incorporating redundancy, fault tolerance, and clear interfaces.
3. Verification and validation are critical to confirm that the system architecture meets safety goals under all conditions.

The system phase establishes the foundation for hardware and software development. In the next article, we’ll explore the hardware development phase, focusing on how components like sensors and controllers are designed to meet technical safety requirements. Stay tuned to see how hardware reliability contributes to functional safety!

#FunctionalSafety #ISO26262 #SystemDesign #AEB #SafetyStandards