ISO 26262-3

This section explains how to use the Derisker ISO 26262-3 library to build models in SysML v2 for Functional Safety Concept phase of system lifecycle development. Derisker parses these models to extract item definition, malfunctioning behaviors, hazards, operational situations, hazardous events with their corresponding ASILs, safety goals, and functional safety requirements.

Quick-start guide

This is an example workflow for concept-phase development of an ADAS (Advanced Driver Assistance System) subsystem for the vehicle. It follows ISO 26262-3, in particular Clauses 5 (Item definition), 6 (Hazard analysis and risk assessment), and 7 (Functional safety concept).

Building a HARA and functional safety concept model follows this flow:

  1. Item definition

  2. Malfunctioning behaviours for the item

  3. Hazards

  4. Operational situations

  5. Hazardous events (S/E/C → ASIL)

  6. Safety goals

  7. Functional safety requirements

1. Define the Item

This step corresponds to ISO 26262-3 Clause 5.

Define the vehicle (top-level system) with basic vehicle functions (e.g. accelerate, brake, steer), and the item (subsystem) under analysis with its service functions. Each service function can state dependencies to basic functions. The item boundary, interfaces, and assumptions are captured in the part hierarchy and documentation.

public import Derisker_ISO26262_3::*;

part def ISO26262_3_ItemDefinition {
    part def vehicle :> SystemAnalyses::TopLevelSystem {
        #basicFunction accelerate { doc description /* Accelerate vehicle */; }
        #basicFunction brake    { doc description /* Decelerate vehicle */; }
        #basicFunction steer    { doc description /* Steer vehicle */; }
        part adas : ADAS;
    }

    part def <ADAS> 'advanced driver assistance system L2' :> FusaSubsystem {
        part accs : ACCS;
        part lkas : LKAS;
        // ...
    }

    abstract part def <ACCS> 'adaptive cruise control system' :> SystemAnalyses::Subsystem {
        #serviceFunction <F1> maintain_distance {
            doc description /* Maintain safe following distance to forward vehicle */;
            dependency requiresFunctions from maintain_distance to vehicle::accelerate, vehicle::brake;
            // Malfunctions defined inside the function (see step 2)
        }
    }
}

2. Identify Malfunctioning Behaviours

This step is part of HARA (Clause 6).

Define how each service function can malfunction using the #malfunction metadata inside the function. Set malfunctionType and description. Malfunction types are from the library enum (e.g. LackOfFunction, ExceedingFunction, Unintended, LateFunction).

#serviceFunction <F1> maintain_distance {
    doc description /* Maintain safe following distance to forward vehicle */;
    dependency requiresFunctions from maintain_distance to vehicle::accelerate, vehicle::brake;

    #malfunction <M1> mal_exceed_distance {
        attribute redefines malfunctionType = MalfunctionType::ExceedingFunction;
        attribute redefines description = "Maintain too far distance to forward vehicle";
    }
    #malfunction <M2> mal_narrow_distance {
        attribute redefines malfunctionType = MalfunctionType::UnderperformingFunction;
        attribute redefines description = "Maintain too narrow distance to forward vehicle";
    }
    #malfunction <M3> mal_no_distance {
        attribute redefines malfunctionType = MalfunctionType::LackOfFunction;
        attribute redefines description = "Unable to measure distance to forward vehicle";
    }
    // ...
}

3. Select HARA item, identify Hazards

First, create the HARA analysis case. Every HARA is an analysis with a subject pointing to the item being assessed. The subject is the part definition for the item (subsystem) that is the scope of the hazard analysis and risk assessment.

part def ISO26262_3_HARA {
    doc /* Clause 6: Hazard analysis and risk assessment. */
    analysis HARA {
        subject system : ISO26262_3_ItemDefinition::'advanced driver assistance system L2';
    }
    // HARA_Hazards_Identification, HARA_OpSituations_Identification, HARA_HazEvents_Combination, VehicleSafetyGoals defined below
}

This step is part of HARA (Clause 6).

Define hazards (potential sources of harm at vehicle level) in a dedicated part. Link each hazard to the malfunction(s) that can cause it using the #causation connection of type HazardCausationDef: cause end = malfunction, effect end = hazard.

part def HARA_Hazards_Identification {
    #hazard <H1> haz_large_distance {
        attribute redefines description = "Distance allows cut-in in front of ego vehicle";
        #causation connection : HazardCausationDef
            connect ISO26262_3_ItemDefinition::ACCS::maintain_distance::mal_exceed_distance to self;
    }
    #hazard <H2> haz_narrow_distance {
        attribute redefines description = "Distance is not sufficient to avoid front-end collision";
        #causation connection : HazardCausationDef
            connect ISO26262_3_ItemDefinition::ACCS::maintain_distance::mal_narrow_distance to self;
    }
    // ...
}

4. Define Operational Situations

This step is part of HARA (Clause 6).

Describe operational situations in which the item is assumed to behave in a safe manner. Use the library attributes (e.g. vehicleUsageScenario, location, roadSurfaceType, roadSurfaceConditions, vehicleSpeed, trafficAndPeople) — aligned with ISO 34503/34504 where applicable.

part def HARA_OpSituations_Identification {
    #operationalSituation <OS1> os_urban_minor_road {
        attribute redefines location = DrivableAreaType::'Minor road';
        attribute redefines roadSurfaceType = DrivableAreaSurfaceType::Asphalt;
        attribute redefines vehicleSpeed = " <50 km/h";
        attribute redefines trafficAndPeople = "low traffic density";
    }
    #operationalSituation <OS4> os_highway_normal {
        attribute redefines location = DrivableAreaType::Highway;
        attribute redefines vehicleSpeed = "90-130 km/h";
        attribute redefines trafficAndPeople = "normal traffic density";
    }
    // ...
}

