Skip to main content
Understanding ISO 26262 is essential for working with TestAuto2 because the standard’s methodology, terminology, and deliverables form the architectural foundation of the solution’s data model, workflows, and traceability requirements.

​
What Problem Does ISO 26262 Solve?

Modern vehicles contain hundreds of electronic control units (ECUs) managing safety-critical functions like braking, steering, and collision avoidance. A software defect or hardware failure in these systems can lead to injury or death. ISO 26262 addresses this risk by requiring:
  • Systematic hazard identification at the vehicle level before design begins
  • Risk classification (ASIL) that determines the rigor required for development and verification
  • Bidirectional traceability from hazards through requirements to test cases
  • Quantified safety goals with measurable failure rate targets
  • Verification evidence demonstrating that safety requirements are met
  • Independent assessment by qualified functional safety managers
Think of ISO 26262 as a safety contract: if you follow the prescribed process for your ASIL level, you have defensible evidence that your system is acceptably safe.

​
The V-Model Lifecycle Framework

ISO 26262 organizes the development process using the V-Model methodology, which TestAuto2 implements through its space structure and traceability model: diagram The left descending leg represents requirements decomposition (what to build), the right ascending leg represents verification and validation (proving you built it correctly). Every work item on the left must have corresponding test evidence on the right.

​
ASIL: The Risk-Based Rigor Scale

The cornerstone of ISO 26262 is ASIL (Automotive Safety Integrity Level), a risk classification that determines how much process rigor is required:
ASIL LevelMeaningDevelopment RigorExample Hazard
QMQuality Management onlyStandard automotive quality processesCourtesy light failure
ASIL ALowest safety requirementBasic verification, minimal independenceWindshield wiper reduced speed
ASIL BModerate safety requirementEnhanced verification, architectural analysisAEB delayed activation
ASIL CHigh safety requirementIndependent assessment, hardware safety analysisUnintended braking during cornering
ASIL DHighest safety requirementMaximum rigor, formal methods, proven componentsLoss of braking while descending grade
ASIL is not assigned arbitrarily—it is calculated from three factors during the Hazard Analysis and Risk Assessment (HARA): 
┌────────────────────────────────────────────────┐
│  ASIL Determination Matrix (ISO 26262-3)      │
└────────────────────────────────────────────────┘

Input Dimensions:
  S = Severity (S0-S3): Potential harm to occupants
  E = Exposure (E0-E4): Frequency of operational situation
  C = Controllability (C0-C3): Driver's ability to avoid harm

Example Calculation for "Failure to detect obstacle":
  S3 (severe injury) + E4 (medium probability) + C3 (uncontrollable)
  → Lookup in ISO 26262-3 Table D.5 → ASIL D

TestAuto2 Implementation:
  - HARA Risksheet computes ASIL automatically via formula
  - Safety Goal inherits ASIL from parent Hazard
  - Requirements inherit ASIL from Safety Goal
  - Test Cases must verify all ASIL-rated requirements
ASIL does NOT rate the safety of a product or system as a whole. ASIL rates individual safety goals derived from specific hazards. A single system may contain multiple safety goals with different ASIL levels (e.g., ASIL D for collision avoidance, ASIL A for reduced wiper speed).

​
The HARA Process (ISO 26262 Part 3)

HARA (Hazard Analysis and Risk Assessment) is the foundational analysis that identifies what can go wrong and how bad it could be. TestAuto2 implements HARA through the HAZID Risksheet with structured columns for systematic analysis:
  1. Situation Analysis: Define operational scenarios (e.g., “highway driving at 120 km/h”, “urban intersection with pedestrians”)
  2. Hazard Identification: Describe malfunctioning behavior (e.g., “unintended acceleration”, “failure to brake”)
  3. Consequence Analysis: Estimate potential harm (Severity S0-S3)
  4. Exposure Estimation: Determine how often the situation occurs (Exposure E0-E4)
  5. Controllability Assessment: Evaluate driver’s ability to avoid harm (Controllability C0-C3)
  6. ASIL Determination: Automatic lookup based on S×E×C per ISO 26262-3 Table D.5
  7. Safety Goal Derivation: Define top-level safety requirements to mitigate the hazard
Each Hazard work item in TestAuto2 stores these classifications in custom fields (haraSeverity, haraExposure, haraControllability, hara-asil), and the HARA Risksheet formula automatically computes ASIL. Safety Goals are then linked via the derives link role, inheriting the ASIL classification.

​
Safety Goals and Functional Safety Requirements

