Requirements Decomposition
2025-12-16 17 min Season 1 Episode 12
Description & Show Notes
Hello and welcome to another episode of “Applied FuSa,” a podcast for FuSa pragmatists.
Functions are often broken down into sub-functions. A typical reason for this is that it can be easier to implement sub-functions rather than the complete function.
This strategy is relevant to functional safety for two reasons:
1. Depending on how the function is broken down into sub-functions, the ASIL of the sub-functions may be reduced; and
2. The usually lower complexity of sub-functions not only reduces the validation effort but also the risk of failure.
In ISO 26262, this type of breakdown is referred to as requirements decomposition, provided the sub-functions meet certain criteria — for instance, complete independence. In this episode, we will present the exact requirements for such a requirements decomposition in detail, explore its benefits, and discuss its limitations.
Transcript
Hello and welcome to another episode of “Applied FuSa,” a podcast for FuSa pragmatists. Functions are often broken down into sub-functions. A typical reason for this is that it can be easier to implement sub-functions rather than the complete function. This strategy is relevant to functional safety for two reasons: 1. Depending on how the function is broken down into sub-functions, the ASIL of the sub-functions may be reduced; and 2. The usually lower complexity of sub-functions not only reduces the validation effort but also the risk of failure. In ISO 26262, this type of breakdown is referred to as requirements decomposition, provided the sub-functions meet certain criteria — for instance, complete independence. In this episode, we will present the exact requirements for such a requirements decomposition in detail, explore its benefits, and discuss its limitations.
A typical situation in which requirements decomposition is applied is the implementation of safety concepts for complex functions. Usually, safety analyses reveal the need for safety mechanisms to monitor signals for safety-relevant faults and to respond appropriately if such faults occur. In such cases, it often makes sense to implement the actual function and the safety mechanisms separately. Together, the function and safety mechanisms must fulfill the safety concept; the individual functions do not have to do so on their own. Therefore, higher failure risks can be accepted for the individual functions. In other words, the ASIL can be reduced, which can significantly decrease the development effort depending on the situation. Assuming the failure case of a complex function is rated as ASIL C. This means, abstractly speaking, that the malfunction poses a high risk and that a relatively large effort must be made to reduce this risk to an acceptable level. All requirements defined in ISO 26262 for ASIL C must be fulfilled. If the safety mechanisms, identified as necessary based on the safety analyses and possibly safety manuals, are considered as a separate function, then a lower ASIL can be assigned to both the function and the safety mechanisms. However, this applies only to the implementation and only according to clearly defined rules. The integration, on the other hand, must be carried out according to the original ASIL. This also applies when a function is decomposed into two subfunctions—not only for the combination of function and safety mechanisms. Since the differences are almost negligible, the term “decomposition of a function into subfunctions” will be used here in general. The few differences will be briefly mentioned at the appropriate place. What is the advantage of such a decomposition of functions into subfunctions? Application functions are often of such complexity that fulfilling all ISO 26262 requirements according to the assigned ASIL results in a high effort. The lower the ASIL, the lower the effort. Therefore, if a function can be decomposed into subfunctions, the effort will decrease if these subfunctions have lower complexity. It should be noted that additional interfaces may increase the effort again, but very often the overall effort can be significantly reduced. This is especially true when dealing with the combination of a complex function with usually less complex safety mechanisms. Safety mechanisms mostly consist of fault detection and reaction, and their complexity is often significantly lower than that of the actual function. As will be shown later, the ASIL can, for instance, be adjusted such that the complex function is assigned a very low ASIL, while the safety mechanism is assigned a significantly higher one. In extreme cases, the function can be developed according to QM, and the safety mechanism according to the original ASIL of the function. The main motivation, therefore, lies in reducing the ASIL relevant for implementation, thereby decreasing the overall effort and the risk of failure.
Let’s now turn to the rules according to which requirements decomposition must be performed. First of all: Why is it called requirements decomposition and not, for instance, function decomposition? The reason is quite simple: decomposing a function into subfunctions must start with the specification. Functional requirements for the function are used to derive functional requirements for the subfunctions. These requirements have the goal that, on the one hand, together they implement the desired function, and on the other hand, also cover the associated safety concept. As a reminder: For every safety-relevant fault, there must be a separate safety concept. However, safety concepts often cover multiple fault cases. Different strategies can be applied for decomposing a function into subfunctions, depending on the needs: 1. The function is extended by safety mechanisms. The function is assigned a lower ASIL, allowing tailoring of ISO 26262 requirements. This is where the reduction in implementation effort for the function lies. The safety mechanisms are also assigned an ASIL, which can be higher than the function’s ASIL; however, as mentioned, the complexity of the safety mechanisms is often significantly lower. 2. The function is decomposed into subfunctions with lower complexity. Each subfunction is assigned an ASIL that is often lower than the original ASIL. Thus, multiple functions must be implemented, but on the one hand, they have lower complexity, and on the other hand, a lower ASIL. Put simply, the responsibility is distributed across multiple shoulders. Instead of one function having to meet all relevant ISO 26262 requirements, the requirements are distributed among several functions. And by reducing the ASIL, some requirements can usually even be tailored. Now, to the concrete rules of decomposition. It is assumed that a function is to be decomposed into two functions. The allowable new ASILs are defined in ISO 26262, Part 9, Chapter 5. An ASIL D requirement can be decomposed into an ASIL C from D requirement and an ASIL A from D requirement. A brief note at this point: The expression “ASIL A from D,” or more generally “ASIL X from Y,” describes the new and the original ASIL. ASIL A from D means that the original requirement was assigned ASIL D, and the new (decomposed) requirement is assigned ASIL A. This represents a significant reduction in ASIL (from D to A). In general, ASIL X from Y means that an ASIL X requirement was derived by decomposition from an ASIL Y requirement. This will have an impact on integration, as will be shown shortly. Back to the rules of decomposition. An ASIL D requirement can also be split into two ASIL B from D requirements. A third allowed possibility is the derivation of a QM from D requirement and a D from D requirement. This means that one requirement retains the high ASIL, while the other requirement is assigned QM. This is the most extreme form of decomposition and is generally applied when a function is to be developed at ASIL D. In this case, the function is developed according to QM from D, while the safety mechanisms are developed according to ASIL D from D. To recall: their complexity is usually significantly lower, so the effort for development at ASIL D is accordingly much reduced. Another use case is when built-in safety mechanisms of microchips are configured via the Safety Manual to operate in ASIL D compliance. Then all safety-relevant failure cases that can occur within the chip are protected with ASIL D integrity, and the function itself, or the parts executed on the chip, can be developed according to QM from D. Similar rules exist for ASIL C, ASIL B, and ASIL A requirements. These are listed here for completeness without further explanation. An ASIL C requirement can be decomposed 1. into an ASIL B from C requirement and an ASIL A from C requirement, or 2. into an ASIL C from C requirement and an ASIL QM from C requirement. An ASIL B requirement can be decomposed 1. into two ASIL A from B requirements, or 2. into an ASIL B from B requirement and an ASIL QM from B requirement. An ASIL A requirement can only be decomposed into an ASIL A from A requirement and an ASIL QM from A requirement. That’s all about the rules governing how requirements may be decomposed. Here’s a very pragmatic and important tip: in the vast majority of cases, it’s much easier to start with the decomposition of functions rather than decomposing individual requirements. Usually, the goal isn’t to derive single requirements, but to implement a function through multiple functions so that the ASIL of the original function can be reduced for the reasons mentioned. The example of combining a function with safety mechanisms has already been given. Once the decomposition of a function is complete, you only need to assign the derived ASILs to the requirements of the derived functions. This is almost always much easier than decomposing individual requirements.
Finally, a very important topic: so-called inhomogeneous redundancy. The goal of decomposition, as described, is to reduce the ASIL for complex functions without increasing the overall risk. The risk must remain at least the same. It is now clear that this requirement cannot be met if the derived functions are not completely independent of each other. In other words: if a failure in one function can simultaneously cause the failure of the second, decomposed function, then the overall risk would increase, for the following reason. Suppose the original function has a safety-related fault condition for which a safety concept exists. By means of decomposition, two functions are derived whose ASIL is reduced. For both functions, a higher failure risk is accepted. However, the decomposition must be carried out in such a way that the safety-related fault condition can only occur if both derived functions fail simultaneously. Too complicated? Or explained too awkwardly? Here is a simple example. In addition to the actual function, safety mechanisms are implemented that are intended to detect certain functional errors and respond accordingly. This could, for instance, be an out-of-range or stuck-at-value fault of an internal signal. Error detection and reaction are performed by the safety mechanisms in such a way that the associated safety concept is fulfilled. This implies that the fault condition can only occur if, simultaneously with the signal fault, i.e., the functional fault, the safety mechanisms also fail and either do not detect the fault or respond incorrectly. In other words, a double fault is necessary for the original fault to occur. Now independence comes into play. If the function and the safety mechanisms are completely independent of each other, the overall probability of the failure case results from the combination of the individual failure probabilities. This allows a higher risk to be accepted for the individual failures without increasing the overall risk. However, if there is a dependency between the function and the safety mechanisms—for example, if a functional failure can directly cause a failure in the safety mechanism—the overall risk increases. In this case, a single failure immediately triggers a second failure, effectively causing a double failure. Since the decomposition and ASIL reduction accept a higher risk for the individual failures, this dependency means that the risk of the double failure—and thus of the original functional failure—increases overall. This contradicts the goal of the decomposition, which is not to increase the overall risk. It sounds very complicated, but actually it is not. Where before decomposition a single failure had to be mitigated, after decomposition at least two simultaneous failures must occur to trigger the safety-relevant fault. What sounds plausible and neat in theory is unfortunately not always easy to implement in reality. For instance, there are almost always so-called common causes affecting the derived functions, which means full independence is no longer given. However, common causes are not a problem for decomposition, because the same common cause without decomposition would have been a root cause for the single failure. So the overall risk is not increased. Nevertheless, it can happen that two derived functions are not completely independent. In such cases, one must either attempt to justify the increased risk or adjust the decomposition to achieve full independence. A remark on the common distinction between decomposition in terms of redundancy versus decomposition with safety mechanisms. ISO 26262 also differentiates between these two cases. But is this distinction really meaningful? A classic teaching example for redundancy used to be the purely hardware-based control of brake lights. Normally, the status of the brake pedal is evaluated by a control unit, and the brake lights are switched on or off depending on that status. If a fault is detected, the overall system can switch to a redundant solution, which is purely hardware-based. This bypasses the control unit so that the brake lights can still be activated. Is this now a safety mechanism, or is it functional redundancy? Fundamentally, this is actually irrelevant. Such so-called fallback solutions are activated in case of a fault. For this, fault detection must be implemented, which triggers the activation. The overall system must still fulfill the safety concept. It makes absolutely no difference whether one talks about redundancy or safety mechanisms. There is also the approach to understand safety mechanisms merely as fault detection and the activation of the fault reaction. Such a safety mechanism is, so to speak, connected in series with that redundancy, and should consequently be developed to the same ASIL as the decomposed redundancy.
That concludes the topic of requirements decomposition. In summary, new functions are derived from complex functions to reduce the ASIL of the new functions, which opens the possibility to develop with less effort and reduced risk without increasing the overall risk. Finally, an explanation of why it is so important to specify the original ASIL in the formulation ASIL X of Y. As already mentioned, the reduction of the ASIL does not apply to the integration of the derived functions. The reason is that integration is a single action. Single faults therefore contribute directly to the overall risk. Or, in other words: decomposition has no influence on integration, and therefore the ASIL for integration cannot be reduced. The same applies accordingly to the verification of the integrated system as well as to the calculation of hardware metrics (FMEDA). These are required starting at ASIL C and recommended for ASIL B. However, if the overall system is developed according to ASIL C or ASIL D, then decomposition must not lead to FMEDA no longer being performed due to the reduced ASIL. Otherwise, the FMEDA of the entire system could not be performed either, because the results regarding the hardware components of the decomposed function would be missing.
Applied FuSa – a podcast for Functional Safety pragmatists. Get your new piece of FuSa every other week.
Expert
00:00:58
Moderator
00:16:44