Hierarchy of Functions
And why that's relevant for FuSa
2025-11-18 13 min Season 1 Episode 10
Description & Show Notes
Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. Today we'll be talking about hierarchies of functions. What this is about, and why this topic is so enormously important for functional safety... You'll find out shortly.
Transcript
Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. Today we'll be talking about hierarchies of functions. What this is about, and why this topic is so enormously important for functional safety... You'll find out shortly.
Functions are generally not implemented in isolation. They have interfaces to other functions and influence each other during execution. As we will see later, this is particularly relevant for the increasingly complex ADAS functions, since interfaces of this kind are especially common in that domain. Each function typically has not just a single malfunction, but a whole range of them—often with more than one being safety-relevant. And for each safety-relevant malfunction, a functional safety concept must be developed and implemented. It’s easy to imagine how complex the situation can become when multiple safety-relevant functions each present more than one safety-relevant malfunction, and a separate safety concept must be implemented for each. Oh dear… And as if that weren’t complicated enough, all these safety concepts must not be implemented independently of one another. Otherwise, inconsistencies may arise that could, in the end, pose an unnecessary risk of safety goal violations. A tricky situation… so what can be done? As is often the case in functional safety, the problem is not actually complicated, but rather complex. Yet it is precisely in this high level of complexity that the risk of losing track lies. However, one thing we must never forget: in the end, we are dealing with potential harm to people—so losing oversight is simply not an option! In this episode, we want to explore a specific aspect that plays a particularly important role in the parallel development of safety concepts—especially when it comes to maintaining oversight and ensuring the safety of at-risk individuals despite all the complexity. It’s about the hierarchy of functions. It’s about how the function hierarchy can influence the safety concepts of individual malfunctions. It’s about how the hierarchy of functions can affect the verification and validation of safety concepts—and what we can do to avoid creating chaos.
Again and again, one hears statements like, “Yes, but then we’re violating the safety goal!” or “We haven’t received the safety goals from the customer yet!” Surprisingly, such objections are raised regardless of the specific product for which a safety concept is being developed. But does it actually make sense to ask for safety goals when developing a radar or camera sensor for an ADAS function? Do teams working on ADAS software really need the safety goals? If you take a close look at the architecture of the functions, a hierarchy becomes visible—one that provides a clear answer to this very important question: No! Safety goals are only relevant for those functions that can directly trigger a hazard. Example: An engine control unit directly manages the injection of fuel into the combustion chamber of the engine. Too much or too little fuel injection will therefore immediately result in excessive or insufficient acceleration. In contrast, an ACC (Adaptive Cruise Control) function can also trigger acceleration—but not directly. Typically, the function can only place a request on the communication bus, which is then read and evaluated by the engine control unit. If defined criteria are met (such as the plausibility of the request), the engine control unit will initiate the requested acceleration. Thus, the ACC function can only indirectly cause incorrect acceleration, since its role is not to accelerate, but to send a corresponding request. Therefore, the ACC function cannot violate a safety goal. Safety goals like “avoid erroneous acceleration” do not need to be considered by teams developing an ACC function. At most, they may be helpful for general understanding. For function development, only the functional safety concept is relevant—one that also does not refer to the safety goals but instead focuses on the safety-relevant malfunctions of the ACC function itself.
Let’s now consider a series of functions and how they are interconnected. This example is intended to illustrate how important it is from a functional safety perspective to take into account the aforementioned hierarchies of functions. A plausible hazard is when the vehicle suddenly steers to the left or right. Steering, like braking and accelerating, is one of the fundamental vehicle functions whose malfunction can pose an immediate danger to people. Therefore, erroneous steering is rightfully considered a hazard, and a corresponding hazard analysis and risk assessment (HARA) must be performed. The outcome of this analysis includes the ASIL assigned to the hazard, the safety concept, and one or more safety goals. The safety concept defines how the vehicle must behave in order to adequately mitigate the risk arising from incorrect steering. (See also the episode “Hazard Analysis and Risk Assessment.”) Since the function “steering” directly influences the vehicle’s behavior, as mentioned, and because the vehicle itself must be considered the system providing this function, we refer to it as a base function. A base function means that it does not rely on other functions to control the vehicle’s behavior. Additional base functions include: Acceleration, braking, raising and lowering windows, opening and closing doors, ensuring sufficient forward visibility. In addition to the base functions, there is a large number of other functions that can also influence vehicle behavior—but only by utilizing the base functions. The reason is obvious: direct control of the vehicle must not be possible for multiple functions at the same time. One example has already been discussed: the ACC function can merely place an acceleration request on the communication bus (“send it to the vehicle”), but it cannot perform acceleration by itself. Steering is often implemented by the so-called Steering Control Unit, or “SCU.” It is very important to distinguish between steering as a vehicle function and the corresponding function of the SCU. “Steering” as a base function is provided by the vehicle system. Within the “vehicle” system, there exists the subsystem “SCU,” which reads steering requests from the communication bus and—through its mechanical linkage to the actual steering mechanism—activates the vehicle’s base steering function. Thus, the SCU provides a first-level function, which consists of processing the steering requests present on the bus and activating the mechanical steering accordingly. The function “lane keep assist” is designed to keep the vehicle within the lane it is currently driving in by actively intervening in the steering. To do this, the function evaluates information about the vehicle’s current position within the lane. These data are provided to the “lane keep assist” function by another function called “object fusion.” For example, if the vehicle approaches the edge of the lane due to a curve, “lane keep assist” sends corrective steering requests over the communication bus to the “SCU” function, which then actuates the steering accordingly. The “object fusion” function, in turn, processes data provided by camera sensors and combines this information with road course data, which is extracted from stored map data in conjunction with the vehicle’s current GPS data. Regarding the hierarchy of functions, the “lane keep assist” function is a second-level function, while the “object fusion” function is accordingly a third-level function. The sensor data that describe the vehicle’s current position relative to the lane represent a fourth-level function.
What significance does the hierarchy of functions have for the development of the “safety concepts”? Well, the hierarchy arises from the interfaces through which the functions exchange data. Every function requires input signals to provide the necessary output signals. This is the core of every function. It would be a mistake to try to implement the “safety concept” for a “hazardous event” within a function that is not a base function. Doing so would create a high risk of inconsistent “safety concepts.” Safety concepts must be absolutely consistent and exclusively related to the safety-relevant malfunctions of a function, as illustrated by the example of “lane keep assist.” Although “lane keep assist” can ultimately cause erroneous steering, it does not make sense to try to assign the functional “safety concept” defined for the malfunction “erroneous steering” of the base function Steering, as a result of the corresponding “hazard analysis and risk assessment,” to the “lane keep assist” function. Requirements such as “fault tolerant time interval,” “safe state,” maximum FIT-rate, or “emergency operation” would be assigned to the “lane keep assist” function and would have to be implemented accordingly. However, these requirements most likely would not sufficiently reduce the risk that “lane keep assist” sends a wrong steering command on the communication bus. Furthermore, this approach would completely ignore how such a failure would propagate through the vehicle architecture. The functional safety requirements for “lane keep assist” could thus be inappropriate, ultimately making the system unnecessarily expensive. The “safe state” of the base function Steering is generally not suitable for functions like “lane keep assist.” A typical “safe state” for ADAS functions might be “stop communication,” whereas the “safe state” for the Steering function would more likely involve restoring correct steering or vehicle position within a defined, usually very short, time frame or—if that is not possible—bringing the vehicle safely to a stop. This example once again highlights how important it is to define a separate, malfunction-specific “safety concept” for every safety-relevant malfunction of each function. If this is not done in a project, it is highly advisable to work towards making this happen. The efficiency of the “safety concepts” will be significantly increased, also from a business case perspective. Moreover, with regard to the complexity mentioned at the beginning, well-formulated “safety concepts” reduce the risk of losing overall oversight and ultimately even reduce the risk of safety goal violations.
Finally, it should be mentioned that functional “safety concepts” that are cleanly linked to the specific malfunctions of a given function greatly improve reusability. This not only reduces development costs for future projects but also lowers the inherent risk associated with developing “safety concepts” from scratch. Validated “safety concepts” should always be preferred over newly developed ones. Well-defined “safety concepts” have an advantage that is sometimes underestimated or even overlooked. Since today’s E-E-systems often implement multiple functions, each frequently having more than one safety-relevant malfunction, a large number of implemented “safety concepts” must be validated for consistency with each other. Both the validation effort and the risk of overlooking inconsistencies due to poorly specified “safety concepts” can be drastically reduced by the measures described here. This aspect should also motivate us to invest the additional effort that well-formulated “safety concepts,” taking into account the hierarchy of functions, may require. In the end, it is always about the safety of our end customers—that is, people who are at risk in road traffic due to possible malfunctions of our products.
Applied FuSa – a podcast for Functional Safety pragmatists. Get your new piece of FuSa every other week.
Expert
00:00:18
Moderator
00:12:30