About This Guide
This guide walks you through filling in the RTMify template for ISO 26262:2018, the road vehicle functional safety standard. ISO 26262 specifies processes for developing electrical/electronic systems in automotive applications to prevent or mitigate hazardous failures. It covers E/E systems architecture (Part 3), hardware design (Part 5), and software design/verification (Part 6). Part 2 defines ASIL (Automotive Safety Integrity Level) A through D, which drives the rigor of requirements specification, design, testing, and documentation.
The standard mandates a V-model development cycle: Hazard Analysis and Risk Assessment (HARA, Part 3 §7) identifies safety goals; Functional Safety Requirements (FSRs, Part 4 §6) and Technical Safety Requirements (TSRs, Part 6 §6) implement those goals; and Verification/Validation per Part 6 §9–§11 confirms correctness. ASIL inheritance and decomposition rules (Part 2 §5) govern how ASILs propagate through the architecture.
For ISO 26262 workbooks, run RTMify Trace with the automotive profile. That enables automotive-specific chain checks for ASIL inheritance, decomposition, and configuration-item continuity instead of limiting validation to the generic requirement/test matrix.
By the end of this guide, you'll have a complete RTM linking safety goals through functional and technical requirements, test plans, and risk controls. This RTM is a key artifact in your design documentation and demonstrates compliance with ISO 26262 Part 6 traceability requirements.
What ISO 26262 Requires
Hazard Analysis and Risk Assessment (Part 3 §7, HARA)
The first step is HARA, which identifies potential hazards in E/E systems and assigns risk levels. Each hazard is evaluated on a 3×4 severity/exposure/controllability matrix to determine ASIL:
- Severity (S1–S3) — Potential injury level: S1 (no/minor injury), S2 (serious injury), S3 (death or multiple serious injuries)
- Exposure (E0–E4) — Probability of hazard occurrence: E0 (not exposed), E1 (very low), E2 (low), E3 (medium), E4 (high)
- Controllability (C1–C3) — Ability of driver to control hazard: C1 (easily controllable), C2 (normally controllable), C3 (difficult to control)
- ASIL (A–D) — Resulting safety integrity level: ASIL A (lowest rigor) to ASIL D (highest rigor); ASIL QM for non-safety functions
Examples: "Unintended acceleration" (S3/E4/C3 → ASIL D); "Parking brake failure" (S2/E4/C3 → ASIL B). Record HARA results in User Needs (UN) with the hazard context and assigned ASIL.
Functional Safety Requirements (Part 4 §6)
Part 4 §6 mandates functional safety requirements (FSRs) derived from safety goals. FSRs are system-level specifications defining what the E/E system must accomplish to prevent or mitigate hazards; e.g., "Unintended acceleration shall not occur" (addresses S3/E4/C3 hazard). FSRs form the contract between system design and implementation and are typically documented in a separate System Safety Requirements Specification. In RTMify, FSRs map to User Needs (UN).
Technical Safety Requirements (Part 6 §6)
Part 6 §6 specifies technical safety requirements (TSRs) for software implementation. TSRs are derived from FSRs and define verifiable, measurable specifications for software modules; e.g., "The throttle controller SHALL limit output to 0 Nm when brake force > 50N". Each TSR must:
- Be traceable to an FSR/safety goal (UN) and ASIL
- Be testable — measurable success criteria, SHALL language
- Specify ASIL — inherited from FSR or decomposed per Part 2 §5
- Include design rationale — Why this requirement prevents the hazard
RTMify's Requirements tab captures TSRs with ASIL-prefixed IDs (REQ-D-, REQ-C-, etc.) for clarity.
Software Verification (Part 6 §9–§11)
Part 6 mandates verification activities: Unit Testing (§9) validates individual modules; Integration Testing (§10) validates module interactions; and Qualification Testing (§11) validates end-to-end correctness. Verification methods include:
- Test — Functional testing, HIL (hardware-in-the-loop), fault injection, SIL (software-in-the-loop)
- Analysis — FMEA, fault tree analysis, algorithm correctness proofs, static analysis
- Inspection — Code review, design review, traceability review
- Demonstration — Real-vehicle testing, test track validation, operational scenarios
Each requirement must be linked to verification activities per §9–§11. ASIL D requirements require more rigorous verification (multiple independent tests, high code coverage) than ASIL A.
ASIL Inheritance and Decomposition (Part 2 §5)
ASIL propagates through the design hierarchy: if a module implements an ASIL D requirement, the module itself is ASIL D and must meet ASIL D verification rigor. Decomposition allows breaking a high-ASIL requirement into multiple lower-ASIL requirements if the combination achieves the safety goal; e.g., an ASIL D unintended acceleration goal can decompose into REQ-D-001 (torque limit, D) + REQ-C-001 (brake override, C) + diagnostic monitoring (B). Document decomposition arguments in your safety case and link decomposed requirements in RTMify Notes.
Bidirectional Traceability (Part 6)
ISO 26262 requires full traceability: every hazard → safety goal (UN) → FSR/TSR (REQ) → test (TG) → verification results. Every requirement must have a parent User Need and linked tests. Untraced items indicate incomplete design and compliance gaps. RTMify's Trace feature validates this chain.
Step-by-Step Walkthrough
Define Safety Goals from HARA (Part 3 §7)
Conduct Hazard Analysis and Risk Assessment (HARA) per Part 3 §7. Identify potential hazards, assess Severity/Exposure/Controllability, and assign ASIL. Document safety goals derived from hazards as User Needs (UN). Sources include:
- Hazards identified through FMEA or other systematic analysis (e.g., "Throttle stuck open → unintended acceleration")
- Risk assessment: S/E/C matrix → ASIL assignment
- Safety goals: e.g., "Unintended acceleration shall not occur" (ASIL D)
- Regulatory/industry standards (ISO 26262, OEM safety goals)
Use ID format UN-nnn. Include HARA context (S/E/C values) in Source column. Be specific: "Unintended acceleration shall not occur" is a clear safety goal; "System shall be safe" is not.
| ID | Description | Source | Priority |
|---|---|---|---|
| UN-001 | Unintended acceleration shall not occur | HARA (S3/E4/C3 = ASIL D) | High |
| UN-002 | Driver shall be warned of imminent collision in time to react | HARA (S3/E3/C2 = ASIL C) | High |
| UN-003 | Parking brake shall engage when vehicle is stationary and driver exits | HARA (S2/E4/C3 = ASIL B) | Medium |
| UN-004 | Instrument cluster shall display vehicle speed accurately | HARA (S1/E4/C1 = ASIL A) | Medium |
Tips: Every User Need must correspond to a safety goal from your HARA. Include S/E/C values and resulting ASIL in the Source column for auditor visibility. Each UN should trace forward to at least one TSR (REQ). Unlinked User Needs indicate incomplete design. The HARA itself is maintained in your safety case documentation (not in RTMify), but RTMify serves as the traceability index linking HARA results to requirements and tests.
Write Functional & Technical Safety Requirements (Part 4 §6 & Part 6 §6)
Document functional safety requirements (FSRs) from Part 4 §6 and technical safety requirements (TSRs) from Part 6 §6. FSRs are system-level (e.g., "Unintended acceleration shall not occur"); TSRs are software-specific (e.g., "Throttle controller SHALL limit torque to 0 Nm when brake > 50N"). Each requirement must include ASIL and trace to a safety goal.
- Requirement ID (REQ-X-nnn) — Prefix with ASIL letter (D, C, B, A) or QM for clarity; e.g., REQ-D-001
- Description — Functional specification, measurable, testable (use SHALL for mandatory requirements)
- Traces — Parent safety goal (UN-nnn)
- Priority — Safety-critical (High) or quality-managed (Medium/Low)
- Test Group — Link to verification activities (TG-nnn)
- Status — Approved, In Review, Draft
- Notes — ASIL (D/C/B/A/QM), design rationale, risk mitigation reference
| ID | Description | Traces | Priority | Test Group | Status | Notes |
|---|---|---|---|---|---|---|
| REQ-D-001 | The throttle controller SHALL limit torque output to ≤ 0 Nm when brake pedal force > 50N | UN-001 | High | TG-001 | Approved | ASIL D |
| REQ-D-002 | The throttle controller SHALL detect sensor disagreement within 10ms and enter safe state | UN-001 | High | TG-002 | Approved | ASIL D |
| REQ-C-001 | The ADAS module SHALL issue forward collision warning ≥ 2.5 seconds before predicted impact at TTC < 4s | UN-002 | High | TG-003 | Approved | ASIL C |
| REQ-B-001 | The parking brake ECU SHALL engage brake within 500ms of driver exit detection when vehicle speed = 0 | UN-003 | Medium | TG-004 | Approved | ASIL B |
| REQ-A-001 | The instrument cluster SHALL display vehicle speed with accuracy ±1 km/h at speeds > 20 km/h | UN-004 | Medium | TG-005 | Approved | ASIL A |
Tips: Use SHALL for safety-critical requirements (ASIL A–D). Include numeric success criteria (±1 km/h, ≤ 10ms, etc.) for verifiability per Part 6 §6. Assign ASIL based on HARA: ASIL D for S3/E4/C3 hazards, ASIL B for S2/E4/C3, etc. If decomposing a high-ASIL requirement, document decomposition rationale in Notes and link to sibling REQs. Every requirement must have a Test Group for verification per Part 6 §9–§11. For ASIL D, ensure multiple independent tests are specified. See Requirements for detailed guidance on requirement quality and traceability depth.
Plan Verification & Validation (Part 6 §9–§11)
Define verification and validation activities per Part 6 §9 (Unit Testing), §10 (Integration Testing), and §11 (Qualification Testing). Link tests to requirements via Test Group. Verification methods include:
- Test — Functional testing, HIL, SIL, fault injection, dynamometer testing
- Analysis — FMEA, fault tree analysis, algorithm analysis, code coverage metrics
- Inspection — Code review, design review, traceability review, safety plan review
- Demonstration — Test track validation, real-vehicle testing, operational scenarios
| Test Group | Test ID | Type | Method | Description |
|---|---|---|---|---|
| TG-001 | T-001 | Verification | Test | Torque limiting HIL test — brake + throttle simultaneous input |
| TG-001 | T-002 | Verification | Analysis | Fault tree analysis — unintended acceleration paths |
| TG-002 | T-003 | Verification | Test | Sensor disagreement detection timing — fault injection |
| TG-003 | T-004 | Verification | Test | FCW timing validation — radar/camera target simulation |
| TG-003 | T-005 | Validation | Demonstration | Test track validation — real-vehicle collision avoidance scenarios |
| TG-004 | T-006 | Verification | Test | Parking brake engagement timing — vehicle dynamometer |
| TG-005 | T-007 | Verification | Test | Speedometer accuracy — chassis dyno at 20–200 km/h |
Tips: Create test entries for unit testing (T-001, T-002 per §9), integration testing (T-003 per §10), and validation (T-004, T-005 per §11). Each Test Group (TG) must link to a requirement. One requirement may have multiple tests: e.g., TG-001 includes T-001 (HIL test) and T-002 (fault tree analysis) verifying torque limiting. ASIL D requirements require more rigorous verification: multiple independent test methods, fault injection, high code coverage (>90%). ASIL A may require simpler testing (unit test only). Include test track validation (Demonstration) for high-ASIL functions; e.g., TG-003 includes T-005 real-vehicle collision avoidance test for ASIL C forward collision warning. See Tests & Verification for detailed verification guidance and method selection per ASIL level.
Document HARA Hazards and Risk Mitigations (Part 3 §7 Integration)
Identify hazards from HARA, assess severity/occurrence/detectability, and link mitigation requirements. Track residual risk post-mitigation. Per Part 3 §7, every identified hazard must have documented mitigation (requirements, design features, or diagnostic measures).
| Risk ID | Description | Severity | Occurrence | Mitigation | Linked Req | Residual Severity | Residual Occurrence |
|---|---|---|---|---|---|---|---|
| RSK-D-101 | Throttle stuck open due to software fault → unintended acceleration | 5 | 3 | Independent monitoring processor with safe-state torque cutoff | REQ-D-001 | 5 | 1 |
| RSK-D-102 | Sensor disagree condition masked by software → undetected failure | 5 | 2 | Diverse redundant sensing, independent diagnostic path | REQ-D-002 | 5 | 1 |
| RSK-C-101 | FCW triggers too late due to radar latency | 4 | 3 | Dual sensor (radar + camera) with conservative TTC threshold | REQ-C-001 | 4 | 1 |
Tips: Use ASIL-prefixed Risk IDs (RSK-D-, RSK-C-, etc.) matching mitigation requirement ASIL. Assess severity/occurrence on a 1–5 scale; severity typically maps to HARA Severity (S1–S3 → 1–5), occurrence to Exposure. Mitigation is implemented through requirements: e.g., "Throttle stuck open" (RSK-D-101) is mitigated by REQ-D-001 (independent torque cutoff). Track residual risk post-mitigation; auditors expect risk reduction to acceptable levels. Include cybersecurity threats (TARA items per ISO 21434) with "TARA:" prefix if applicable; e.g., RSK-TARA-101 "CAN message spoofing → unintended acceleration" mitigated by REQ-SEC-001 (message authentication). Link each Risk to the requirements that mitigate it; tests (TG) verify mitigation effectiveness. See Risk Management for detailed FMEA and mitigation assessment guidance.
Validate Traceability and ASIL Consistency (Part 6 Compliance)
Run RTMify Trace to validate bidirectional traceability and ASIL consistency. Every requirement should trace to a safety goal (UN), have linked tests, and respect ASIL inheritance/decomposition rules (Part 2 §5). The trace checks:
Use rtmify-trace --profile automotive your-workbook.xlsx for ISO 26262 reviews. The automotive profile is what surfaces ASIL-chain and decomposition gaps before a functional safety assessment.
MISSING_USER_NEED— Requirement with no parent safety goal (traceability upward broken)NO_TEST_LINKED— Requirement with no Test Group (verification per §9–§11 missing)ORPHAN_TEST— Test Group with no Requirement (scope creep or obsolete test)INCOMPLETE_RISK— Risk with no mitigation or residual risk unacceptableORPHAN_USER_NEED— Safety goal with no linked requirement (design input not addressed)ASIL_MISMATCH— Requirement ASIL conflicts with parent safety goal or decomposition rules
Fix all issues before design completion and formal review. A clean RTM demonstrates compliance with Part 6 traceability requirements and is mandatory evidence in your Design History File (DHF) and Design Input/Output documentation per Part 8.
Pro tip: Export your RTM as a traceability report and include it in your Design History File per Part 8 §8.3. Auditors review Part 6 §9–§11 verification and traceability completeness. RTMify's status checks help ensure no orphaned requirements or tests. Cross-reference ASIL decomposition arguments: if your design decomposes ASIL D unintended acceleration into multiple lower-ASIL requirements, document the safety justification in your safety case and link to RTMify via requirement Notes. See Status Codes for full error definitions and remediation steps.
What This Template Covers vs. Doesn't Cover
Covered
- HARA-to-Safety-Goal Traceability (Part 3 §7) — Hazard identification, S/E/C assessment, ASIL assignment, and safety goal derivation mapped to User Needs
- Functional & Technical Safety Requirements (Part 4 §6 & Part 6 §6) — FSR and TSR specification with ASIL annotation and design rationale
- ASIL Inheritance and Decomposition (Part 2 §5) — ASIL-prefixed requirement IDs, decomposition documentation in Notes, and consistency validation
- Software Verification (Part 6 §9–§11) — Unit, integration, and qualification testing strategy; bidirectional traceability per §9–§11; multiple verification methods per ASIL level
- Risk-to-Requirement Linkage (Part 3 §7 Integration) — Hazard mitigation tracking, residual risk assessment, and verification of mitigation effectiveness
- Design Input/Output Documentation (Part 8) — RTM serves as traceability evidence for Design Input (safety goals, requirements) and Design Output (tests, verifications)
NOT Covered (separate ISO 26262 documentation)
- Detailed HARA Documentation (Part 3 §7 full FMEA/HARA report) — RTMify captures HARA results as User Needs but does not maintain the detailed HARA spreadsheet, severity matrix, or hazard decomposition. Your HARA tool (FMEA software, spreadsheet) is the source; RTMify indexes safety goals.
- Hardware Design & Metrics (Part 5, PMHF, SPFM, LFM) — ISO 26262 Part 5 covers hardware architecture, fault metrics (PMHF, SPFM, LFM for hardware diagnostics). RTMify focuses on software requirements and tests; hardware safety metrics and FMEA are maintained separately per your hardware design process.
- Dependent Failure Analysis (DFA, Part 5) — DFA documents how failures propagate between hardware and software modules. DFA results inform software requirement rigor but are not captured in RTMify; they are part of your safety case documentation.
- Software Architecture & Detailed Design (Part 6 §5–§6 detailed documents) — RTMify captures requirements; detailed architecture diagrams, module interfaces, design specifications are maintained separately in your design documentation tool (CAD, design repository).
- Production & Operation Phases (Part 7) — Part 7 covers post-release maintenance, problem reporting, corrective action. RTMify is design-phase focused; production phase is handled by your QMS change control and field support processes.
- Design History File (DHF) Assembly (Part 8 §8.3) — RTMify generates the traceability matrix portion. You assemble the complete DHF with design inputs, design outputs, verification records, design changes, and compliance evidence per Part 8.
- Cybersecurity (ISO 21434 TARA in detail) — While the Risks tab can accommodate TARA items with a "TARA:" prefix, detailed cybersecurity threat analysis and mitigation strategies are managed in your ISO 21434 TARA register. RTMify indexes cybersecurity requirements that mitigate functional safety hazards.
Frequently Asked Questions
How do I handle ASIL decomposition in the template?
ASIL decomposition (Part 8) allows you to break down a high-ASIL requirement (e.g., ASIL D) into multiple lower-ASIL requirements that collectively achieve the original safety goal. For example, an ASIL D unintended acceleration goal can decompose into REQ-D-001 (torque limit, ASIL D) and REQ-C-001 (brake override, ASIL C) plus REQ-B-001 (diagnostic monitoring, ASIL B) if the decomposition argument is sound. In RTMify, document the decomposition in the User Need (UN) Notes column: e.g., "ASIL D decomposed: REQ-D-001 (D) + REQ-C-001 (C) + RSK monitoring (B)". Link all decomposed requirements to the same User Need and cross-reference in requirement Notes. Your safety case must justify why the decomposed combination achieves the ASIL D safety goal; this argument is maintained in your HARA/Safety Case tool (not in RTMify, but referenced from it).
What is the difference between functional safety requirements and technical safety requirements?
ISO 26262 Part 4 §6 defines functional safety requirements (FSRs) as high-level specifications of what the system must do to prevent or mitigate hazards; e.g., "Unintended acceleration shall not occur" (UN-001). Part 6 §6 defines technical safety requirements (TSRs) as software-specific implementations of FSRs; e.g., "The throttle controller SHALL limit torque to 0 Nm when brake > 50N" (REQ-D-001). In RTMify, User Needs (UN) correspond to system-level safety goals and FSRs. Requirements (REQ) correspond to technical safety requirements. Each TSR (REQ) must trace to at least one FSR/safety goal (UN). Distinguish FSRs from TSRs in your requirements document or in the Notes column of RTMify by prefixing TSR IDs (REQ-D-, REQ-C-, etc.) with ASIL level, making the traceability chain clear: Hazard → HARA → Safety Goal (UN) → FSR → TSR (REQ) → Implementation (code) → Tests (TG).
Do QM (Quality Management) requirements go in the template?
Yes. ISO 26262 Part 6 §4 classifies requirements into two categories: Safety-Related (tagged with ASIL A–D) and Quality Management (QM). QM requirements are non-safety functions subject to standard quality practices but not functional safety rigor. In RTMify, include QM requirements but mark them as "ASIL QM" or "QM (no ASIL)" in the Notes column. Example: REQ-QM-001 "The instrument cluster shall display outside temperature" (ASIL QM, UN-004 parent). QM requirements follow the same Requirements/Tests/Risks structure as ASIL requirements, but may require lower verification rigor (e.g., unit testing alone vs. integration + validation). Use the Priority column to distinguish: High for ASIL (safety-critical), Medium for QM. When running RTMify Trace, ensure QM requirements are linked to tests (even if simpler tests) and do not appear as orphaned. This distinction helps auditors see which requirements are safety-critical vs. quality-managed.
How does ISO 21434 (cybersecurity) fit with this template?
ISO 21434 (automotive cybersecurity risk and incident management) operates in parallel with ISO 26262 functional safety. ISO 21434 Part 4 requires a Threat Analysis and Risk Assessment (TARA) identifying cybersecurity threats (e.g., "Throttle command injection via CAN bus → unintended acceleration"). Cybersecurity mitigation requirements (e.g., "CAN message authentication via HMAC-SHA256") are incorporated into your Risks table with a "TARA:" prefix. Example: RSK-TARA-101 "Throttle CAN message spoofing" with mitigation REQ-SEC-001 (cryptographic authentication). In RTMify, create a Risks tab entry for each TARA item, link it to the mitigating requirement, and track residual cybersecurity risk. The functional safety requirement (REQ-D-001 torque limit) and the cybersecurity requirement (REQ-SEC-001 message authentication) are complementary: functional safety prevents hazards by design, and cybersecurity prevents malicious activation of those hazards. Your Design History File should cross-reference TARA items (managed in your cybersecurity tool) with corresponding RTMify requirements. For simplicity, you may manage cybersecurity requirements in a separate TARA register and link to RTMify via the Risks tab; your safety case then shows how functional safety and cybersecurity requirements together achieve overall vehicle safety.