Functional Safety Concept (FSC)

From Safety Goal to Functional Safety Requirement

After the HARA, the safety goals and ASIL classifications are defined. But this does not yet describe which behavior an item must show in a fault case. This is where it becomes clear whether a risk evaluation turns into a robust requirements set or whether system development starts with ambiguous input.

The functional safety concept, or FSC, is a central work product of the concept phase according to ISO 26262-3. It describes how the safety goals derived from the HARA are to be fulfilled at item level. At this stage, the focus is not yet on ECUs, sensor paths, software tasks, or concrete redundancies. The FSC describes which safe or degraded behavior is required so that unreasonable risk is avoided.

At its core, the FSC answers three questions: Which safety goals must be fulfilled at functional level? Which functional safety requirements refine these safety goals? And which assumptions, reactions, timing constraints, and evidence are needed so that the requirements can later be implemented cleanly at technical level?

What the Functional Safety Concept Provides

The FSC bridges abstract safety goals and later technical implementation at system, hardware, and software level. It is created based on the item definition and the HARA and deliberately remains technology-neutral. This solution neutrality matters because the concept first defines the required safety behavior, not the concrete architecture.

The core statement is simple: the functional safety concept describes what a system must functionally do to fulfill its safety goals, not how this behavior is technically implemented.

This leads to four central tasks:

• refine safety goals into verifiable functional safety requirements,
• ensure traceability from HARA through safety goals to FSR,
• create the input for the technical safety concept according to ISO 26262-4,
• provide a robust evidence line for the safety case.

The documented functional safety concept is therefore more than a list of requirements. It must make clear why the functional requirements are complete, ASIL-consistent, verifiable, and traceable to the original safety goals.

Safety Goals and Functional Safety Requirements

Safety goals are the top-level safety objectives. They are derived from the HARA and describe what must be prevented or limited from a safety perspective in order to avoid unreasonable risk. They are hazard- and scenario-oriented, formulated at item level, classified with an ASIL, and intentionally abstract.

A simplified safety goal can look like this:

SG 01: Unintended acceleration of the vehicle must be prevented. ASIL D.

A functional safety requirement, or FSR, is the functional refinement of a safety goal. It describes which functional behavior the system must show in order to fulfill the respective safety goal. One safety goal is typically decomposed into several FSRs.

The relationship between safety goal and FSR is:

• hierarchical: one safety goal sits above several FSRs,
• refining: “What must not happen?” becomes “Which functions ensure that it does not happen?”,
• complete and necessary: every safety goal must be covered by at least one FSR, and every FSR must be clearly assigned to a safety goal,
• ASIL-consistent: the ASIL of the safety goal is carried forward to the related FSRs.

ASIL reduction is not the usual lever at this level. If ASIL decomposition is used later, it belongs in the technical architecture and system context and must be explicitly justified there.

Safety Goal	Functional Safety Requirement
describes the safety objective	describes the functional safety behavior
hazard-based	function- and reaction-based
abstract	concrete and verifiable
item level	system behavior without technical implementation

What an FSR Should Contain

A high-quality FSR does not only describe a broad intention. It defines at functional level under which conditions a fault must be detected, which reaction is required, and how the safe or degraded state is reached.

Typical contents of an FSR are:

• conditions for fault detection,
• required reaction in case of faults,
• transition into a safe or degraded state,
• allowed reaction times,
• requirements for warnings or driver information.

For the safety goal “unintended acceleration must be prevented”, several FSRs can be derived:

• FSR 01: The system shall provide plausibility monitoring for accelerator pedal signals.
• FSR 02: If an inconsistent accelerator pedal signal is detected, the torque shall be limited to a safe value within x ms.
• FSR 03: The driver shall be clearly warned when the fault occurs.

Together, these FSRs form the functional fulfillment of the safety goal. None of these requirements already explains which ECU, sensor path, or software architecture is used. This separation keeps the FSC at the right abstraction level.

How to Write a High-Quality FSR

An FSR is not only formally correct. It is methodically embedded in the ISO 26262 safety lifecycle. It enables evidence, architecture derivation, and auditability, and therefore becomes an important building block of the safety case.

For reviews, it helps to check each FSR against clear quality criteria:

• unambiguous: the requirement leaves no room for interpretation regarding trigger, reaction, or state,
• verifiable: it is clear how fulfillment can later be checked,
• ASIL-consistent: the ASIL and origin from the safety goal remain traceable,
• complete with respect to the safety goal: the relevant safety objective is not only partially addressed,
• necessary: the requirement is safety-relevant, not a general comfort or quality requirement,
• solution-neutral: the requirement describes functional behavior, not already the technical implementation,
• at the correct abstraction level: it is more concrete than the safety goal, but not yet hardware or software design,
• allocatable and traceable: origin and later refinement can be followed,
• consistent: it does not contradict other FSRs or assumptions from item definition or HARA,
• functionally testable: verification can be planned at functional level.

