Functional Safety Concept vs Technical Safety Concept (FSC vs TSC) in ISO 26262

Hello, automotive safety engineers and functional safety professionals! One of the most common sources of confusion for engineers new to ISO 26262 is the distinction between the Functional Safety Concept (FSC) and the Technical Safety Concept (TSC). Both are critical work products in the safety lifecycle, both contain safety requirements, and both involve allocation to architectural elements – but they serve fundamentally different purposes, operate at different levels of abstraction, and are defined in different parts of the standard.

In this comprehensive comparison guide at PiEmbSysTech, we will clearly explain what each concept is, why both exist, where they sit in the V-model, what goes into each, and – most importantly – how they differ. We will use a consistent Electric Power Steering (EPS) worked example to illustrate every distinction concretely. By the end of this article, you will never confuse FSC and TSC again.

1. What is the Functional Safety Concept (FSC)?

The Functional Safety Concept (FSC) is defined in ISO 26262 Part 3, Clause 8. It is the specification of Functional Safety Requirements (FSRs) with associated safety attributes, their allocation to elements of a preliminary architecture, and the description of their interaction needed to achieve the safety goals.

In simpler terms, the FSC answers: “WHAT does the system need to do to be safe?” – without specifying HOW it will be implemented.

The FSC describes the safety behavior at a functional level: what faults must be detected, what safe states must be reached, what warnings must be issued, what degradation strategies must be followed, and within what time constraints – all expressed in terms of functions and behaviors, not in terms of specific hardware components or software modules. The FSC operates on a preliminary (tentative) architecture that identifies the major functional blocks and their interactions, but does not yet commit to specific technology choices.

2. What is the Technical Safety Concept (TSC)?

The Technical Safety Concept (TSC) is defined in ISO 26262 Part 4, Clause 7. It is the specification of Technical Safety Requirements (TSRs) and their allocation to specific hardware and software elements of the system architectural design, describing how the functional safety requirements are implemented in the actual system design.

In simpler terms, the TSC answers: “HOW will the system implement safety – using which specific hardware, software, and interfaces?”

The TSC operates on the system architectural design – the detailed architecture that identifies specific ECUs, microcontrollers, sensors, actuators, communication buses (CAN, CAN FD, SPI, etc.), software components, and their concrete interfaces. The TSC transforms the abstract functional safety requirements of the FSC into concrete, implementable technical requirements allocated to real hardware and software elements.

3. FSC and TSC in the V-Model – Different Levels of Abstraction

In the ISO 26262 V-model, the FSC and TSC occupy distinct positions on the left side (specification side) of the V:

FSC (Part 3 – Concept Phase): Sits at the very top of the V, immediately after the HARA. It operates at the vehicle level and addresses the safety goals through functional requirements allocated to a preliminary architecture. The FSC is implementation-independent – it does not commit to specific technology choices.

TSC (Part 4 – System Level): Sits one level below the FSC on the V. It refines the FSC by transforming functional requirements into technical requirements and allocating them to the actual system design. The TSC is implementation-aware – it specifies concrete hardware and software solutions.

The verification counterparts on the right side of the V are correspondingly: Safety Validation (verifying the FSC against the safety goals at the vehicle level) and System Integration Testing (verifying the TSC against the FSRs at the system level).

4. Functional Safety Requirements (FSR) Explained

An FSR (Functional Safety Requirement) is a specification of implementation-independent safety behavior or safety measure. FSRs are derived directly from the safety goals and describe what the system must do to prevent or mitigate each identified hazard. Each FSR inherits the ASIL of the safety goal it addresses.

According to ISO 26262 Part 3 Clause 8, FSRs must address the following seven aspects:

1. Fault detection and indication: How will faults that could violate the safety goal be detected? (e.g., “The EPS shall detect loss of torque sensor signal.”)

2. Transition to safe state: How will the system reach the defined safe state? (e.g., “Upon detection of a torque sensor fault, the EPS shall transition to the safe state of no electric assist within the FTTI.”)

