FIM Overview
Whenever an issue occurs within an ECU, protective measures need to be taken. Learn how FIM works to accomplish this goal here
In the past, we spent already a bit of time on ECU monitoring, diagnostics and functional safety, by learning about the DEM (Diagnostic Event Manager) in the article DEM Overview (opens in a new tab) and opening the book about functional safety in What is Functional Safety (opens in a new tab). We even overviewed the watchdog stack, in Watchdgod Stack Overview (opens in a new tab). One thing we never quite explained is what comes next.
Imagine a scenario when a problem is detected within an ECU. Let's use the aforementioned modules as an example. As part of your functional safety, you decide to monitor the correct execution of a function, by setting multiple checkpoints in a Supervised Entity (SE). Next, your watchdog detects a failure and reports it to the DEM. What's next? You will likely want to act on this failure, by inhibiting some functionalities. And like that, we introduce the Function Inhibition Manager (FIM).
One can describe the FiM as a control mechanism to deactivate some functionalities depending on a set of conditions. It acts as a central hub to react upon malfunctions. You assign your functionalities with a FID (Function IDentifier) and constantly poll for a permission to execute such functionality (eg. running an actuator). When an inhibit condition is detected, the functionality is not executed.
As the FIM tries to be this central hub, it is expected a lot of interaction with other modules. We already learned about the central hub for diagnostic monitoring, which is the DEM, but the FIM needs a bit more interaction with the Autosar layered architecture. Let's take a look at the interaction with other modules:
FIM interaction with other modules, in the Autosar Layered architecture
-
DEM (Diagnostic Event Manager) - Obviously, as the central point for diagnostic monitoring, the DEM can provide a lot of useful information to the FIM, in regards to inhibit conditions. That way, you don't need to get your information from a bunch of places.
-
SW-C (Software Components) - If a Software Component contains the permission interface for the FIM, it will ask the FIM to run the functionality defined by the FID (Function Identifier), before running it.
-
BSW (Basic SoftWare) - The permission mechanism is not just limited to SW-C's. A BSW module might want to run a specific functionality which can be inhibited by the FIM.
Now, let's check how the FIM implements this inhibition mechanism, starting with the FID's. You can assign a bunch of DEM event ID's and inhibition masks to calculate the boolean inhibition. Regarding the inhibition part, you need a service port, through a client-Server interface to get permission (if you need an overview of interfaces and ports, you can check our article Types of Interfaces and Ports (opens in a new tab)) or an API, depending on where you are in the layered architecture, to get the permission for a certain functionality, as described below:
// Client-Server Interface pseudo-code to get permission for a specified FID
ClientServerInterface FunctionInhibition {
GetFunctionPermission(OUT Boolean Permission);
}
// API to get permission for a specified FID
void Fim_GetFunctionPermission(Fim_FunctionIdType FID, boolean* Permission)
Of course, there are some constraints regarding the FIM. It's not suited for every use case, namely:
- Time critical systems may need a faster response time and cannot take the slight delays in the stack
- It may not be sufficiently flexible for all Software Components. It may be difficult to integrate the FIM in some cases
- Some SW-C's may not be ready to use the FIM, in terms of software integrity
As some finishing thoughts, we hope this article helped you understand the main advantages and drawbacks of the FIM, and show you it's nothing to be afraid of. It's a quite simple module!
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn