Skip to main content
Concept guide · ISO 26262-4 §6 · 17 chapters

Technical Safety Concept

Learn how to turn safety goals into real hardware and software requirements, from deriving Technical Safety Requirements through FTTI analysis, ASIL decomposition, safety mechanism selection, HSI specification, dependent failure analysis, and hardware metric validation (SPFM, LFM, PMHF), all aligned with ISO 26262 Part 4.

Chapters
17
Chapters
Interactive Tools
6
Interactive Tools
Case Study
1
Case Study
Video
1
Video
Included inExpert
Start learningSee the chapters
Course intro · 5 minFree preview
A 5 min look inside the course. 2 hours of course videos for registered users.
The short version

Quick answers

What is a technical safety concept in ISO 26262?
The technical safety concept (TSC) is the work product specified in ISO 26262-4 Clause 6 that translates the functional safety concept into technical safety requirements (TSRs) and allocates them to the system architecture. It defines which hardware elements, software elements, and safety mechanisms implement each safety requirement, specifies the hardware-software interface (HSI), and carries the ASIL attribution down from the safety goals. The TSC is the bridge between the vehicle-level functional safety concept of Part 3 and the concrete hardware (Part 5) and software (Part 6) development that follows.
What is the difference between the functional safety concept and the technical safety concept?
The functional safety concept (FSC, ISO 26262-3) states WHAT must happen in solution-independent terms: functional safety requirements, safe states, fault tolerance, and warning strategies derived from the safety goals. The technical safety concept (ISO 26262-4) states HOW: it refines those requirements into technical safety requirements bound to a specific system architecture, names the safety mechanisms, sets timing budgets like the FTTI, and specifies the hardware-software interface. The FSC is written before the architecture is fixed; the TSC is written against a concrete architecture and drives hardware and software development.
Why this course · ISO 26262, Part 4, Clause 6

Why it pays for itself

Turn safety goals into requirements

Learn the derivation discipline that converts functional safety requirements into verifiable, ASIL-attributed technical safety requirements with traceability and allocation rationale an assessor can follow line by line.

Pick the right architecture pattern

Compare 1oo1D, 1oo2, 1oo2D, and TMR patterns with their ASIL capability and trade-offs, then allocate requirements across hardware, software, and external measures with a defensible decomposition argument.

Prove it with hardware metrics

Calculate SPFM, LFM, and PMHF in the TSC context and verify them against ASIL targets, using the same FMEDA workflow the interactive simulator walks you through step by step.

After the course

What you’ll be able to do

Derive Technical Safety Requirements

Transform functional safety requirements into implementable, testable technical safety requirements with full ASIL (Automotive Safety Integrity Level) attribution.

Allocate Requirements to Architecture

Systematically allocate TSRs (Technical Safety Requirements) to hardware, software, and external measures with justified design decisions.

Select Appropriate Safety Mechanisms

Choose and specify safety mechanisms that achieve required diagnostic coverage for your ASIL (Automotive Safety Integrity Level) level.

Calculate HW (Hardware) Architectural Metrics

Apply PMHF (Probabilistic Metric for random Hardware Failures), SPFM (Single-Point Fault Metric), and LFM (Latent Fault Metric) calculations and verify compliance against ISO 26262 Part 5 targets.

Specify Hardware-Software Interfaces

Document HSI (Hardware-Software Interface) specifications with signal definitions, timing constraints, and safety-relevant attributes.

Establish TSC (Technical Safety Concept) Verification Evidence

Plan and document the verification strategy for TSC (Technical Safety Concept) work products including review, analysis, and test evidence.

The curriculum · 17 chapters