3. Fault tolerance (if needed): Can the system continue operating (in a degraded mode) after a fault, rather than immediately shutting down? (e.g., “The EPS shall maintain reduced assist for 2 seconds to allow the driver to adapt before transitioning to no assist.”)

4. Driver warning: How will the driver be informed of a safety-relevant fault or degraded mode? (e.g., “The EPS shall request illumination of a steering warning indicator on the instrument cluster.”)

5. Degradation strategy: What reduced functionality will the system provide after fault detection? (e.g., “In the degraded state, the EPS shall provide reduced assist torque limited to 50% of normal.”)

6. Timing constraints (FTTI-derived): Within what time must fault detection and transition to the safe state occur? (e.g., “The EPS shall detect the fault and reach the safe state within 50 ms.”)

7. Driver actions and assumptions: What actions are expected from the driver during or after fault handling? (e.g., “The driver is expected to adapt to increased steering effort within 2 seconds of the warning.”)

5. Technical Safety Requirements (TSR) Explained

A TSR (Technical Safety Requirement) is the implementation-specific refinement of an FSR. TSRs specify HOW the functional safety behavior will be achieved using specific hardware and software elements, communication interfaces, and safety mechanisms. TSRs are derived from the FSRs and the system architectural design.

TSRs are characteristically more detailed and technology-specific than FSRs. They specify concrete hardware elements (e.g., “The primary microcontroller (MCU-A) shall monitor…”), specific communication protocols (e.g., “The torque sensor signal shall be transmitted via SPI with CRC-8 protection”), quantitative parameters (e.g., “The watchdog timer shall trigger a reset if the main task does not service it within 5 ms”), and specific safety mechanisms with their implementation details.

TSRs also address the Hardware-Software Interface (HSI) – defining which hardware resources the software will use for safety functions, which hardware signals the software must monitor, and what diagnostic coverage the hardware safety mechanisms must achieve.

6. FSR vs TSR – The Key Differences

Aspect	FSR (Functional Safety Requirement)	TSR (Technical Safety Requirement)
Abstraction level	Implementation-independent (WHAT)	Implementation-specific (HOW)
Derived from	Safety goals	FSRs + system architectural design
Allocated to	Preliminary architecture elements (functional blocks)	System design elements (specific HW/SW components)
Technology references	None (no CAN, SPI, MCU references)	Explicit (CAN, SPI, MCU-A, MOSFET, ADC)
Example	“The EPS shall detect loss of torque sensor signal within 10 ms”	“MCU-A shall monitor SPI communication with the torque sensor ASIC; if 3 consecutive SPI frames fail CRC check, MCU-A shall set the torque_sensor_fault flag within 6 ms”
Standard reference	ISO 26262 Part 3, Clause 8	ISO 26262 Part 4, Clause 7

7. FSC Architecture – The Preliminary (Tentative) Architecture

The FSC is developed against a preliminary architecture (also called “tentative architecture” in some translations). This architecture describes the system in terms of functional blocks and their interactions – without specifying the implementation technology. For an EPS system, the preliminary architecture might show functional blocks such as “Torque Sensing Function,” “Vehicle Speed Interface Function,” “Assist Torque Calculation Function,” “Motor Drive Function,” “Fault Monitoring Function,” and “Driver Warning Function.” These are described in terms of their safety-relevant inputs, outputs, and behaviors.

The preliminary architecture is sufficient to allocate FSRs to functional blocks and to describe the interactions between them needed to achieve the safety goals. It does not specify whether the assist torque calculation runs on a specific MCU, or whether the motor drive function uses a specific H-bridge IC, or whether the vehicle speed is received via CAN or LIN.

8. TSC Architecture – The System Architectural Design

