Skip to main content
Safety Goal is a work item type in TestAuto2 — Automotive Safety Solution that represents a top-level functional safety requirement derived from hazard analysis. Safety Goals form the bridge between ISO 26262 Hazard Analysis and Risk Assessment (HARA) and the formal functional safety concept phase, translating hazard mitigation strategies into implementable requirements.

​
Overview

Safety Goals capture the desired safe state or behavior that must be achieved to prevent or mitigate a hazardous event identified during HARA. Each Safety Goal:
  • Derives from one or more Hazards via the derivedFrom link role
  • Inherits ASIL classification from its parent Hazard(s)
  • Decomposes into System Requirements and lower-level requirements through the V-Model
  • Participates in bidirectional traceability linking risk analysis to functional safety requirements
  • Drives test case creation for verification and validation planning
Safety Goals are typically created during HARA completion and serve as the primary input to the functional safety concept phase of ISO 26262 Part 4 (System Design).

​
Core Properties

NameTypeDefaultDescription
IDStringAuto-generatedUnique identifier for the Safety Goal (e.g., SG-001). Typically assigned sequentially or by system element prefix.
TitleString(required)Concise title describing the safe state or mitigation measure. Example: “Ensure obstacle detection reliability”. Should use active voice and specify the desired outcome.
DescriptionText(optional)Detailed description of the Safety Goal, including context, rationale, and how it addresses the identified hazard. May reference operational scenarios or hazardous events.
StatusEnumdraftWorkflow state: draft, proposed, approved, implemented, verified, retired. Reflects progress through functional safety development lifecycle.
AssigneeUser(optional)Person responsible for implementing or validating the Safety Goal. Typically a systems engineer or functional safety lead.
PriorityEnumnormalRelative priority: low, normal, high, critical. ASIL-derived Safety Goals should typically be marked high or critical.

​
Custom Fields (Safety Goal-Specific)

NameTypeDefaultDescription
safetyGoalIdString(auto)Formal reference identifier following project naming convention (e.g., SG-02, SG-SENSOR-001). Used in traceability reports and compliance documentation.
asilLevelEnum(required)Automotive Safety Integrity Level inherited from parent Hazard(s): QM, ASIL-A, ASIL-B, ASIL-C, ASIL-D. Determines verification rigor and safety mechanisms required.
hazardReferenceLink(required)Bidirectional link to the parent Hazard work item(s) that this Safety Goal mitigates. Establishes traceability back to HARA analysis. Link role: derivedFrom (inverse: derives).
controlTypeEnum(optional)ISO 26262 control hierarchy classification: inherent-safety-design, protective-measure, information-for-safety. Guides whether mitigation relies on architecture, detection mechanisms, or procedures. See Risk Control Types for detailed definitions.
safetyMechanismText(optional)Description of the safety mechanism or architectural approach used to achieve this Safety Goal. Example: “Redundant sensor fusion with voting logic” or “Watchdog timer with safe shutdown”.
rationaleText(optional)Justification for the Safety Goal, including how it prevents or mitigates the identified hazardous event. Should explain the causal relationship between the goal and hazard mitigation.
acceptanceCriteriaText(optional)Measurable acceptance criteria for Safety Goal implementation. Should be testable and traceable to verification test cases.
notesText(optional)Additional notes, assumptions, or constraints related to this Safety Goal (e.g., dependencies on other Safety Goals, design constraints).
Link RoleTarget TypeCardinalityDirectionDescription
derivedFromHazard1..* → 1BackwardLinks Safety Goal to the Hazard(s) it mitigates. Establishes HARA-to-functional-safety traceability. Safety Goal inherits ASIL from parent Hazard.
refinesSystem Requirement0..*ForwardSafety Goal decomposes into one or more System Requirements. Part of vertical requirements decomposition in V-Model. Typically created during System Design phase.
mitigatesRisk Control0..*BackwardRisk Control work items that implement this Safety Goal. Establishes traceability from abstract goal to concrete risk mitigation measures (e.g., watchdog, redundancy).
validatesValidation Test Case0..*BackwardValidation test cases that verify this Safety Goal in operational scenarios. Supports ISO 26262 V&V strategy.
verifiesVerification Test Case0..*BackwardSystem-level verification test cases that confirm Safety Goal implementation. Used for design verification evidence collection.

​
Visual: HARA-to-Functional Safety Concept Flow

diagram

