Technical Safety Concept (TSC)

From Safety Requirement to Technical Solution

After the Functional Safety Concept, the required safe behavior of an item is defined. What remains open is how this behavior will be technically implemented: through which system elements, interfaces, diagnostic paths, redundancies, operating modes, and verification evidence.

The Technical Safety Concept, or TSC, is a central work product of product development at system level according to ISO 26262-4. It describes how the Functional Safety Requirements defined in the Functional Safety Concept are implemented through concrete technical measures and a suitable system architecture.

At its core, the TSC answers three questions: Which Technical Safety Requirements are derived from the FSR? Which architecture is suitable to fulfill these requirements in an ASIL-consistent way? And which safety mechanisms must detect faults, control them, or transition the system into a safe state?

What the TSC Provides

The TSC connects functional safety intent with a technical system solution. According to ISO 26262-4, clause 6.2, it is essentially an aggregation of technical safety requirements and the associated system architecture. This aggregation justifies why the selected system solution is suitable to fulfill the safety requirements derived from the concept phase according to ISO 26262-3.

The technical solution must not be considered in isolation. The TSC also needs to account for non-safety requirements, design restrictions, and constraints from production, operation, service, and decommissioning. This is where the system level becomes visible: safety is not placed next to the architecture, but integrated into it.

The central tasks of the TSC are to:

• specify Technical Safety Requirements for implementing FSR,
• define and justify the system architecture including safety mechanisms,
• ensure consistency between the Functional Safety Concept and technical implementation,
• consider constraints from production, operation, service, and decommissioning,
• verify that architecture and requirements fulfill the respective ASIL.

The TSC is therefore not only a requirements appendix. It is the technical justification for why a system solution can control the functional safety objectives.

System-Level Positioning

The TSC sits between the concept phase and detailed hardware and software development. It takes the safety goals and FSR from the concept phase and turns them into technical requirements, architecture decisions, and evidence at system level.

Typical inputs are:

• the Functional Safety Concept according to ISO 26262-3,
• a preliminary system architecture,
• the item definition,
• where relevant, safety requirements from other systems.

Typical outputs and work products are:

• Technical Safety Requirements (TSR),
• the Technical Safety Concept itself,
• a system architecture specification,
• a hardware-software interface specification (HSI),
• safety analyses and verification reports.

A standard-compliant TSC includes four core elements in particular. First, TSR refine FSR into technical measures, such as stimulus-response behavior, timing limits, and operating modes. Second, the system architecture allocates these TSR to system elements, interfaces, redundancies, and partitions. Third, safety mechanisms describe how faults are detected, controlled, and how latent faults are prevented. Fourth, the ASIL is carried forward and, where used, ASIL decomposition is justified at system level according to ISO 26262-9.

FSC and TSC: What Level and How Level

The separation between FSC and TSC is a central structuring principle in ISO 26262. It deliberately separates the safety intent from the technical implementation and thereby creates traceability, variant flexibility, and auditability.

Perspective	Functional Safety Concept (FSC)	Technical Safety Concept (TSC)
Key question	What must the system do to be safe?	How is this safe behavior technically realized?
ISO part	ISO 26262-3, concept phase	ISO 26262-4, product development at system level
Abstraction	functional, technology-neutral	technical, architecture-related
Result	Functional Safety Requirements (FSR)	Technical Safety Requirements (TSR) and system architecture

The FSC describes the required safety-relevant system behavior independently of concrete technical solutions. It starts from safety goals derived from the HARA and defines functional behavior in a fault case: fault detection, fault reaction, safe state, degradation, and timing reactions, but without technical details.

The TSC describes how this behavior is technically achieved. This is where system elements, interfaces, diagnostic and safety mechanisms, redundancies, plausibility checks, and where applicable ASIL decomposition are named explicitly.

A simplified example shows the difference:

FSR:

• If an inconsistent steering angle signal is detected, the system shall transition into a safe state within 100 ms.

TSR:

• Two independent steering angle signals shall be evaluated cyclically.
• A plausibility check with at least x Hz shall detect inconsistencies.
• If a fault is detected, steering torque shall be limited to at most y within the required time.

This separation prevents architecture decisions from being fixed too early. It supports variant and supplier separation, keeps the safety case argument stable, and makes requirements reviewable.

Technical Safety Requirements

Technical Safety Requirements translate FSR into concrete technical requirements for system elements and interfaces. They are the first step where functional safety intent becomes technical system responsibility.

High-quality TSR are:

