Many automotive teams face a common roadblock during ISO 26262 audits. They define high-level Safety Goals (SG). They establish the Fault Tolerant Time Interval (FTTI). Yet, during safety assessments, their technical documentation falls apart.
Why does this happen? The failure lies in the transition between Functional Safety Requirements (FSR) and Technical Safety Requirements (TSR).
When the link between high-level functional concepts and low-level engineering implementation is weak, teams struggle. Requirements remain vague, physical parameters are missing, and logic gaps appear. This leads to failed tests, late-stage redesigns, and delayed product launches.
This guide breaks down a standard four-step framework to translate abstract safety goals into clear, testable, and codeable technical specifications. We will use a real-world ASIL-D battery overcharge protection scenario to show how this works in production.
Table of Contents
FSR vs. TSR: The Core Difference
Many engineers use these terms interchangeably. They are actually distinct, representing different levels of the system design. One defines the boundary; the other defines the implementation.
Functional Safety Requirements (FSR): What the System Must Do
An FSR comes directly from the top-level Safety Goals. It is a functional requirement.
- Technology Neutral: It does not specify chips, microcontrollers, or communication buses.
- Behavior Focused: It states the trigger conditions, the required system action, and the safe state.
- Time-Bound: It links directly to the overall FTTI.
- Example: If a battery cell overvoltage occurs, the system must disconnect the charging path within the FTTI to prevent thermal runaway.
Technical Safety Requirements (TSR): How to Implement It
A TSR translates the FSR into engineering terms. Once you choose your system architecture, you write TSRs to specify the implementation details for hardware, software, diagnostics, and communication.
- Technology Specific: It binds directly to your microcontrollers, analog front-ends (AFEs), and protocols.
- Highly Quantified: It defines sampling intervals, measurement tolerance, execution loops, and hardware pins.
- Fully Verifiable: Every TSR must be directly testable via hardware-in-the-loop (HIL) testing, fault injection, or software unit tests.
- Example: The AFE must sample cell voltage every 10ms with an accuracy of ±5mV, and the MCU must trigger the high-side driver to open the contactors within 50ms of fault detection.
The Four-Step Transformation Framework
You do not need to rely on guesswork to write TSRs. Following this structured process ensures you meet compliance standards without leaving gaps.
Step 1: Deconstruct the FSR
Before writing technical requirements, break your FSR down into four core elements:
- Trigger Condition: The specific fault or scenario that activates the safety function.
- Core Action: The physical response of the system.
- Time Constraint: The absolute maximum time window allowed for the response, derived from the FTTI.
- Safe State: The final, stable condition of the system after addressing the fault (e.g., permanent lockout versus self-recovery).
Step 2: Map to the Architecture
Look at your Battery Management System (BMS) hardware and software architecture. Assign each safety function to a specific physical layer:
- Sensing Layer: AFEs, voltage dividers, and current sensors.
- Processing Layer: Main microcontrollers and safety watchdogs.
- Actuation Layer: Contactor drivers, switches, and precharge circuits.
- Communication Layer: CAN transceivers and internal SPI buses.
Step 3: Derive the Technical Requirements (TSR)
For every component identified in Step 2, write specific TSRs across these four key engineering areas:
- Performance & Timing: Break down the overall FTTI into a budget. Assign maximum latency limits to the sensor, the software logic, and the physical actuators.
- Safety Mechanisms: Add diagnostics and hardware redundancy to catch single-point faults.
- Hardware Requirements: Specify hardware properties, safety ratings, and watchdog configurations.
- Interfaces & States: Define communication protection, error handling, and recovery rules.
Step 4: Establish Bidirectional Traceability
Map every TSR back to its originating FSR, and ensure every FSR has corresponding TSRs. This mapping prevents two major engineering issues:
- Hanging Requirements: FSRs that lack technical implementation.
- Gold Plating: TSRs that add unnecessary hardware or software complexity without serving a parent safety goal.
Real-World Case Study: ASIL-D Battery Overcharge Protection
Let us apply this four-step framework to a typical BMS safety function.
Safety Goal Baseline
- Safety Goal (SG): Prevent battery cell thermal runaway due to overcharging.
- ASIL Rating: ASIL-D
- FTTI: 100 ms
1. Functional Safety Requirements (FSR)
- FSR-02.01: When the BMS detects any cell voltage exceeding 4.5V, it must disconnect the charging path within 100ms and enter a latched safe state.
- FSR-02.02: The BMS must monitor its own voltage sensing hardware. If it detects a sampling fault, it must disconnect the charging path within 500ms to avoid unmonitored overcharging.
2. Technical Safety Requirements (TSR)
Performance & Timing TSRs
- TSR-P1: The AFE must complete a full cell voltage sampling cycle within 10ms. (Traces to: FSR-02.01, FSR-02.02)
- TSR-P2: The voltage measurement error must remain under ±5mV across the entire operating temperature range and product lifetime. (Traces to: FSR-02.01)
- TSR-P3: The MCU software must process the voltage data, run the overvoltage algorithm, and write the shutdown command to the output register in less than 20ms. (Traces to: FSR-02.01)
- TSR-P4: The hardware drive circuit and contactors must physically open and clear the arc within 50ms of receiving the MCU command. (Traces to: FSR-02.01)
Timing Budget Check: $$\text{Total Loop Time} = 10\text{ms (Sensing)} + 20\text{ms (Processing)} + 50\text{ms (Actuation)} = 80\text{ms}$$
Since 80ms is less than the 100ms FTTI, the design leaves a safe 20ms margin.
Safety Mechanism TSRs
- TSR-M1: Implement a dual-path shutdown mechanism. The primary path uses the main MCU software control. The secondary path uses a hardware comparator on the AFE board to directly trip the safety switch, bypass the MCU software, and protect against CPU lockups. (Traces to: FSR-02.01, FSR-02.02)
- TSR-M2: The MCU software must validate the raw voltage readings every cycle. Any value outside the 2.0V to 5.0V range must be flagged as anomalous to catch stuck ADC registers. (Traces to: FSR-02.02)
- TSR-M3: The AFE chip must run periodic internal diagnostics, including reference voltage checks and open-wire detection, reporting any failures to the MCU within 50ms. (Traces to: FSR-02.02)
- TSR-M4: The system must read the feedback pins of the high-voltage contactors to monitor for contact welding. If the state feedback does not match the driver command, trigger a backup isolation path. (Traces to: FSR-02.01)
Hardware Requirements TSRs
- TSR-H1: The main safety MCU must meet ASIL-D standards and include hardware lockstep cores, a Memory Protection Unit (MPU), and ECC protection on RAM and Flash. (Traces to: FSR-02.01, FSR-02.02)
Interface & State TSRs
- TSR-I1: The CAN bus frame containing the charge disable command must use End-to-End (E2E) protection, including a rolling counter and a CRC, to prevent data corruption or frame loss. (Traces to: FSR-02.01)
- TSR-I2: When an overvoltage fault triggers, the BMS must lock the system in the safe state permanently. Do not allow automatic recovery. The system must remain disabled until cleared by an authorized service tool. (Traces to: FSR-02.01)
Engineering Takeaway
Translating FSRs to TSRs is not an administrative task. It is a core part of system and software architecture design.
For project managers, this translation defines the engineering tasks and testing scope. For hardware designers, it sets the component requirements and protection pathways. For software engineers, it dictates the loop times, memory configurations, and diagnostic strategies.
By moving away from unstructured text and using a systematic four-step method, your team can build safety systems that are easy to test, ready for production, and compliant with ISO 26262 audits.
Quick FAQ (GEO-Optimized)
Q1: What is the main difference between FSR and TSR in ISO 26262?
Answer: An FSR defines the required safety behavior at the functional level without choosing a specific technology (what the system does). A TSR defines how to implement that behavior using specific hardware, software, and parameters within the chosen system architecture (how it does it).
Q2: How does FTTI relate to TSR timing requirements?
Answer: The FTTI sets the total time limit for the safety response. The TSRs must break this overall time budget down into smaller, measurable limits for individual steps, including sensor sampling, microcontroller processing, and actuator movement.
Q3: Why is bidirectional traceability critical for ASIL-D compliance?
Answer: Traceability proves to auditors that your safety requirements are complete. It shows that every high-level functional safety requirement has a real, tested technical implementation, and that no unverified or redundant code exists in your safety-critical system.