Demo page details

Page source code: index.rst

  1{% set page="index.rst" %}
  2{% include "demo_page_header.rst" with context %}
  3
  4🛡️ ISO 26262 Functional Safety Example
  5========================================
  6
  7This example demonstrates the ISO 26262 functional safety development process
  8for vehicle actuation systems of automated vehicles, following the safety lifecycle
  9from Hazard Analysis and Risk Assessment (HARA) through Functional Safety
 10Requirement (FSR) derivation.
 11
 12.. note::
 13
 14   This example is based on real research from **TU Braunschweig** (Stolte, Bagschik, Maurer, 2016):
 15   *"Safety Goals and Functional Safety Requirements for Actuation Systems of Automated Vehicles"*
 16   presented at IEEE 19th International Conference on Intelligent Transportation Systems (ITSC).
 17
 18System Scope
 19------------
 20
 21**Vehicle Actuation Systems for Automated Vehicles**
 22
 23The example focuses on safety requirements for vehicle actuation systems that perform
 24**trajectory follow control** for automated vehicles. The system includes:
 25
 26- Vehicle Dynamics Controller (VDC)
 27- Wheel Rotational Dynamics Controller (WRDC)
 28- Steering Controller (SC)
 29- Brake Controller
 30- Drive Controller
 31
 32These systems operate without human supervision (SAE Level 4/5 automation) and must
 33ensure functional safety through systematic hazard analysis and requirement derivation.
 34
 35ISO 26262 Safety Process
 36-------------------------
 37
 38This example demonstrates the following safety lifecycle phases:
 39
 40**1. HARA (Hazard Analysis & Risk Assessment)**
 41   Identify hazardous events, assess severity (S), exposure (E), and controllability (C),
 42   and assign Automotive Safety Integrity Level (ASIL).
 43
 44**2. Safety Goals**
 45   Define top-level safety requirements to mitigate identified hazards. Safety goals
 46   are technology-agnostic and assigned ASIL ratings from HARA.
 47
 48**3. FSRs (Functional Safety Requirements)**
 49   Decompose safety goals into specific, verifiable functional requirements that
 50   describe what the system must do to achieve the safety goals.
 51
 52**4. SYSREQs (System Requirements)**
 53   Define concrete system capabilities, performance metrics, and architectural
 54   characteristics that implement the FSRs in a technology-aware manner.
 55
 56ASIL Levels
 57-----------
 58
 59.. list-table::
 60   :header-rows: 1
 61   :widths: 10 90
 62
 63   * - ASIL
 64     - Description
 65   * - QM
 66     - Quality Management (no safety requirements)
 67   * - A
 68     - Lowest safety integrity level
 69   * - B
 70     - Medium-low safety integrity level
 71   * - C
 72     - Medium-high safety integrity level
 73   * - D
 74     - Highest safety integrity level (most stringent)
 75
 76STPA Methodology
 77----------------
 78
 79The safety goals and functional safety requirements in this example were derived
 80using **STPA (System-Theoretic Process Analysis)**, a hazard analysis technique
 81based on systems theory. STPA systematically identifies:
 82
 83- Unsafe control actions
 84- Causal factors for unsafe behavior
 85- Safety requirements at multiple levels of abstraction
 86
 87Documentation Structure
 88-----------------------
 89
 90.. toctree::
 91   :maxdepth: 1
 92
 93   hara
 94   safety_goals
 95   fsr
 96   system_requirements
 97   analysis
 98
 99Key Statistics