5. Create and Rate Hazardous Events

This step is part of HARA (Clause 6).

A hazardous event is the combination of one hazard and one operational situation. Create one occurrence per (hazard, situation) pair and assign Severity (S), Exposure (E), and Controllability (C) with justifications. Harm is a separate metric: use the harm attribute with AIS_Stages (Abbreviated Injury Scale) to classify potential injury; rating_Severity is the S0–S3 rating used for ASIL. ASIL is derived automatically by the library via ASIL_Calc(rating_Severity, rating_Exposure, rating_Controllability) per ISO 26262-3 Table 4.

part def HARA_HazEvents_Combination {
    private import HARA_Hazards_Identification::*;
    private import HARA_OpSituations_Identification::*;

    #hazardousEvent <HE1> HE1_H1_OS1 {
        ref occurrence redefines hazardRef = haz_large_distance;
        ref occurrence redefines opSituationRef = os_urban_minor_road;
        attribute redefines harm = AIS_Stages::AIS3_Severe_NoLifeThreat;
        attribute redefines rating_Severity = Severity::S2;
        attribute redefines justification_Severity = "Front-end collision if lead vehicle brakes suddenly; restricted speed under 50 km/h.";
        attribute redefines rating_Exposure = Exposure::E4;
        attribute redefines justification_Exposure = "Following a vehicle in front on a minor road takes place often";
        attribute redefines rating_Controllability = Controllability::C2;
        attribute redefines justification_Controllability = "Avoiding crash while experiencing cut-in is controllable.";
        // rating_ASIL is derived automatically (e.g. S2+E4+C2 → ASIL C)
    }
    // ...
}

6. Define Safety Goals

This step corresponds to ISO 26262-3 Clause 6.4.

Formulate safety goals for hazardous events that have an ASIL (not QM). Use the Mitigate allocation to link each safety goal to the hazardous event(s) it mitigates. The safety goal’s ASIL can be derived as the maximum ASIL of the allocated hazardous events via Maximize_ASIL(mitigate_allocations).

requirement def VehicleSafetyGoals {
    private import ISO26262_3_HARA::HARA_HazEvents_Combination::*;

    #safetyGoal requirement <SG1> preventExcessAcceleration {
        require constraint { language "English" /* Prevent excessively high longitudinal acceleration of the vehicle by ACCS */ }
        allocation mitigate_SG1_HE1 : Mitigate allocate self to HE1;
        derived attribute redefines rating_ASIL = Maximize_ASIL(mitigate_SG1_HE1);
        attribute redefines safeStates = "ACCS is disabled and ACC status change warning indicated to driver.";
    }
    #safetyGoal requirement <SG3> disableACCS {
        require constraint { language "English" /* Avoid ACCS operation when safe distance is not maintained or not tracked */ }
        allocation mitigate_SG3_HE3 : Mitigate allocate self to HE3;
        allocation mitigate_SG3_HE4 : Mitigate allocate self to HE4;
        derived attribute redefines rating_ASIL = Maximize_ASIL((mitigate_SG3_HE3, mitigate_SG3_HE4));
        attribute redefines safeStates = "ACCS is disabled and ACC status change warning indicated to driver.";
    }
    // ...
}

7. Define and satisfy Functional Safety Requirements

This step corresponds to ISO 26262-3 Clause 7.

Functional safety requirements (FSRs) are derived from safety goals. Use the Derive allocation to link each top-level FSR to the safety goal(s) it derives from. Top-level FSRs use #FSR and can carry a derived ASIL; decomposed FSRs use #FSR_Decomp and set rating_ASIL to an ASIL_QM_decomp value (e.g. 'A(B)' for ASIL B requirement from decomposition of ASIL B parent) per ISO 26262-9.

requirement def VehicleFSRs {
    private import ISO26262_3_HARA::VehicleSafetyGoals::*;

    #FSR requirement <FSR1> limitAcceleration {
        require constraint { language "English" /* Limit acceleration performance */ }
        allocation derive_SG1_FSR1 : Derive allocate self to SG1;
        derived attribute redefines rating_ASIL = Maximize_ASIL(derive_SG1_FSR1);

        #FSR_Decomp requirement <'FSR1.1'> restrictMaxAcceleration {
            require constraint { language "English" /* Restrict the maximum acceleration by ACCS */ }
            attribute redefines rating_ASIL = ASIL_QM_decomp::'A(B)';
        }
        #FSR_Decomp requirement <'FSR1.2'> actuatorPerformanceReq {
            require constraint { language "English" /* Establish minimal performance requirements on actuators */ }
            attribute redefines rating_ASIL = ASIL_QM_decomp::'A(B)';
        }
    }
    // ...
}

Satisfying Requirements at Item Level completes concept-phase traceability at item level.

The vehicle (or item) part definition can satisfy the safety goals and FSR requirement sets to complete traceability.

part def vehicle :> SystemAnalyses::TopLevelSystem {
    satisfy requirement safetyGoals : ISO26262_3_HARA::VehicleSafetyGoals;
    satisfy requirement FSRs : ISO26262_3_FunctionalSafetyConcept::VehicleFSRs;
    // ...
}

For rating tables, ASIL determination, ASIL decomposition values, and full type reference, see ISO 26262: Road vehicles - Functional safety.