Chapter by chapter

  1. 01

    What is a TSC (Technical Safety Concept)?

    Understand the purpose, scope, and critical role of the Technical Safety Concept as the bridge between functional safety requirements and hardware/software design in the ISO 26262 lifecycle.

    • Definition & scope
    • V-Model position
    • TSC vs FSC
  2. 02

    TSC in the Safety Lifecycle

    Trace the TSC through ISO 26262-4 phases and understand its inputs from the FSC, outputs to HW/SW development, and dependencies on HARA and safety goals.

    • Lifecycle phases
    • Work product inputs
    • Upstream dependencies
  3. 03

    Development Workflow

    Follow the complete TSC development process from initial inputs through iterative refinement, covering workflow gates, review checkpoints, and tool-supported activities.

    • Process gates
    • Iterative refinement
    • Tool support
  4. 04

    Writing Technical Safety Requirements

    Learn how to derive verifiable, ASIL-attributed TSRs from functional safety requirements with proper traceability, testability criteria, and allocation rationale.

    • TSR attributes
    • ASIL inheritance
    • Testability criteria
  5. 05

    FTTI & Safe States

    Master Fault Tolerant Time Interval (FTTI) analysis, safe state definition, FDTI/FRTI/EOTTI/MFTTI timing parameters, and emergency operation strategies for degraded modes.

    • FTTI analysis
    • Safe state definition
    • Emergency operation
  6. 06

    Architecture & Patterns

    Compare safety architecture patterns (1oo1D, 1oo2, 1oo2D, TMR/2oo3) and allocate technical safety requirements to hardware, software, and external measures with ASIL decomposition rationale.

    • 1oo1D/1oo2/1oo2D/TMR
    • Element allocation
    • ASIL decomposition
  7. 07

    ASIL Decomposition

    Apply ASIL decomposition per ISO 26262-9 with freedom from interference (FFI) arguments, independence criteria, coexistence analysis, and decomposition algebra for complex architectures.

    • FFI arguments
    • Independence criteria
    • Decomposition algebra
  8. 08

    Safety Mechanisms

    Survey the complete catalog of hardware, software, communication, and system-level safety mechanisms with diagnostic coverage values, ASIL applicability, and implementation trade-offs.

    • HW/SW mechanisms
    • Diagnostic coverage
    • Watchdog & plausibility
  9. 09

    Interfaces & Communication Safety

    Define safe communication protocols, E2E protection mechanisms, bus monitoring, and inter-element interface requirements for CAN, LIN, Ethernet, and SPI.

    • E2E protection
    • Bus monitoring
    • Protocol safety
  10. 10

    HSI Specification

    Document the Hardware-Software Interface with signal definitions, register maps, timing constraints, diagnostic interfaces, and safety-relevant attributes per ISO 26262-4 Clause 6.5.

    • Signal definitions
    • Register maps
    • Timing budgets
  11. 11

    Malfunction Analysis

    Perform systematic malfunction analysis at system level to identify failure modes, effect propagation paths, fault coverage gaps, and residual risks using FMEA and FTA.

    • Failure mode ID
    • Effect propagation
    • FMEA/FTA integration
  12. 12

    Dependent Failure Analysis (DFA)

    Analyze common cause failures (CCF), cascading failures, and common mode failures per ISO 26262-9 with systematic identification methods and mitigation strategies.

    • CCF analysis
    • Cascading failures
    • ISO 26262-9
  13. 13

    Hardware Metrics

    Calculate SPFM, LFM, and PMHF in the TSC context, verify compliance against ASIL B/C/D targets, apply failure rate data, and validate diagnostic coverage assumptions.

    • SPFM/LFM/PMHF
    • ASIL targets
    • FIT rate data
  14. 14

    Verification & Release

    Plan and execute TSC verification activities including requirements reviews, architecture analysis, safety analysis confirmation, metric verification, and integration testing.

    • V&V methods
    • Review criteria
    • Release for production
  15. 15

    Complete Worked Example

    Walk through a complete ASIL D powertrain TSC from FSC inputs through TSR derivation, architecture allocation, safety mechanism selection, metric calculation, and verification evidence.

    • End-to-end example
    • ASIL D powertrain
    • Full traceability
  16. 16

    Build a TSC (Playbook)

    Build a TSC from scratch with a step-by-step decision playbook: a readiness checker, a hazard-to-metric translator, the FTTI budget calculator, architecture and decomposition decisions, and the gates that move you from blank page to verified concept.

    • Readiness checker
    • Hazard to metric
    • Decision gates
  17. 17

    Toolkit & Advanced Reference

    Access TSC templates, checklists, clause-by-clause ISO 26262-4 reference, assessor preparation guides, common pitfalls, and a comprehensive glossary of 100+ safety terms.

    • Templates & checklists
    • Assessor preparation
    • 100+ term glossary