​
Workflow States

Safety Goals typically progress through the following lifecycle:
StateDescriptionTypical Actions
draftInitial creation from HARA outputFill in ASIL, control type, and acceptance criteria. Under review by Safety Engineer.
proposedProposed for approvalDocumented rationale and decomposition strategy. Ready for design team review.
approvedApproved by functional safety leadConfirmed ASIL allocation, control strategy endorsed. May now be refined into System Requirements.
implementedIntegrated into requirement hierarchyDecomposed into System Requirements and linked to risk controls. Part of active development scope.
verifiedVerification evidence collectedAssociated test cases executed and passing. Verification matrix complete.
retiredNo longer applicableObsoleted due to requirement change, design evolution, or scope reduction. Retain for audit trail.

​
Examples

​
Example 1: Obstacle Detection Reliability (ASIL-B)

ID:                    SG-02
Title:                 Ensure obstacle detection reliability
ASIL Level:            ASIL-B
Derived From:          HAZ-005 (Failure to detect obstacle)
Control Type:          Protective Measure
Safety Mechanism:      Dual-sensor fusion with cross-validation

Description:
Safety goal to mitigate the hazard of delayed or failed obstacle detection
that could result in insufficient braking force application. Requires robust
sensor fusion logic with plausibility checking to detect sensor degradation
and trigger safe shutdown if confidence below threshold.

Acceptance Criteria:
- Obstacle detection latency ≤ 100ms at highway speeds
- Cross-sensor disagreement triggers diagnostic → safe degradation
- System detects ≥80% of 10cm obstacles at 100km/h

Decomposition:
  ├─ SysReq-12: Implement dual camera + radar sensor fusion
  ├─ SysReq-13: Sensor plausibility check with confidence scoring
  └─ SysReq-14: Safe mode transition on sensor disagreement > threshold

​
Example 2: Braking Control Safety (ASIL-D)

ID:                    SG-01
Title:                 Maintain continuous AEB braking capability
ASIL Level:            ASIL-D
Derived From:          HAZ-001 (Power supply failure)
                       HAZ-003 (Excessive braking force)
Control Type:          Inherent Safety Design
Safety Mechanism:      Redundant power supply with automatic failover

Description:
Top-level safety goal to prevent loss of braking capability due to power
supply failure. Requires dual independent power supply paths (primary +
backup battery) with automatic switchover logic. Safety architecture must
ensure braking actuation possible even with single power supply failure.

Acceptance Criteria:
- Braking available with any single power supply failure
- Switchover latency ≤ 50ms
- Backup battery capacity supports minimum 10 emergency brake events

Decomposition:
  ├─ SysReq-01: Dual independent power supply design
  ├─ SysReq-02: Battery management with switchover logic
  ├─ SysReq-03: Power supply diagnostics with self-test
  └─ SysReq-04: Safe shutdown if both supplies fail

​
PowerSheet Integration

Safety Goals appear in the Whole RTM PowerSheet with bidirectional expansion:
  • Upstream expansion → Hazard (shows parent hazard context, ASIL source)
  • Downstream expansion → System Requirements (shows decomposition tree)
The PowerSheet displays traceability chains: Filtering by ASIL level or control type enables Safety Engineer dashboards to focus on high-criticality items requiring design emphasis.

​
Risksheet Configuration

In HARA Risksheet workflows, Safety Goals are often created inline using the TaskLink column type. The Risksheet automatically:
  • Creates new safetyGoal work items
  • Links them via derivedFrom to the parent Hazard
  • Inherits ASIL classification automatically via formula
  • Sets initial status to proposed
This supports agile HARA workflows where Safety Goals emerge from interactive risk assessment sessions.

​
Traceability and Compliance

Safety Goals serve as critical compliance evidence for ISO 26262:
  • Part 3 (Concept Phase): HARA output directly produces Safety Goals
  • Part 4 (System Design): Safety Goals drive System Requirement definition and ASIL allocation strategy
  • Part 8 (Clause 6): Bidirectional traceability from Hazard → Safety Goal → System Requirement → Verification Test Case required for certification
Use the Requirements Traceability Report to validate:
  • ✓ Every ASIL B-D Hazard has at least one Safety Goal
  • ✓ Every Safety Goal is linked to System Requirement(s)
  • ✓ Every Safety Goal has verification or validation test case(s)
  • ✓ ASIL classification consistent across traceability chain