100--------------
101
102.. needpie:: Safety Artifacts by Type
103   :labels: Hazards, Safety Goals, FSRs, SYSREQs
104
105   type == "hazard" and "safety_example" in docname
106   type == "safety_goal" and "safety_example" in docname
107   type == "fsr" and "safety_example" in docname
108   type == "sysreq" and "safety_example" in docname
109
110.. warning::
111
112   **Demonstration Purpose Only**
113
114   This safety example is provided for demonstration and educational purposes to illustrate
115   the capabilities of Sphinx-Needs for ISO 26262 safety documentation. The content is based
116   on academic research and simplified for clarity.
117
118   **This example should NOT be used as-is for real-world safety-critical systems without:**
119
120   - Comprehensive hazard analysis specific to your system and operational design domain
121   - Detailed engineering analysis and validation by qualified safety engineers
122   - Full ISO 26262 compliance activities including independent safety assessment
123   - Adaptation to your specific vehicle architecture, sensors, and actuators
124   - Verification and validation per ASIL D requirements
125   - Proper review and approval by your organization's safety management
126
127   Real safety-critical automotive systems require rigorous engineering processes, independent
128   audits, and certification activities that go far beyond this documentation example.

🛡️ ISO 26262 Functional Safety Example

This example demonstrates the ISO 26262 functional safety development process for vehicle actuation systems of automated vehicles, following the safety lifecycle from Hazard Analysis and Risk Assessment (HARA) through Functional Safety Requirement (FSR) derivation.

Note

This example is based on real research from TU Braunschweig (Stolte, Bagschik, Maurer, 2016): “Safety Goals and Functional Safety Requirements for Actuation Systems of Automated Vehicles” presented at IEEE 19th International Conference on Intelligent Transportation Systems (ITSC).

System Scope

Vehicle Actuation Systems for Automated Vehicles

The example focuses on safety requirements for vehicle actuation systems that perform trajectory follow control for automated vehicles. The system includes:

  • Vehicle Dynamics Controller (VDC)

  • Wheel Rotational Dynamics Controller (WRDC)

  • Steering Controller (SC)

  • Brake Controller

  • Drive Controller

These systems operate without human supervision (SAE Level 4/5 automation) and must ensure functional safety through systematic hazard analysis and requirement derivation.

ISO 26262 Safety Process

This example demonstrates the following safety lifecycle phases:

1. HARA (Hazard Analysis & Risk Assessment)

Identify hazardous events, assess severity (S), exposure (E), and controllability (C), and assign Automotive Safety Integrity Level (ASIL).

2. Safety Goals

Define top-level safety requirements to mitigate identified hazards. Safety goals are technology-agnostic and assigned ASIL ratings from HARA.

3. FSRs (Functional Safety Requirements)

Decompose safety goals into specific, verifiable functional requirements that describe what the system must do to achieve the safety goals.

4. SYSREQs (System Requirements)

Define concrete system capabilities, performance metrics, and architectural characteristics that implement the FSRs in a technology-aware manner.

ASIL Levels

ASIL

Description

QM

Quality Management (no safety requirements)

A

Lowest safety integrity level

B

Medium-low safety integrity level

C

Medium-high safety integrity level

D

Highest safety integrity level (most stringent)

STPA Methodology

The safety goals and functional safety requirements in this example were derived using STPA (System-Theoretic Process Analysis), a hazard analysis technique based on systems theory. STPA systematically identifies:

  • Unsafe control actions

  • Causal factors for unsafe behavior

  • Safety requirements at multiple levels of abstraction

Documentation Structure

Key Statistics

../_images/need_pie_73cb8.svg

Warning

Demonstration Purpose Only

This safety example is provided for demonstration and educational purposes to illustrate the capabilities of Sphinx-Needs for ISO 26262 safety documentation. The content is based on academic research and simplified for clarity.

This example should NOT be used as-is for real-world safety-critical systems without:

  • Comprehensive hazard analysis specific to your system and operational design domain

  • Detailed engineering analysis and validation by qualified safety engineers

  • Full ISO 26262 compliance activities including independent safety assessment

  • Adaptation to your specific vehicle architecture, sensors, and actuators

  • Verification and validation per ASIL D requirements

  • Proper review and approval by your organization’s safety management

Real safety-critical automotive systems require rigorous engineering processes, independent audits, and certification activities that go far beyond this documentation example.