The abstraction level is often a point of discussion in projects. An FSR that is too abstract merely repeats the safety goal and does not help system development. An FSR that is too technical anticipates architecture decisions and moves content from the TSC into the concept phase. The robust middle ground is functionally concrete, but not implementation-bound.

Transition from FSC to TSC

The transition from the functional safety concept to the technical safety concept marks the step from the what level to the how level. Functional safety requirements become technical safety requirements, which can be implemented and evidenced in a concrete system architecture.

The purpose of this transition is to ensure that all FSRs are technically feasible, fully covered by system measures, and traceably carried forward at system, hardware, and software level.

Level	FSC	TSC
Focus	functional behavior	technical implementation
Key question	What must happen to be safe?	How is it technically achieved?
Artifacts	safety goals, FSR	TSR, system architecture
Abstraction	technology-neutral	architecture- and element-related

The TSC is where the technical system architecture is defined for the first time: system elements such as ECUs, sensors and actuators, communication paths, redundancies, and diagnostic chains. In this context, FSRs are allocated to technical system elements, ASIL requirements are carried forward, and safety mechanisms are systematically placed.

An example transformation can look like this:

FSR:

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

TSR:

• The ECU shall evaluate two independent steering angle signals.
• A plausibility check shall be performed cyclically with at least x Hz.
• If a fault is detected, the steering torque shall be limited to at most y.

An ISO 26262-compliant transition needs complete traceability, full coverage, consistency between function and technology, and evidence capability. The chain runs from hazard and safety goal through FSR and TSR to architecture, hardware and software requirements, and tests.

Typical FSC Pitfalls

Many weaknesses in the FSC only become visible later, when system architecture, supplier alignment, or verification is already underway. This is why an early methodical review is valuable.

The first typical pitfall is implicit assumptions. Requirements then depend on boundary conditions such as sensor signal quality, driver reactions, operating modes, or availability of external systems without documenting these assumptions. This is often visible in requirements that only work under an unspoken “if”. Such assumptions should be stated explicitly as boundary conditions, requirements, or validated premises.

The second pitfall is missing or unsuitable verification. An FSR exists, but it is unclear whether it will later be checked by test, analysis, or inspection. It becomes especially critical when functional requirements are only planned for verification at software or hardware level, although they should have been checked earlier at concept or system level.

The third pitfall is ASIL inconsistency. If an ASIL D safety goal leads to an ASIL D FSR, this must not silently turn into a weaker technical requirement without traceable justification. ASIL must be carried forward explicitly. Decomposition belongs in the technical context and requires documented independence and effectiveness.

The fourth pitfall is incomplete coverage of safety goals. A safety goal is then only partially addressed by FSRs. Fault transitions, degradation paths, or boundary conditions are often missing. A simple coverage matrix between safety goals and FSRs makes such gaps visible early.

The fifth pitfall is combined requirements. An FSR that bundles several triggers, reactions, and timing constraints in one sentence is difficult to verify unambiguously. A clearer rule is: one requirement, one behavior.

The sixth pitfall is missing traceability. Requirements may look technically plausible, but can no longer be traced back cleanly to hazard, safety goal, TSR, architecture, or test. For the safety case, this is a structural problem because the argument chain breaks.

The seventh pitfall is unspecified timing behavior. If a reaction is required but no reaction time or timing boundary is stated, the requirement remains incomplete. Timing constraints need to be described early enough so that they can later be analyzed, implemented, and verified.

What a High-Quality FSC Achieves in a Project

An FSC reduces uncertainty before technical architecture work begins. It shows which safety goals drive which functional requirements, which assumptions apply, and where later evidence will be needed. This turns the transition into the TSC from an interpretation exercise into a controlled refinement step.

For reviews and audits, a short checklist can help:

• Are assumptions explicitly documented?
• Is a verification method defined for each requirement?
• Is the abstraction level of the FSR correct?
• Is the ASIL carried forward consistently?
• Is safety goal coverage complete?
• Are states, triggers, and terms unambiguous?
• Is forward and backward traceability clean?
• Is relevant timing behavior specified?

This makes the FSC more than an intermediate document. It stabilizes requirements derivation, supports alignment between safety, systems engineering, and suppliers, and provides an important evidence line for the safety case.

Conclusion

The functional safety concept translates safety goals into verifiable functional safety requirements. It remains technology-neutral, but already describes concretely which safe or degraded behavior an item must show in order to fulfill the safety goals derived from the HARA.

Its quality determines whether the transition into the technical safety concept is controlled. Clear FSRs, consistent ASIL propagation, documented assumptions, defined verification, and clean traceability prevent later gaps in architecture, evidence, and safety case.

Especially in early project phases, a robust FSC may look unspectacular, but it is decisive. It creates technical order before solutions are fixed. The clearer this order is, the more stable the TSC, verification, and later release decision become.