• technically precise, for example with stimulus-response behavior, timing limits, and thresholds,
• clearly allocatable to system elements such as ECU, sensor, actuator, or communication,
• verifiable at system level,
• ASIL-consistent, including propagation from the FSR and justified decomposition only in the TSC.

Typical contents of TSR are requirements for diagnosis, reaction and safe state, timing and performance limits, operating and fault states including transitions, and communication requirements such as timeouts, alive counters, or plausibility rules.

A TSR can look like this:

In case of inconsistent steering angle signals, the plausibility check shall be performed cyclically with at least x Hz and trigger a steering torque limitation to at most y within 100 ms.

This means a Functional Safety Requirement is not implemented directly. It is first transformed into a technical system requirement. That requirement can then drive architecture, HSI, hardware safety requirements, and software safety requirements.

System Architecture

The system architecture shows how TSR can be realized in the system. It is the link between requirements and later implementation.

In the TSC, architecture describes in particular:

• the structure of system elements, such as sensors, actuators, ECUs, and buses,
• interfaces and data flows, such as signals, messages, and dependencies,
• partitioning and independence as prerequisites for ASIL decomposition,
• redundancies and diversity, functional or technical,
• operating modes such as normal operation, degradation, and emergency operation.

The architecture must justify why the selected solution is suitable to fulfill the TSR under ASIL constraints. A redundancy is therefore not safety-effective just because it appears in a diagram. It must be allocated correctly, sufficiently independent, suitable in timing, and verifiable.

Interfaces are especially critical. Many safety findings do not arise in a single element, but between elements: unclear signal responsibility, missing timeout rules, implicit assumptions about data quality, or an HSI specification that only indirectly reflects safety requirements.

Safety Mechanisms in the TSC

Safety mechanisms are the concrete technical means by which safety-relevant faults are detected, controlled, or limited in their effect. In the TSC, they must be derived from TSR, allocated to architecture and system elements, and later verified in an ASIL-consistent way.

Typical mechanisms are:

• fault detection, such as plausibility checks, monitoring, and watchdogs,
• fault control, such as switchover, limitation, or shutdown,
• fault avoidance, such as redundancy, partitioning, and diversity,
• prevention of latent faults, such as self-tests and background diagnostics.

For each mechanism, at least trigger criteria, reaction logic, safe state, timing behavior, effectiveness, and placement in the system need to be defined. The central question is: Which element detects which fault, within which time, with which diagnostic coverage, and which reaction is triggered deterministically?

TSR define the requirements. The architecture shows the technical structure. The mechanisms provide the concrete implementation. Together, they form the technical core of the safety argument.

Diagnostics, Degradation, and Fallback

Diagnostics, degradation, and fallback interact in a coordinated way in the TSC. Diagnostics detect faults, degradation controls them in a restricted but safe mode, and fallback limits the risk when safe function can no longer be maintained.

Diagnostics are used for early and reliable detection of faults. This includes random hardware faults, systematic faults, and communication faults. Typical diagnostic mechanisms include plausibility checks, redundancy comparisons, timing supervision, self-tests, watchdogs, and end-to-end monitoring.

A diagnostic requirement needs to clarify at least:

• what counts as a fault,
• which detection time is acceptable,
• how diagnostic effectiveness is justified,
• which system element detects the fault.

Degradation maintains a restricted but safe function when part of the functionality fails. It avoids unnecessary complete shutdowns and improves controllable availability. Typical measures are limitation of actuating variables, reduced operating modes, simplified control strategies, or use of remaining redundant channels.

Robust degradation requires defined entry conditions, clearly described degradation levels, a deterministic transition, permitted return conditions, and verification of safety effectiveness during degraded operation.

Fallback applies when degradation is no longer sufficient or safety goals otherwise cannot be met. Forms include fail safe, meaning transition into a safe state, and fail operational, meaning continued safety-relevant operation despite a fault. Typical fallback actions are shutdown of actuators, transition into emergency operation, handover to the driver or an external system, and activation of mechanical safeguards.

For fallback, a clearly defined safe state, deterministic trigger path, defined reaction time, and consistent warning or information strategy are decisive.

TSC Verification

Verification of the TSC demonstrates that TSR have been derived correctly, the system architecture is suitable, and the safety mechanisms are effective. It is a central building block of the safety case because it turns technical claims into reviewable evidence.

First, derivation and completeness need to be shown. Every FSR from the FSC must be fully covered by at least one TSR. At the same time, no TSR should exist without an FSR reference. ASIL propagation and, where applicable, ASIL decomposition must be justified in a traceable way. Typical evidence includes traceability matrices from safety goal through FSR to TSR, review records, and decomposition evidence.

