What Is a Functional Safety Concept?
The Functional Safety Concept (FSC) is the document—or more accurately, the structured model—that connects what can go wrong with what the system must do about it. In the ISO 26262 framework, the FSC sits between hazard analysis and risk assessment (HARA) and the technical safety concept that governs hardware and software design. It takes the safety goals produced by HARA and converts them into functional safety requirements: specific, allocated, verifiable obligations on system behavior.
Without the FSC, safety goals remain abstract. With a poorly built FSC, they become traceable in appearance but empty in substance. The FSC is where functional safety engineering either earns its credibility or quietly fails.
The Role of the FSC in ISO 26262 Part 3
ISO 26262 is structured in layers. Part 3 covers the concept phase of system-level development. It defines three mandatory work products: the item definition, the HARA, and the Functional Safety Concept. The FSC is the output of Clause 8 and the direct input to Part 4 (system-level technical safety concept) and beyond.
The HARA produces safety goals. Each safety goal carries an Automotive Safety Integrity Level (ASIL)—A through D, or QM—based on the combination of severity, exposure, and controllability assessed for each hazardous event. These ASILs tell you how rigorously a failure must be prevented or controlled. They do not tell you how.
The FSC answers the how—at the functional level, before architecture decisions are made.
What “Functional Level” Means
Functional safety requirements in the FSC describe what a system function must do or refrain from doing to support a safety goal. They are technology-independent: no specific microcontrollers, no named sensors, no software partitions. A functional safety requirement might read: “The braking function shall detect loss of hydraulic pressure within 50 milliseconds and request activation of the redundant braking path.” It says nothing about which ECU hosts this logic or which bus carries the message. That is intentional. Architectural decisions come later.
This abstraction matters. If you write functional safety requirements that already assume a specific architecture, you constrain your design before you have evaluated whether that architecture is the safest option.
How Safety Goals Become Functional Safety Requirements
The transformation from safety goal to functional safety requirement involves three steps, each of which can be done well or poorly.
Step 1: Decompose the safety goal into failure modes. A safety goal like “avoid unintended acceleration” contains multiple failure modes: unintended torque request, failure to detect driver intent, failure to limit torque after fault detection. Each failure mode becomes a candidate for a functional safety requirement.
Step 2: Define the safety mechanism in functional terms. For each failure mode, the FSC specifies what functional behavior prevents or mitigates the hazard. This is the safety mechanism—described functionally. “The torque management function shall monitor commanded torque against driver-requested torque and suppress output if the delta exceeds X Nm for more than Y ms.” This is a functional safety requirement.
Step 3: Assign the ASIL. The safety goal carries an ASIL. If a single functional safety requirement is solely responsible for achieving the safety goal, it inherits that ASIL in full. If ASIL decomposition is applied—splitting a goal across two independent functions to reduce individual ASIL—the FSC must document that decomposition explicitly, including the independence argument.
Each of these steps requires rigor. Each is a place where weak FSCs fail.
How the FSC Allocates Safety Mechanisms to System Elements
Allocation is one of the least-understood functions of the FSC. Many teams write functional safety requirements but stop short of allocating them to system elements. This creates a gap: the requirements exist, but no one owns them.
System elements at the FSC stage are defined at the functional architecture level—braking system, powertrain control, gateway, HMI. Allocation means each functional safety requirement is assigned to one or more of these elements, with clarity about which element is responsible for detection, which for reaction, and which for confirmation.
If a safety mechanism requires coordination between two system elements (for example, a sensor reporting a fault and an actuator responding to it), the FSC must define both obligations and the interface between them. This is where the FSC becomes the foundation for hardware-software interface (HSI) requirements later in the process.
Poor allocation—requirements assigned to “the system” or “TBD”—means hardware engineers have no clear mandate. During hardware design review, reviewers cannot verify that a safety mechanism is implemented if no one specified where it should live.
What a Weak FSC Looks Like
A weak FSC is recognizable. Its failure patterns are consistent across projects.
Vague safety mechanism language. Requirements that say a function shall “detect faults” or “respond appropriately” provide no testable criteria. They cannot be verified. They cannot be allocated with confidence.
Untraced safety goals. A safety goal that does not appear in any functional safety requirement is a gap. It may have been forgotten, it may have been assumed covered, or it may have been deferred. None of these are acceptable in a Part 3 artifact intended for compliance.
Undocumented ASIL decomposition. Decomposition without an independence argument is a regulatory and technical problem. The FSC must show why the two elements satisfying a decomposed ASIL are sufficiently independent—in terms of common cause, common location, and shared failure modes.
Missing allocation. Functional safety requirements with no named owner cannot be traced to hardware or software design. Hardware design reviews cannot verify them. Auditors will flag them. More importantly, they may simply not be implemented.
No defined safe states. For each failure mode, the FSC should define what the system’s safe state is—limp mode, controlled shutdown, driver warning—and how the system transitions to it. A functional safety requirement without a defined safe state endpoint is incomplete.
The consequences appear downstream. In hardware design review, reviewers check that the hardware architecture implements the safety mechanisms defined in the FSC. If the FSC is vague, the review becomes a negotiation about intent rather than a verification of compliance. ASILs assigned to hardware components cannot be justified if the functional requirements that drove those assignments are ambiguous.
Practical Implications for Systems Engineers
The FSC is not a document to write once and archive. It is a living model that feeds every subsequent artifact in the functional safety lifecycle. Changes to the FSC propagate to the technical safety concept, to hardware and software safety requirements, to the verification plan, and to the safety case.
This is why the FSC demands a model-based or at minimum a structured, linked approach. A requirements document in a word processor may satisfy the form of the FSC, but it will not support the change management and traceability that make the FSC useful.
The most important discipline in FSC development is bidirectional traceability. Every functional safety requirement must trace back to a safety goal. Every safety goal must trace forward to at least one functional safety requirement. Gaps in either direction are nonconformances under ISO 26262 Part 3 Clause 8.
If you cannot run a coverage query that shows all safety goals and their associated requirements—and all requirements and their source safety goals—you do not have a compliant FSC. You have a document.
How Modern Tools Support FSC Development
Word processors and spreadsheets have been used to produce FSCs for years. They can technically produce the right artifacts. The problem is that they do not enforce the relationships that make the FSC valuable. A safety goal can exist without any downstream requirements. A requirement can reference a safety goal that has been modified. ASIL decomposition arguments can be written in prose that no automated check can evaluate.
Requirements management tools vary in how well they support FSC development. IBM DOORS and DOORS Next provide mature traceability infrastructure, and DOORS has been used in automotive safety projects for decades. Jama Connect offers review and collaboration workflows that work well for cross-functional teams. Polarion and Codebeamer both provide process templates that include FSC-relevant workflows, and Codebeamer’s AUTOSAR-awareness makes it useful for teams already inside that ecosystem.
Where these tools differ—and where the FSC development process exposes that difference—is in how they handle the semantic structure of requirements. Traditional requirements management tools store requirements as text objects with attributes. Relationships between requirements are explicit links, but the meaning of those links (this requirement satisfies this safety goal, this decomposition depends on this independence argument) is stored in attributes and naming conventions that vary across teams and projects.
Flow Engineering takes a graph-based approach. Requirements, safety goals, system elements, and architectural decisions are nodes in a connected model, not rows in a database with foreign keys. This matters for FSC development because the FSC is inherently relational: a safety goal exists in relation to a hazardous event, a functional safety requirement exists in relation to a safety goal, a safety mechanism exists in relation to a system element. When those relationships are first-class model elements rather than attribute conventions, the FSC becomes queryable in ways that word-processor-based artifacts cannot match.
In practice, Flow Engineering users can define a safety goal from a HARA output, attach an ASIL, and immediately create child nodes representing functional safety requirements. Each requirement node carries an allocation link to a system element. ASIL decomposition is modeled as a structured relationship with an independence argument attached—not a prose paragraph somewhere in a document section.
The forward trace from FSC to architectural design decisions is particularly useful during hardware design review. When a hardware architect needs to verify that the braking system ECU implements the safety mechanisms allocated to it in the FSC, the trace is navigable: safety goal → functional safety requirement → system element allocation → hardware design decision. The chain does not require manual cross-referencing between documents.
Flow Engineering is deliberately focused on this kind of systems engineering work. It does not attempt to replicate the full lifecycle management features of tools like Polarion or Codebeamer, and teams that need deep PLM integration or legacy DOORS migration workflows will need to evaluate that scope separately. The tradeoff is depth of model-based support for exactly the kind of structured safety reasoning the FSC demands.
Where to Start
If you are building a Functional Safety Concept and want to avoid the patterns that create problems in hardware design review, start with four commitments:
1. Trace every safety goal bidirectionally. Before writing a single functional safety requirement, map your safety goals to your hazardous events and define coverage criteria. If you have ten safety goals, you need to be able to show that all ten have at least one downstream requirement when the FSC is complete.
2. Write requirements to a testable standard. Every functional safety requirement should answer: what detects the fault, what responds to it, in what time, with what safe state outcome. If you cannot write a verification method against the requirement, rewrite the requirement.
3. Allocate explicitly. Assign every requirement to a named system element. “TBD” is a deferred nonconformance.
4. Document decomposition arguments. Every ASIL decomposition needs an independence argument with specific claims about why the two satisfying elements cannot fail from a common cause. This argument will be challenged in assessment.
The Functional Safety Concept is the most consequential artifact in the concept phase. It determines whether your safety goals are realized or merely stated. Getting it right at Part 3 is far less expensive than finding the gaps at Part 5.