A Safety Goal is a top-level safety requirement derived from a hazard, written in measurable terms with a quantified failure rate target. TestAuto2 represents Safety Goals as work items with the safetyGoal type. Example from the TestAuto2 demo project:
  • Hazard: Failure to detect obstacle - no braking (ASIL D)
  • Safety Goal SG-02: Ensure obstacle detection reliability with <10 FIT (Failures In Time per billion hours)
  • Refinement: System Requirements for sensor fusion, redundant processing, diagnostic coverage
Safety Goals refine into Functional Safety Requirements (stored as System Requirements with ASIL inheritance), which then cascade through the V-Model into Subsystem Requirements and Design Requirements. The entire chain is traceable using the refines link role, and every requirement must have corresponding verification test cases linked via the verifies relationship.

​
Verification and Validation Requirements

ISO 26262 draws a critical distinction between verification and validation:
  • Verification (Parts 4, 5, 6): “Are we building it right?” — Prove that each requirement is correctly implemented at its level
    • System Requirements verified by System Integration Tests
    • Hardware Design Requirements verified by Hardware-in-Loop Tests
    • Software Unit Requirements verified by Unit Tests
  • Validation (Part 4): “Are we building the right thing?” — Prove that the implemented system actually mitigates the original hazard in real-world conditions
    • Safety Goals validated by vehicle-level tests in operational scenarios
    • Validation Test Cases linked to Safety Goals via validates link role
TestAuto2 implements this distinction through two test case types (verificationTestCase, validationTestCase) and separate PowerSheet configurations for tracking coverage at each level.
Hazard: Unintended braking during cornering (ASIL C)
Safety Goal: Prevent false-positive obstacle detection with <0.01% rate
System Requirement: Implement curve radius compensation algorithm
Verification: Unit test proves algorithm calculates radius within ±2%
Validation: Vehicle test on test track with 50 m radius curve at 60 km/h shows zero false braking events over 1000 passes

​
Traceability Requirements (ISO 26262 Part 8)

ISO 26262 Part 8 mandates bidirectional traceability across the entire V-Model. TestAuto2 implements this through link roles and PowerSheet RTM (Requirements Traceability Matrix) configurations:
UpstreamLink RoleDownstream
HazardderivesSafety Goal
Safety GoalrefinesSystem Requirement
System RequirementrefinesDesign Requirement
Design Requirementverifies ←Verification Test Case
Safety Goalvalidates ←Validation Test Case
CharacteristicassessesFailure Mode
Failure Modemitigates ←Risk Control
The Whole RTM PowerSheet provides an interactive view of the complete traceability network, and the Requirements Traceability Report dashboard uses Velocity macros to calculate coverage percentages and identify gaps. Traceability gaps are non-compliances under ISO 26262—every safety-relevant requirement must have objective verification evidence before release.

​
How TestAuto2 Implements ISO 26262

TestAuto2’s data model directly maps ISO 26262 concepts:
  • Spaces organize content by V-Model phase (Requirements, Design, Risks, Testing)
  • Work Item Types represent ISO 26262 artifacts (Hazard, Safety Goal, Requirement, Test Case)
  • Custom Fields store HARA classifications (S, E, C, ASIL), FTTI (Fault Tolerant Time Interval), safety state
  • Link Roles enforce traceability relationships (derives, refines, verifies, validates, mitigates)
  • Workflows manage document lifecycle (draft → inReview → approved → published) per Part 8 requirements
  • Risksheet provides interactive HARA analysis with automatic ASIL calculation
  • PowerSheet provides RTM views with coverage metrics and gap detection
  • Velocity Dashboards generate compliance scorecards showing readiness by ISO 26262 Part
The Safety Readiness Scorecard automatically evaluates compliance across Parts 3-6, showing percentage completion for requirements, traceability, verification, and FMEA coverage.

​
ISO 26262 vs Other Standards

TestAuto2 supports multiple automotive safety standards simultaneously because they address complementary aspects:
StandardFocusRelationship to ISO 26262
ISO 26262Functional safety (malfunction scenarios)Foundational—defines ASIL, safety goals, V-Model
AIAG-VDA FMEAFailure mode analysis methodologyImplements ISO 26262 Part 4 requirement for systematic failure analysis
IATF 16949Quality management for automotiveDefines baseline quality processes (QM level below ASIL A)
ISO 21448 (SOTIF)Safety of intended functionalityExtends ISO 26262 to non-malfunction scenarios (e.g., sensor limitations)
See Standards Compliance Model for details on how these standards interact within TestAuto2.

​
Next Steps

Conceptual Understanding: Practical Application: Reference Materials: