FSC vs TSC
Or: Function vs. System
2025-11-04 12 min Season 1 Episode 9
Description & Show Notes
The strict separation of functional and technical safety concepts is one of the most important principles in functional safety—and for good reason. This not only affects the scope of the two work products but also their respective responsibilities and the impact this separation has on the efficiency of safety concepts.
Transcript
Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. The strict separation of functional and technical safety concepts is one of the most important principles in functional safety—and for good reason. This not only affects the scope of the two work products but also their respective responsibilities and the impact this separation has on the efficiency of safety concepts.
The safety standard ISO 26262 distinguishes between the functional safety concept and the technical safety concept. So, what exactly is the difference? And why is this distinction important for the development of safety-related E-E systems? We’ll be answering these questions in today’s episode. In the episode “About Functions and Systems,” we will show that functions are provided by systems. In other words, systems implement functions. At the highest level, users expect certain functionality from a system. Here are some examples: When I turn on a vacuum cleaner, I expect the vacuum to clean the floor. When I press the “Espresso” button on my coffee machine, I expect an espresso to be poured into my cup. When I press the accelerator pedal in my car, I expect the car to accelerate. We want functions and buy systems that provide these functions. Sometimes, the specific system matters to us—for example, when we prefer a particular car brand. But primarily, it’s always about the function, and only secondarily—if at all—about the system. So, as users, we want a function, and we expect the system to provide that desired function on demand.
E-E systems also provide one or more functions, which can be requested by a user or by other E-E systems. A fault condition occurs whenever the output signals of the function have incorrect values. Possible reasons for this include: The system that is supposed to provide the function is not working correctly. Input signals or other data—such as calibration parameters—are faulty. In other words, the system processes incorrect signals and generates incorrect output values. How does a system work? Simply put, it reads input signals and processes them to generate output signals. The function specification describes the functional relationship between input and output signals—that is, which output signals should be generated for given input signals. If this relationship no longer holds—meaning the output signals no longer correspond correctly to the input signals—this is called a malfunction of the E-E-system. If the input signals themselves are faulty, then the error lies with the system that provides those input signals.
Functional faults become safety-relevant when they can lead to violations of safety goals. In such cases, a functional safety concept must be specified. A functional safety concept consists of requirements placed on the function, aimed at reducing the risk posed by a safety-relevant malfunction to an acceptable level. The risk associated with a safety-relevant malfunction is expressed through the ASIL (Automotive Safety Integrity Level). ASIL A represents a low risk, while ASIL D indicates a very high risk where survival is considered highly unlikely. Thus, the ASIL serves as an “attribute” of the malfunction. According to ISO 26262, a functional safety concept includes the following requirement: The Fault Tolerant Time Interval (FTTI) describes the maximum duration for which a safety-relevant malfunction is allowed to persist. This requirement takes into account the fact that malfunctions do not necessarily lead directly to a violation of a safety goal, as illustrated by the following example: A false positive braking event can destabilize vehicle dynamics. For this hazard, there is typically a safety goal such as “avoid unintended braking.” However, it must be noted that false positive braking of very short duration is unlikely to dangerously affect vehicle dynamics. In fact, braking errors lasting only briefly may not even be perceptible. The FTTI defines the maximum allowable duration of false braking and is designed so that, as long as the malfunction does not exceed this duration, the associated safety goal is not violated and the hazard is not caused. The “safe state” describes a state to which a system must transition if the fault cannot be resolved within the FTTI. This is intended to prevent the malfunction from persisting too long and violating the corresponding safety goals. Often, the safe state is defined as a response that informs the downstream system of the fault. This could be a message—such as an error flag—sent over the communication bus. Another possibility is to stop communication altogether, so the downstream system detects that something is wrong. This downstream system can then take action to prevent the impending violation of the safety goal. The “Maximum FIT rate” specifies how often a malfunction is allowed to occur within a time frame of one billion hours (10 to the 9 hours). One FIT means that the malfunction may occur only once in 10 to the 9 hours. This metric is necessary when calculating failure rates quantitatively for a system and applies exclusively to so-called “random hardware faults.” These are faults caused by hardware components failing, which can, for example, result from aging. “Emergency operation” defines a system response that should be triggered immediately upon detecting a fault to reduce risk right away. Typical reactions include shutting down other functions to reduce the microcontroller’s load. Another possible response is temporarily activating redundant systems while the faulty system attempts to identify and fix the root cause of the error. The “Warning and degradation concept” — as the name suggests — aims to warn the driver or other people at risk about the danger, as well as to deactivate other systems. For example, if a radar sensor has a critical fault and can no longer provide reliable object data used by the ADAS function Adaptive Cruise Control (ACC), the warning and degradation concept could involve informing the driver that ACC is no longer available while simultaneously deactivating the function. These are the five key requirements defined within a functional safety concept for a function’s specific malfunction, aimed at minimizing the risk arising from that malfunction.
Now, let’s move on to the technical safety concept. How does it actually differ from the functional safety concept? Starting from the knowledge that a specific malfunction is safety-relevant, all root causes for this malfunction must be identified. These root causes can either lie within the E-E system itself or stem from already faulty input signals. For each of these root causes, a concept must be developed that describes how to either avoid them, or how to detect them and react, appropriately. Avoidance means to sufficiently reduce the probability for a root cause to happen, while detection and reaction during runtime is formulated as system-level requirements and referred to as the technical safety concept. A typical example would be monitoring temperature and reacting to overtemperature or undertemperature conditions. It is called a technical safety concept because it consists of requirements directed at the system. In contrast, the previously explained functional safety concept describes requirements related to the malfunction itself—hence the term “functional” safety concept. Note: It is possible that for certain root causes, no safety concept needs to be defined if that root cause can be considered acceptable. This is usually only feasible when the probability that the root cause can trigger the functional fault is assessed as sufficiently low. In any case, a plausible justification must be well documented, as it will become a critical part of the safety case. A thorough assessor will pay particular attention to these arguments. Back to the topic… The main difference is that the functional safety concept addresses the malfunction itself, while the technical safety concept deals with the root causes within the system. And since a system represents the technical implementation of the function, requirements directed at the system are called “technical” requirements, whereas requirements aimed at the function are referred to as “functional” requirements.
There is another very important aspect of this distinction: the question of responsibility. While the functional safety concept represents an expectation of the function (more precisely, of the malfunction), the technical safety concept relates to the technical implementation of the function. The supplier of the system is responsible for the technical implementation. It’s essentially the supplier’s “cookbook,” the internal details of the product design. The function, on the other hand, is specified by the customer, who demands this function from the supplier’s system. Therefore, the customer must also define how the system should react to a safety-relevant fault. In summary: The customer is responsible for the functional safety concept because they expect the function. The supplier is responsible for the technical safety concept because they develop and deliver the system. This aspect is unfortunately often neglected. It is not uncommon for customers to define technical safety requirements for the supplier’s system, for example. This limits the supplier’s options regarding the technical solution for the functional safety concept. Furthermore, this can lead to inconsistencies between the functional and technical safety concepts if the customer does not ensure that their technical requirements are fully consistent with the functional safety concept. Suppliers should try to avoid such overlaps in responsibilities as much as possible. This unnecessarily complicates the interface between supplier and customer and increases the risk of flawed safety concepts, which ultimately is not only risky for the business case but, most importantly, also endangers the end users unnecessarily.
Applied FuSa – a podcast for Functional Safety pragmatists. Get your new piece of FuSa every other week.
Expert
00:00:28
Moderator
00:11:00