Architecting the Technical Safety Concept in ISO 26262

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.

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)

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.

ASIL Decomposition in Technical Safety Architecture

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

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.

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 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