The TSC is developed against the system architectural design – the concrete system design that specifies actual hardware components (specific microcontrollers, sensor ICs, power stage ICs, connector types), software components (application software, basic software, safety middleware), and communication interfaces (CAN bus messages, SPI protocols, analog signals). For an EPS system, the system architectural design would specify “Infineon TC3xx MCU running AUTOSAR-based application software, communicating with the steering torque sensor ASIC via SPI, driving a 3-phase BLDC motor through a DRV8323 gate driver IC, receiving vehicle speed via CAN bus message 0x1A0.”

The system architectural design must demonstrate that it can implement all the FSRs from the FSC. Each FSR must be traceable to one or more TSRs, and each TSR must be allocated to specific hardware and/or software elements.

9. The Master Comparison Table – FSC vs TSC

Dimension	Functional Safety Concept (FSC)	Technical Safety Concept (TSC)
ISO 26262 Part	Part 3 – Concept Phase	Part 4 – System Level Development
Clause	Part 3, Clause 8	Part 4, Clauses 6 & 7
Core question answered	WHAT must the system do to be safe?	HOW will the system implement safety?
Requirements type	Functional Safety Requirements (FSR)	Technical Safety Requirements (TSR)
Derived from	Safety goals (from HARA)	FSRs + system architectural design
Architecture	Preliminary (tentative) – functional blocks	System architectural design – specific HW/SW elements
Implementation awareness	Implementation-independent	Implementation-specific
Technology references	None	MCU, CAN, SPI, MOSFET, ADC, etc.
Safety mechanism detail	Conceptual (e.g., “redundant monitoring”)	Concrete (e.g., “secondary MCU-B cross-checks torque via independent ADC”)
Safety analysis methods	Qualitative FTA/FMEA	Quantitative FMEA/FMEDA/FTA + hardware metrics
HW metric targets	Not yet specified (budgets may be estimated)	SPFM, LFM, PMHF budgets allocated to elements
HSI specification	Not addressed	Defined as part of TSC
Typically performed by	OEM or system-level Tier-1	System-level Tier-1 or component supplier
Verified against	Safety goals	FSRs and FSC
Validation counterpart	Safety Validation (vehicle level)	System Integration Testing

10. Worked Example – EPS Functional Safety Concept

Let us trace from the safety goal through the FSC for our EPS example. Starting with Safety Goal SG-01: “The EPS shall not apply unintended steering torque” (ASIL D), the FSC derives the following FSRs (simplified):

FSR-01: The EPS shall monitor the commanded assist torque for plausibility. [ASIL D]

FSR-02: If unintended torque is detected, the EPS shall transition to the safe state (no electric assist) within the FTTI of 50 ms. [ASIL D]

FSR-03: The EPS shall provide a gradual torque reduction (not an abrupt cut-off) during the transition to the safe state. [ASIL C]

FSR-04: The EPS shall request a steering warning to the driver within 200 ms of fault detection. [ASIL B]

FSR-05: The torque monitoring function shall be independent of the torque command function, such that a single fault cannot disable both the command and the monitoring. [ASIL D]

Note that these FSRs describe WHAT the system must do, without specifying which MCU runs the monitoring, which communication bus carries the torque command, or what specific IC drives the motor. They are allocated to functional blocks in the preliminary architecture: “Torque Command Function,” “Torque Monitoring Function,” “Motor Drive Function,” and “Driver Warning Function.”

11. Worked Example – EPS Technical Safety Concept

The TSC refines each FSR into concrete TSRs allocated to specific hardware and software elements:

From FSR-01 (torque plausibility monitoring):

TSR-01a: The primary MCU (TC397) shall compute the commanded assist torque from the primary torque sensor channel via SPI (16-bit ADC, CRC-8 protected). [ASIL D(D)]

TSR-01b: The secondary MCU (TC375) shall independently compute expected torque from the redundant torque sensor channel via a separate SPI bus. [ASIL D(D)]

