About Functions and Systems
2025-12-02 12 min Season 1 Episode 11
Description & Show Notes
Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists.
What’s actually the difference between functions and systems? And why is this relevant for functional safety at all? Is it enough to have requirements documents for either functions or systems, or are both always needed? Simple questions, with simple answers — but far-reaching consequences.
Transcript
Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. What’s actually the difference between functions and systems? And why is this relevant for functional safety at all? Is it enough to have requirements documents for either functions or systems, or are both always needed? Simple questions, with simple answers — but far-reaching consequences.
It might seem unnecessary to talk about the differences between functions and systems. And yet, these two terms are often mixed up — sometimes with significant consequences for functional safety. That’s why we want to take a closer look at this topic in today’s episode. At its core, there is a very simple relationship between systems and functions — and that’s where we’ll start. In general, we say that systems implement functions. Systems are the technical realizations provided by a supplier to deliver the functions desired by a customer. Systems read input signals in order to generate output signals. The causal relationship between those input and output signals is what we call the function. So far, so good. Up to this point, it’s all fairly straightforward. But now things start to get a bit more complex.
Input and output signals can be described either logically or technically. Let’s use a simple example to illustrate this: the interfaces of an electronic control unit (ECU) for a windshield wiper motor. The ECU primarily reads two signals: the state of the steering column stalk, which the driver uses to switch the wipers on and off, and the state of the ignition switch. The wipers should not be activated when the ignition is off (“off” state) or during engine start (“crank” state). The state of the wiper switch can be described logically using the values OFF, AUTO, SLOW, and FAST. These four values represent the typical, well-known states a wiper can have. Since the technical details — meaning the concrete technical implementation — are not the focus here, this is referred to as a logical or functional description (or specification). A technical description, on the other hand, depends on the actual implementation and must be agreed upon between the customer and the supplier. Typically, the customer defines the technical specification of the interface, since it is part of the system architecture into which the ECU is integrated — and the customer is responsible for that architecture. The supplier, in turn, develops the product in such a way that, within the constraints of the given interface, the desired function is implemented. In other words: the product must fulfill the customer’s functional requirements. As such, the supplier is responsible for all technical requirements — with one exception: the interface specifications, which, as mentioned, are usually defined by the customer. We’ll come back to the topic of responsibility for functions and systems later. For now, let’s focus on the technical specification of interfaces.
What might a technical specification for the interface between the ECU and the wiper switch look like? Let’s take a look at how it works. The wiper switch is essentially a multi-position switch whose position is changed by rotating or vertically moving the lever. A mechanical resistance must be overcome between positions, so that the new position is perceived as a distinct “click” or detent. Switches like the steering column stalk and similar components are supplied with voltage to determine their status (i.e., current position). After a brief delay — allowing for any power-on transients to settle — a current measurement is taken. Inside the switch, changing the position alters the total effective resistance. By measuring the current, the resistance can be determined, which in turn allows the ECU to infer the position of the switch. A technical description must reflect the actual functional behavior. Therefore, it does not consist of the logical, functional states OFF, AUTO, SLOW, and FAST, but rather of the corresponding current measurement results. In addition, the technical description includes measurement tolerances to ensure that fault conditions can be clearly identified. The technical specification describes the product on a technical level — that is, the concrete implementation of the required function, or the product design. As mentioned earlier, this design — with the exception of the interfaces — is the responsibility of the supplier. Conclusion: Interfaces can be described both logically and technically. The logical description is part of the functional specification commissioned by the customer. Input and output signals are described purely functionally, which ensures reusability due to their independence from the design. The technical description defines the concrete implementation of the interfaces and is typically also created by the customer, since it is determined by the architecture into which the supplier’s system is integrated.
So much for the description of interfaces using logical and technical specifications. But what does all this have to do with the topic of “functions and systems”? By now, it should be clear that this episode is based on the assumption that the customer is responsible for specifying the function — including the technical specification of the interfaces. The supplier, on the other hand, develops the ECU and is therefore responsible for the technical specification of the system — with the exception of the interfaces. This division is quite logical, as the customer usually has no reason to define specific technical requirements for the internal design, apart from the interfaces. As long as the product correctly implements the intended function, the internal details should not be of concern and typically remain the supplier’s intellectual property. Of course, reality often looks different… but from several perspectives, this separation of responsibilities makes a great deal of sense. First and foremost, the supplier should have maximum flexibility when developing their product. However, it must not be forgotten that the customer, in turn, is required to perform a risk assessment to ensure that the required function is available with sufficient reliability. This may lead to concrete technical requirements — for instance, regarding the choice of microcontroller. So yes, there are indeed cases where it makes sense for the customer to specify technical requirements for the implementation of the function that go beyond the interface definitions.
Sometimes, an error occurs at this point in the organization of requirements, which should be pointed out here. Customer requirements are usually classified as so-called stakeholder requirements, and according to the V-model, these are assigned to the “Sysdot 1” level. From these, “Sysdot 2” and later “Sysdot 3” requirements are derived, and so on. While functional requirements are located at the “Sysdot 1” level, the “Sysdot 2” and “Sysdot 3” levels represent the technical requirements for product design. If a customer specifies not only functional but also technical requirements, it must be ensured that these are not assigned to the Sysdot 1 level just because they come from the customer. These are technical requirements related to the design, and therefore they must be assigned to one of the lower levels – regardless of whether they come from the customer or not. If technical requirements are assigned to the Sysdot 1 level just because they are customer requirements, there is a risk that inconsistencies may arise in the requirement management process, which in the worst case can lead to faulty design. The chaos that results from this becomes fully apparent when it comes to defining test cases. It gets especially critical when developing functional or technical safety concepts. Even the creation of the safety case and the final functional safety assessment can involve unnecessarily high risks and costs if requirements are not assigned clearly and correctly to their respective levels. The importance of traceability is often underestimated. To the untrained eye, traceability might seem like nothing more than a mountain of documentation and administrative work around requirements—without making any meaningful contribution to the actual product design and, consequently, the business case. Far from it! And this brings us to an extremely important point!!
Full traceability is the key guarantee that it can even be verified whether all functional requirements have been completely and correctly implemented. This not only protects both supplier and customer from unpleasant—and potentially very costly—recalls, including the associated loss of image and prestige; ultimately, it also protects the end users from unacceptably high, sometimes even life-threatening risks. And that should be motivation enough to always ensure full traceability in its entirety.
Let’s summarize. We have learned that the main difference between function and system is that systems are the technical implementations of the required functions. We have established that, as a rule, the customer specifies the function because it is the function for which they hire the supplier. The customer wants to receive the product that provides the desired function. Since the ordered system is integrated into the customer’s architecture, the customer must define the internal interfaces for all architectural elements—both functionally and technically. For this reason, the customer is responsible for the technical specification of the interface related to the function for which they hire the supplier. For the supplier, the technical specification of the interface represents a constraint that must be taken into account when designing the product. A clear distinction between function and system—especially regarding their respective specifications—is absolutely essential. The reasons for this include unacceptably high risks that, among other things, can arise for the end user due to insufficient traceability. A couple of additional remarks: Of course, the supplier also has some influence on the specification of the interfaces, both on the functional and technical levels. For instance, it may turn out that additional input signals—previously not considered—are needed to implement the function. It’s also possible that the supplier, based on their experience, may want to propose changes to the technical specification. Ultimately, what matters most is that customer and supplier communicate openly, because the product should be a collaborative effort. And finally: what has been said so far mainly applies to E/E systems, but it also holds true for purely software or hardware components. There is always a function (or functions) for which the supplier is tasked with developing a system. And the customer should always be responsible for specifying the interfaces—especially when the supplier is “only” developing application software that will be integrated into a software architecture.
Applied FuSa – a podcast for Functional Safety pragmatists. Get your new piece of FuSa every other week.
Expert
00:00:24
Moderator
00:11:36