Title: Architecting the Technical Safety Concept in ISO 26262 | ISO 26262 Academy
URL: https://iso26262.academy/blog/architecting-the-technical-safety-concept-in-iso-26262
Description: Master the Technical Safety Concept under ISO 26262. Explore FTTI budgets, ASIL decomposition, and interface safety to elevate your system architecture.

---
# Architecting the Technical Safety Concept in ISO 26262

![AI-generated illustration of an open automotive ECU, wiring harness and oscilloscope on a vehicle development bench.](https://iso26262.academy/edge-media/p/blog/images/2026/09/9e5a546e-9548-4be1-86c3-4feb6c042f5c-1672.webp)

A safety goal needs an architecture that can deliver it. How do timing budgets, ASIL decomposition and E2E checks turn functional requirements into a technical safety concept? A practical look at the decisions that connect ISO 26262 safety intent to hardware and software.

![ISO 26262 Academy](https://iso26262.academy/logo.png) ISO 26262 Academy

By [Paul Danci](https://iso26262.academy/about) 16 September 2026 9 min read

Share

Text size

A functional safety concept defines what an automotive system must do to mitigate hazards, while the technical safety concept specifies technical safety requirements and their allocation within the system architecture. This article outlines the transition from abstract safety goals to concrete architectural mechanisms, detailing how timing constraints, communication interfaces, and independence requirements shape the technical safety architecture.

Developing a robust technical architecture requires translating item-level behaviors into precise component-level constraints. Engineers must allocate safety mechanisms across microcontrollers, power supplies, and communication buses while proving that these elements operate within strict timing budgets. The resulting architecture forms the blueprint for all subsequent hardware and software development phases.

## The Role of Technical Safety in the ISO 26262 Lifecycle

In the ISO 26262 lifecycle, the technical safety phase bridges the gap between the vehicle-level concept and the domain-specific engineering tasks. The Functional Safety Concept answers what the system must do to stay safe: for each safety goal it states the required safety behaviour and decides, on a first sketch of the architecture, which part is responsible for it. The Technical Safety Concept takes those functional requirements and maps them to a specific system architecture.

This phase demands a deep understanding of the chosen hardware components and software execution environments. The outputs include Technical Safety Requirements, their allocation, and the system architectural design. These requirements define fault detection and control mechanisms, degradation strategies, and the safe states or emergency operation needed to prevent safety goal violations.

By explicitly allocating each requirement to either hardware, software, or a combination of both, the technical safety concept ensures that no safety-critical function is left unassigned. This allocation process also reveals potential bottlenecks in processing power, memory protection, and network bandwidth early in the design cycle.

![Safety goals lead to functional safety requirements, then technical safety requirements allocated across hardware, software and their interfaces.](https://iso26262.academy/edge-media/p/blog/images/2026/09/142cc4da-92a8-4ddb-9c9b-54852d068b5f-1920.webp)

Technical requirements connect functional intent to hardware, software and interface constraints.

## Deriving Technical Safety Requirements

Transforming functional requirements into technical requirements requires analyzing the specific failure modes of the chosen architecture. Consider a hypothetical Adaptive Cruise Control system. A functional requirement might state that the system must prevent unintended acceleration exceeding a specific threshold. The corresponding technical requirements must define the exact mechanisms used to enforce this limit.

For this system, the technical requirements would specify a torque request plausibility check within the main microcontroller. They would define the acceptable voltage ranges for the radar sensors, the diagnostic test intervals for the analog-to-digital converters, and the exact error flags that must be set if a sensor output drifts out of bounds. The degradation logic depends on the safety concept: radar failure might require controlled ACC deactivation and a driver warning, or continued operation using a validated redundant sensing path.

Crucially, technical requirements must be verifiable. A requirement stating that a memory component must be "reliable" is invalid. For example, a RAM requirement can specify single-bit error correction and double-bit error detection per protected codeword, together with detection latency and the required response to an uncorrectable error.

### Managing the Fault Tolerant Time Interval (FTTI)

![Fault occurrence starts FDTI and FTTI. Detection starts FRTI, which ends at the required response. FHTI equals FDTI plus FRTI and fits within FTTI.](https://iso26262.academy/edge-media/p/blog/images/2026/09/58ab249b-7f23-4e36-8ddc-08885c38bbd5-1920.webp)

FHTI covers detection and reaction; FTTI bounds the time available without effective safety mechanisms.

The Fault Tolerant Time Interval is a key item-level timing constraint. Think of it as a countdown that starts when the fault appears: if nothing reacts before it runs out, a hazardous event becomes possible. The term is defined in ISO 26262-1 (3.61). Fault handling must maintain or reach a safe state, or enter specified emergency operation, within this interval. Emergency operation has its own duration limit.

To achieve this, engineers calculate the maximum Fault Handling Time Interval. FHTI adds two parts together: the time it takes to notice the fault (FDTI) and the time it takes to react to it (FRTI). The detection interval runs from fault occurrence to detection, including any manifestation delay, diagnostic scheduling and debouncing. The reaction time includes the processing delay to command the safe state and the physical actuation time (such as de-energizing a relay or ramping down motor torque).

The worst-case handling time must fit within the relevant FTTI; design for FHTI < FTTI with a justified margin. If the proposed architecture cannot meet this budget, the engineering team must either select faster hardware, optimize the diagnostic software, or redesign the physical actuation path.

Keep learning

[Free course preview Technical Safety Concept](https://iso26262.academy/features/concepts/technical-safety-concept) [Or test yourself with the 7-question demo exam](https://iso26262.academy/demo-exam)

## ASIL Decomposition in Technical Safety Architecture

![An ASIL D requirement is decomposed into two redundant B(D) requirements, each fulfilling the original requirement, with sufficient independence justified by dependent failure analysis.](https://iso26262.academy/edge-media/p/blog/images/2026/09/a83295d6-ffdb-437c-9c7b-ec3a0a93d9cb-1920.webp)

D → B(D) + B(D) requires redundancy and sufficient independence.

ASIL decomposition can be applied at different development levels, including technical safety concept development, to tailor the ASIL of redundant safety requirements. When a safety requirement carries a high Automotive Safety Integrity Level, developing a single complex component to that standard can be prohibitively expensive. Decomposition allocates redundant requirements to sufficiently independent elements; each must fulfil the original requirement on its own.

A common misconception is that decomposition reduces the hardware architectural metric targets for random hardware failures. This is incorrect. The safety goal retains its original ASIL. The applicable hardware architectural metrics and random hardware failure evaluation remain tied to that ASIL; decomposition does not relax those targets.

Furthermore, decomposition is only valid if the apportioned elements are sufficiently independent. Duplicating the exact same software on two identical microcontrollers does not provide independence against systematic software bugs or common-cause hardware design flaws. Dependent Failure Analysis must justify sufficient independence by addressing common-cause and cascading failures that could violate the safety requirement.

### The Freedom from Interference (FFI) Mandate

If parts with different ASILs live in the same element, the lower-rated parts may keep their lower ASIL (or QM) only if you can show they are unable to break the higher-ASIL requirements; without that evidence, everything in the element is developed to the highest ASIL present (ISO 26262-9, Clause 6). This principle ensures that a failure in a lower-criticality component cannot cascade and corrupt a higher-criticality function.

The software architecture must address memory, timing and execution, and exchange of information. Memory Protection Units can restrict access; scheduling and resource budgets can bound interference. Watchdogs detect selected execution faults but do not provide isolation by themselves. Communication checks and traffic controls address corrupt data and excessive bus use.

## Protecting Interfaces for Technical Safety

| Communication Failure Mode | E2E Protection Mechanism | Architectural Purpose |
| --- | --- | --- |
| Information Corruption | Cyclic Redundancy Check (CRC) | Detects covered corruption patterns; residual errors remain possible |
| Message Loss or Delay | Timeout Monitoring | Detects missing updates; application logic selects the specified response |
| Repetition or Sequence Error | Alive / Sequence Counter | Detects repetition and sequence faults within the configured profile |
| Masquerading / Addressing Error | Data ID Check | Detects message mix-ups through the expected Data ID; no sender authentication |

Mapping of common communication failure modes to their respective End-to-End (E2E) protection mechanisms.

Interfaces are important safety boundaries. System-level development establishes the Hardware-Software Interface specification, which is refined during hardware and software development. This specification includes interrupt priorities, diagnostic register behaviors, and the precise control lines required to trigger a hardware safe state.

When safety-critical data crosses physical boundaries between Electronic Control Units, the communication link introduces new failure modes. ISO 26262 requires the technical architecture to protect against data corruption, message loss, unintended delays, and sequence errors. This is typically managed through End-to-End communication protection protocols.

The technical safety requirements must allocate a specific portion of the overall timing budget to the communication bus. They must also define the exact safety states the receiver should adopt if a message times out or fails its integrity check. Whether utilizing Classic CAN, CAN FD, or Automotive Ethernet, the receiver needs checks for communication integrity, sequence and timeliness. E2E safety protection does not provide cryptographic sender authentication.

![A sending application adds E2E protection. The receiver checks CRC, Data ID, counter and timeout, then uses the check result in its specified fault response.](https://iso26262.academy/edge-media/p/blog/images/2026/09/7ef8a581-db29-4281-b2e2-5a6f0795ccc9-1920.webp)

E2E checks detect communication faults; the application implements the required response.

## Conclusion

The technical safety concept is the definitive bridge between functional intent and physical reality. Defining timing budgets, justifying independence where required, and protecting interfaces supports effective fault handling in the specified operating conditions. The concept supports ISO 26262 compliance; verification and validation must substantiate it.

Building these architectures requires a deep understanding of ASIL algebra, dependent failure analysis, and timing allocations. To master these principles and explore interactive architectural models, explore the [Technical Safety Concept learning resource](https://iso26262.academy/features/concepts/technical-safety-concept) on ISO 26262 Academy.

## Abbreviations & Key Definitions

- **ASIL** - Automotive Safety Integrity Level, a risk classification scheme defined by ISO 26262
- **ACC** - Adaptive Cruise Control, an advanced driver-assistance system that maintains a safe distance from vehicles ahead
- **CAN** - Controller Area Network, a robust vehicle bus standard designed for microcontrollers to communicate without a host computer
- **CPU** - Central Processing Unit, the primary component of a computer that acts as its "brain"
- **ECC** - Error-Correcting Code, a method for detecting and correcting data corruption in memory
- **ECU** - Electronic Control Unit, an embedded system that controls one or more of the electrical systems or subsystems in a vehicle
- **E2E** - End-to-End, protection that detects covered communication faults between sending and receiving applications
- **FFI** - Freedom from Interference, making sure a fault in one part cannot spread into another part and break its safety function
- **FHTI** - Fault Handling Time Interval, how long the system needs in total to notice a fault and then reach a safe state
- **FTTI** - Fault Tolerant Time Interval, the time budget between a fault appearing and the earliest moment it could lead to a hazardous event if nothing reacts
- **HARA** - Hazard Analysis and Risk Assessment, the concept-phase analysis that works out what could go wrong at vehicle level, how serious each risk is, and which ASIL it gets
- **HSI** - Hardware-Software Interface, the specification defining the interaction between hardware and software elements
- **MCU** - Microcontroller Unit, a compact integrated circuit designed to govern a specific operation in an embedded system
- **RAM** - Random Access Memory, a form of computer memory that can be read and changed in any order
- **SPFM** - Single-Point Fault Metric, a percentage showing how much of the dangerous hardware failure rate is caught by safety mechanisms or designed out
- **TSC** - Technical Safety Concept, the system-level design that turns the functional safety requirements into concrete technical measures and assigns them to hardware and software
- **TSR** - Technical Safety Requirement, a requirement derived from the functional safety concept allocated to hardware and software

Last updated: 30 October 2026

Tags [asil-decomposition](https://iso26262.academy/blog/tag/asil-decomposition) [system-architecture](https://iso26262.academy/blog/tag/system-architecture) [ftti](https://iso26262.academy/blog/tag/ftti) [technical-safety](https://iso26262.academy/blog/tag/technical-safety) [iso-26262](https://iso26262.academy/blog/tag/iso-26262)

Share this article

## Comments

## Go deeper: Technical Safety Concept

Open the free course preview to see what the full course covers. Or check yourself against exam-style questions, graded like the real exam.

[Open the course preview](https://iso26262.academy/features/concepts/technical-safety-concept) [Take the 7-question demo exam](https://iso26262.academy/demo-exam)

Ready for a full course? [Start free with the complete Functional Safety Concept guide](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Ffunctional-safety-concept&utm_source=website&utm_medium=cta&utm_campaign=blog_end)

Keep learning

## Guides on this topic.

The guide this article draws on, and where the topic leads next.

[Browse all guides](https://iso26262.academy/features/concepts#library)

- System level [Technical Safety Concept](https://iso26262.academy/features/concepts/technical-safety-concept) Learn how to translate safety goals and FSC into technical safety requirements (TSRs), system architecture, and HW/SW allocation. Covers safety mechanisms, diagnostic coverage, FMEA integration, and a complete worked example with templates. [Expert](https://iso26262.academy/pricing#plan-advanced) 17 chapters
- System level [The Hardware-Software Interface (HSI)](https://iso26262.academy/features/concepts/hardware-software-interface) The HSI is the bilateral contract where ISO 26262 hardware and software meet. Learn to specify registers, allocate diagnostics, budget timing against the FTTI, and run joint reviews so safety mechanisms actually work at the boundary. [Expert](https://iso26262.academy/pricing#plan-advanced) 10 chapters
- System level [Freedom from Interference (FFI)](https://iso26262.academy/features/concepts/freedom-from-interference) Learn how to ensure elements of different ASILs do not interfere through temporal, spatial, and data partitioning. Covers MPUs, hypervisors, bus monitoring, multi-core strategies, and evidence generation for assessments. [Expert](https://iso26262.academy/pricing#plan-advanced) 12 chapters

## Related Articles

[![An automotive driver-assistance controller board with two identical processor packages side by side, next to a larger processor, memory, power components and a row of connectors, all on one PCB.](https://iso26262.academy/edge-media/p/blog/images/2026/10/d0792939-6e66-418e-935b-485f4dc3db35-1200.webp) Technical

### The Core Concept of Dependent Failure Analysis in ISO 26262

7 min Oct 2](https://iso26262.academy/blog/the-core-concept-of-dependent-failure-analysis-in-iso-26262) [![Abstract geometric network of connected nodes against a pale blue background.](https://iso26262.academy/edge-media/p/blog/images/2026/09/58953e56-2c83-4359-ab7f-b917bd73e6ee-640.webp)

### Dependent Failure Analysis: Three Checks Beyond Redundancy

3 min Sep 29](https://iso26262.academy/blog/practical-tips-for-mastering-dependent-failure-analysis-in-iso-26262) [![5 Essential Advices for ASIL Decomposition in ADAS Architectures](https://iso26262.academy/_next/image?url=https%3A%2F%2Fiso26262.academy%2Fedge-media%2Fp%2Fblog%2Fimages%2F2026%2F03%2F85a4f098-5684-4484-9429-6ca19a3a4746.jpg&w=1920&q=75)

### 5 Essential Advices for ASIL Decomposition in ADAS Architectures

9 min Mar 2](https://iso26262.academy/blog/5-essential-advices-for-asil-decomposition-in-adas-architectures)