TSR-01c: The secondary MCU shall compare its computed torque with the primary MCU’s commanded torque (received via dedicated SPI cross-check interface). If the difference exceeds ±2 Nm for more than 3 consecutive 2 ms cycles (6 ms), TSR-01c shall assert the torque_plausibility_fault signal. [ASIL D(D)]

From FSR-02 (safe state transition within 50 ms):

TSR-02a: Upon assertion of torque_plausibility_fault, the primary MCU shall command motor current to zero through the DRV8323 gate driver within 10 ms. [ASIL D]

TSR-02b: The safety switch (relay K1, controlled by secondary MCU) shall disconnect the motor phase outputs within 30 ms if the primary MCU fails to de-energize the motor. [ASIL D]

From FSR-05 (independence of monitoring):

TSR-05a: The primary MCU (TC397) and secondary MCU (TC375) shall have independent power supplies, independent clock sources, and independent torque sensor channels. [ASIL D]

TSR-05b: The SPI cross-check interface between MCU-A and MCU-B shall use CRC-16 protection and alive counter. [ASIL D]

Note the contrast: the TSRs name specific components (TC397, TC375, DRV8323, relay K1), specific communication protocols (SPI with CRC), specific timing values (2 ms cycle, 6 ms detection), and specific electrical interfaces. This is the “HOW” that transforms the abstract FSR “WHAT” into an implementable design.

12. How FSC Flows into TSC – The Refinement Process

The flow from FSC to TSC is a process of refinement and allocation:

Step 1 – Receive FSRs and preliminary architecture: The TSC development team receives the FSC work products – the FSRs with their ASIL assignments, the preliminary architecture, and the safety goal attributes (safe state, FTTI).

Step 2 – Develop the system architectural design: Based on the FSRs and non-safety functional requirements, the system architecture is designed with specific hardware and software elements. Technology choices are made (MCU selection, sensor technology, communication protocols).

Step 3 – Derive TSRs from FSRs: Each FSR is refined into one or more TSRs that specify how the functional requirement will be achieved in the actual design. New TSRs may be added for implementation-specific safety mechanisms not foreseen at the FSC level (such as memory protection unit configuration, watchdog implementation, or end-to-end communication protection).

Step 4 – Allocate TSRs to HW/SW elements: Each TSR is allocated to specific hardware elements, software elements, or hardware-software interactions.

Step 5 – Specify the HSI: The Hardware-Software Interface specification defines the boundary between hardware and software for safety-relevant functions.

Step 6 – Verify TSC against FSC: Perform safety analysis (system FMEA, FTA) to verify that the TSC achieves all the FSRs. Ensure complete traceability from each FSR to the TSRs that implement it.

13. Safety Mechanisms in FSC vs TSC

Safety mechanisms appear in both the FSC and the TSC, but at different levels of detail:

Safety Mechanism	FSC Level (Conceptual)	TSC Level (Implementation)
Redundant monitoring	“An independent monitoring function shall cross-check the commanded torque”	“Secondary MCU (TC375) shall compare torque via independent SPI channel with CRC-16; threshold ±2 Nm; 3-cycle persistence filter”
Safe state switch-off	“The motor drive shall be de-energized upon fault detection”	“Primary path: DRV8323 gate driver inhibit via MCU-A GPIO; backup path: safety relay K1 controlled by MCU-B”
Communication protection	“Vehicle speed input shall be protected against data corruption”	“CAN message 0x1A0 shall use E2E Profile 1 (CRC + alive counter); timeout 50 ms; substitution value = last valid speed for 200 ms then 0”
Driver warning	“A warning shall be provided to the driver upon fault detection”	“CAN diagnostic message DTC_EPS_Fault (0x7FF) shall be sent to instrument cluster ECU; amber warning lamp GPIO on pin 34 shall be asserted within 100 ms”

14. Safety Analyses – Qualitative (FSC) vs Quantitative (TSC)

ISO 26262 prescribes different safety analysis methods for the FSC and TSC levels:

