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
- 01What is a TSC (Technical Safety Concept)?
- 02TSC in the Safety Lifecycle
- 03Development Workflow
- 04Writing Technical Safety Requirements
- 05FTTI & Safe States
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.
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.
Chapter by chapter
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
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
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
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
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
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
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
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
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
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.
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⁻¹
Unlock in course
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
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. The Pro and Expert plans unlock more of the 77-guide library. No credit card required.