Interactive Tools

Not just text: the visual toolkit

Architecture Pattern Selector

Compare Single-Channel, Dual-Channel Monitor, Dual-Channel Redundant, and TMR (Triple Modular Redundancy) patterns with ASIL capability and trade-offs.

Safety Mechanisms Chart

Interactive scatter plot of safety mechanisms by effectiveness vs. complexity, with clickable data points showing ASIL applicability and characteristics.

Failure-to-Mechanism Mapper

Select failure types (sensor stuck-at, CPU lockup, memory corruption, CAN message loss) and see detection and mitigation mechanisms with diagnostic coverage.

Hardware Metrics Visualization

SPFM (Single-Point Fault Metric), LFM (Latent Fault Metric), and PMHF (Probabilistic Metric for random Hardware Failures) charts with target vs. achieved comparisons and formula displays.

Requirements Allocation Chart

Visualize how technical safety requirements are allocated to hardware and software elements with ASIL decomposition rationale.

FMEDA (Failure Modes, Effects, and Diagnostic Analysis) Simulator

Full interactive simulator to develop and validate safety mechanisms with failure rate inputs, diagnostic coverage calculations, and ASIL compliance checks.

Real-World Application

Complete EPS (Electric Power Steering) Technical Safety Concept

See how a real-world EPS system translates functional safety goals into technical requirements, system architecture allocation, and safety mechanisms with full traceability.

  • Safety goal SG-01 decomposed into 7 traceable TSRs (Technical Safety Requirements) with ASIL D inheritance
  • Dual-processor monitoring architecture with cross-channel comparison at 10 ms cycle
  • FMEA (Failure Mode and Effects Analysis)-driven safety mechanism selection: torque plausibility, end-stop detection, watchdog
  • HSI (Hardware-Software Interface) specification with 47 signals and timing budgets
  • PMHF (Probabilistic Metric for random Hardware Failures) calculation: 2.3 × 10⁻⁸ h⁻¹ against ASIL D target of < 10⁻⁷ h⁻¹
TSR (Technical Safety Requirement) Allocation Matrix
SG-01 → TSR-01: Torque monitoring response < 20 ms [ASIL D]

Unlock in course

Built for

Who this guide is for

  • System engineers writing their first technical safety concept for an ASIL project
  • Safety architects choosing between redundancy patterns and ASIL decomposition options
  • Hardware and software leads who receive TSRs and need to understand where they come from
  • Anyone preparing a TSC work product for a functional safety assessment

Frequently Asked Questions

Common questions about Technical Safety Concept

The HSI specification documents every safety-relevant interaction between hardware and software: signal definitions, register maps, diagnostic interfaces, timing constraints, and the conditions each side may assume about the other. ISO 26262-4 requires it so that hardware and software teams - often in different companies - develop against the same contract. A typical HSI for a steering or braking ECU covers dozens of signals with explicit timing budgets; the course case study documents 47 signals for an electric power steering system.
ASIL decomposition per ISO 26262-9 lets you implement one high-ASIL requirement with redundant elements of lower ASIL, for example ASIL D decomposed into ASIL B(D) plus ASIL B(D). The catch is independence: you must show freedom from interference and sufficient independence between the decomposed elements, typically through a dependent failure analysis covering common cause and cascading failures. Without that evidence the decomposition is invalid and the original ASIL applies. The course dedicates a chapter to decomposition algebra, FFI arguments, and coexistence analysis.
The guide has 17 chapters running from TSC fundamentals through TSR derivation, FTTI and safe states, architecture patterns, ASIL decomposition, safety mechanisms, HSI specification, dependent failure analysis, and hardware metrics to verification and release. It includes 6 interactive tools - among them an architecture pattern selector, a failure-to-mechanism mapper, and an FMEDA simulator - plus a complete electric power steering case study. A free account starts you off, and the Pro and Expert plans unlock more of the library.

Start the course today

A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month - plus 2 hours of course videos for registered users. The Pro and Expert plans unlock more of the 78-guide library. No credit card required.

Start learningView Pricing Plans

We use cookies to measure how this site is used. Essential cookies stay on. Cookie Policy