At the FSC level (Part 3): Qualitative safety analyses are used to verify that the FSC achieves the safety goals. Qualitative FMEA identifies potential failure modes at the functional block level and verifies that the FSRs address them. Qualitative FTA decomposes each safety goal violation into its contributing failure combinations to verify that the FSC covers all relevant fault paths. These analyses are performed on the preliminary architecture.

At the TSC level (Part 4): Both qualitative and quantitative analyses are performed. System-level FMEA analyzes failure modes of the actual hardware and software elements. FTA is refined with the actual design information. Additionally, the TSC initiates the quantitative hardware safety evaluation that continues into Part 5 – including SPFM, LFM, and PMHF calculations, hardware metric budget allocation to system elements, and Dependent Failure Analysis (DFA) to verify independence claims.

15. The Role of the Hardware-Software Interface (HSI)

The Hardware-Software Interface (HSI) specification is a TSC-level work product (Part 4, Clause 8) – it does not exist at the FSC level. The HSI defines the boundary between hardware and software for safety-relevant functions, including which hardware registers and I/O pins the safety software must access, which hardware diagnostic features (ECC, memory protection, watchdog) the software must configure and monitor, which hardware signals the software uses as inputs for safety mechanisms, and what timing and sequencing constraints exist at the HW/SW boundary.

The HSI is critical because it is the specification that enables hardware development (Part 5) and software development (Part 6) to proceed in parallel while ensuring that both sides have a consistent understanding of the safety-relevant interface between them.

16. Handling Discrepancies Between FSC and TSC

During TSC development, it is common to discover that the system architectural design introduces new functional blocks, interfaces, or behaviors that were not foreseen in the FSC preliminary architecture. ISO 26262 Part 4 Clause 6 requires that such discrepancies be handled through iteration: if the TSC reveals new functionality that is not traceable to the FSC, or if the system design introduces new potential failure modes not addressed by the FSRs, the development team must go back to the FSC (and potentially to the HARA and item definition) and update them.

This iterative process is sometimes called the “safety mirror” – the TSC architecture should be a more detailed reflection of the FSC architecture, and discrepancies between the two must be resolved through updates to one or both. The key rule is: the FSC architecture must be consistent with the TSC architecture at the appropriate level of granularity. Details added at the TSC level are expected, but new functional blocks or significantly changed interactions require FSC updates.

17. OEM vs Supplier Responsibilities for FSC and TSC

In the automotive supply chain, the FSC and TSC are typically developed at different organizational levels:

FSC (typically OEM or system-level Tier-1): The FSC is developed by the organization that has vehicle-level context – typically the OEM or the system-level Tier-1 supplier who is responsible for the complete item (e.g., the complete EPS system). The FSC requires vehicle-level knowledge to correctly formulate FSRs that address the safety goals from the HARA.

TSC (typically Tier-1 or component supplier): The TSC is developed by the organization that designs the actual system – typically the Tier-1 supplier who selects the hardware, designs the PCB, and develops the software. The TSC requires detailed knowledge of the available hardware components, their failure modes, and the software architecture.

The interface between these organizations is managed through the Development Interface Agreement (DIA), defined in Part 8. The DIA specifies which organization is responsible for each work product, how the FSC is communicated from OEM to supplier, and how discrepancies between FSC and TSC are resolved.

18. Common Mistakes and How to Avoid Them

Mistake 1: Including technology-specific details in the FSC. If your FSR says “The MCU shall monitor the CAN message for timeout,” it is too detailed – it belongs in the TSC as a TSR. The FSR should say “The vehicle speed input shall be monitored for availability.” Keep the FSC technology-free.

Mistake 2: Skipping the FSC and going directly to TSC. Some teams attempt to write TSRs directly from safety goals, bypassing the FSC entirely. This violates ISO 26262 Part 3 requirements and, more practically, results in a TSC that is overly tied to a specific implementation. If the hardware platform changes, the entire safety concept must be re-derived from scratch instead of just updating the TSC.