For TSR, it must be shown that they are unambiguous, technically feasible, ASIL-consistent, and verifiable at system level. Suitable methods include system tests, stimulus-response scenarios, timing and performance analyses, and reviews for structuring requirements.

For architecture, it must be shown that it enables implementation of all TSR, ensures required independence, consistently defines redundancies, partitioning, and interfaces, and contains no unjustified single points of failure in safety-relevant paths. Typical evidence includes architecture descriptions, architecture reviews, system-level safety analyses such as FTA, and HSI specifications.

For safety mechanisms, it must be evidenced that faults are detected reliably, reactions are deterministic, safety goals remain fulfilled in the fault case, and prioritization from diagnostics through degradation to fallback is correct. Fault injection tests, transition scenarios, and coverage arguments are central evidence here.

Timing behavior must also be correct. Detection and reaction times must remain within the required limits, and architecture as well as communication must support these limits deterministically. Consistency reviews and impact analyses finally check whether TSC, FSC, architecture, TSR, and further system requirements are free of contradictions and whether assumptions from the FSC have been preserved.

Handover to Hardware and Software Development

The transition from the TSC into hardware and software development is the formal handover from system level to implementation level. The objective is to transform all TSR completely, unambiguously, and ASIL-consistently into hardware safety requirements and software safety requirements.

This handover is a high-risk point for safety findings when traceability or abstraction levels are not maintained cleanly. Typical questions are: Which parts of a TSR belong in hardware? Which parts belong in software? Which responsibility sits in the HSI? And where is the required timing behavior actually ensured?

From TSR, the following are derived:

• hardware safety requirements according to ISO 26262-5,
• software safety requirements according to ISO 26262-6,
• clear allocation to hardware elements, software elements, and interfaces.

A TSR can read as follows:

• If a sensor signal loss is detected, the system shall limit steering torque to a safe value within 100 ms.

This can lead to HSR:

• The sensor interface shall detect an interruption within x ms.
• The actuator output stage shall enable safe limitation.

And SSR:

• The software component shall cyclically monitor sensor values.
• The torque limitation shall be triggered within the required time window.

The ASIL of the TSR is inherited by HSR and SSR. Further ASIL decomposition is possible, but must be explicitly justified through independence and effectiveness. Hardware architectures need to support diagnostics and safety mechanisms, avoid undetected single points of failure or justify them, and provide the basis for quantitative analyses such as FMEDA. Software architectures need to support a clear safety architecture, partitioning, independence of safety-relevant functions, and deterministic timing behavior.

Typical handover pitfalls are implementing TSR directly without deriving HSR or SSR, leaving HW/SW responsibility implicit, letting safety mechanisms “disappear” into software, failing to carry over timing assumptions, or ending traceability at system level. The practical rule is correspondingly strict: no implementation without an explicit hardware or software safety requirement.

What a High-Quality TSC Contributes in a Project

A TSC reduces technical interpretation before hardware and software development move deeply into implementation. It shows which FSR drive which TSR, which system elements are responsible, which mechanisms are expected to work, and how this effectiveness will later be evidenced.

For reviews and assessments, a short checklist can help:

• Is every FSR fully covered by TSR?
• Are TSR technically precise, allocatable, and verifiable?
• Is the system architecture justified as a safety solution?
• Are diagnostics, degradation, and fallback specified unambiguously?
• Are ASIL propagation and decomposition traceable?
• Are timing assumptions consistent across TSR, architecture, HSI, HSR, and SSR?
• Is bidirectional traceability established through tests and evidence?
• Are verification methods and evidence clearly allocated?

This makes the TSC more than a handover artifact. It stabilizes system development, supports supplier alignment, and creates a robust evidence line for the safety case.

Conclusion

The Technical Safety Concept translates Functional Safety Requirements into a technical system solution. It connects Technical Safety Requirements, system architecture, safety mechanisms, ASIL handling, and verification into a traceable ISO 26262-4 work product.

Its quality determines whether the transition from concept phase into hardware and software development is controlled. Clear TSR, justified architecture, defined mechanisms, consistent traceability, and robust verification prevent safety from being interpreted only during implementation.

In project reality, the TSC is often the point where it becomes clear whether the safety concept is technically robust. The earlier requirements, architecture decisions, mechanisms, and evidence are reviewed together, the more stable implementation, safety case, and later release decision become.