Mistake 3: Not maintaining traceability between FSR and TSR. Every TSR must trace back to one or more FSRs. Every FSR must be covered by at least one TSR. Gaps in this traceability mean either a safety requirement is not implemented (dangerous) or a technical requirement has no safety justification (unnecessary).

Mistake 4: Treating the FSC and TSC as static documents. Both concepts evolve as the design matures. When the TSC reveals design constraints that affect the FSC (such as the need for a new safety mechanism not foreseen in the FSC), the FSC must be updated. The iteration loop between FSC and TSC is normal and expected.

Mistake 5: Copying the FSC system architectural design into the TSC unchanged. The TSC architecture must be more detailed than the FSC architecture. If they are identical, either the FSC is too detailed or the TSC is too abstract. The TSC must show specific HW/SW elements, not just functional blocks.

Mistake 6: Not aligning the ASIL of derived TSRs. TSRs inherit the ASIL of the FSRs they implement. New TSRs introduced at the TSC level (for implementation-specific safety mechanisms) must also be assigned an appropriate ASIL. Failing to propagate ASILs to TSRs creates gaps in the safety case.

19. Frequently Asked Questions

Q1: Can the FSC and TSC be combined into a single document?

While ISO 26262 defines them as separate work products in separate parts (Part 3 and Part 4), some organizations combine them into a single “safety concept document” with clearly separated sections. This is acceptable as long as the distinction between FSRs and TSRs is maintained, traceability is preserved, and the review and verification activities for each level are performed separately.

Q2: What if the TSC reveals that an FSR is not achievable?

This is a legitimate engineering scenario – for example, the TSC team may discover that the FTTI cannot be met with the available hardware. In this case, the issue must be escalated back to the FSC level, and potentially to the HARA, to reassess the safety concept. The solution might involve changing the safe state, adjusting the FTTI, modifying the degradation strategy, or selecting different hardware.

Q3: Does the FSC include hardware metric targets?

No. Hardware metric targets (SPFM, LFM, PMHF) are specified at the TSC and Part 5 level, not at the FSC level. The FSC may reference the ASIL-level metric targets from Part 5 as a constraint, but the actual metric budget allocation to system elements is a TSC/Part 5 activity.

Q4: Who approves the FSC and TSC?

Both the FSC and TSC are subject to verification reviews as defined in Part 2. The independence level of the review depends on the ASIL. For ASIL D, independent assessment (I2 or I3) is recommended for both the FSC and TSC. The safety manager is typically responsible for approving these work products.

Q5: Does the TSC include software safety requirements?

The TSC allocates TSRs to both hardware and software elements. The software-allocated TSRs become the starting point for the software safety requirements specification in Part 6. Similarly, the hardware-allocated TSRs become the starting point for the hardware safety requirements specification in Part 5. The HSI specification bridges the two.

20. Conclusion

The distinction between the Functional Safety Concept (FSC) and the Technical Safety Concept (TSC) is one of the most important structural concepts in ISO 26262. The FSC defines WHAT the system must do to be safe – expressed as implementation-independent Functional Safety Requirements allocated to a preliminary architecture. The TSC defines HOW the system will implement safety – expressed as implementation-specific Technical Safety Requirements allocated to actual hardware and software elements in the system architectural design.

Both concepts are essential, both are required by the standard, and both must be maintained in alignment throughout the development lifecycle. The FSC provides stability and reusability (it can survive hardware platform changes), while the TSC provides the concrete, implementable specification that hardware and software teams need to build the actual system. Together, they form the bridge between the abstract safety goals from HARA and the detailed hardware/software implementation that delivers safety in the final product.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. For the foundational coverage of the FSC, see Part 3 – Concept Phase. For the TSC, see Part 4 – System-Level Development.

Stay safe. Stay structured. Keep engineering the future.

– The PiEmbSysTech Team