In previous issues, Xiaoyi introduced to all my friends that the article content was too much and was divided into two issues. In this issue, I will introduce to you "Diagnosis of AUTOSAR Module (Part 2)".
Table of contents
1 Overview
2.DCM
3.DEM
4.FIM
5 Conclusion
Click to view the previous article: AUTOSAR series topic-diagnosis module (Part 1)
03 DEM
3.1 Overview
DEM (Diagnostic Event Manager) is responsible for processing and storing diagnostic events (errors) and related data. Additionally, the DEM provides fault information to the DCM (e.g. reading all stored DTCs from the event memory). DEM provides interfaces to the application layer and other BSW modules.
The interfaces and dependencies between DEM, BSW and SWC are as follows:
3.2 DTC
DTC (Diagnostic Trouble Code, 3 bytes in length) is used to record fault information when an ECU fails, such as fault triggering conditions, fault clearing conditions, system function performance, etc.
The ISO15031-6 standard stipulates the data composition of DTC, DTC naming method and other information.
The DTC types supported by DEM are as follows:
The fault types of DTC are as follows:
● Hardware failure: such as RAM, Flash, CPU clock and other hardware failure problems
● Software failure: such as configuration word failure, calibration failure or customer-defined software functional failure
● External environment fault: voltage is too high or under voltage, ambient temperature is too high or too low, etc.
● Communication-related faults: such as message loss, invalid signal, Checksum/AliveCounter fault, etc.
When a DTC is generated, it is not stored directly in the NVM. Instead, the DTC is stored indirectly through the Event-DTC mapping relationship, and the status bits of the DTC are the OR set of the status bits of all events mapped by it. Only DTC and status bit information often cannot locate the root cause of the fault in one step. Environmental information needs to be introduced to further determine the problem, including:
● Snapshot Data: Snapshot information is the transient environmental data saved when the fault occurs, generally referring to power mode, temperature, timestamp, vehicle speed and other information.
● Extended Data: It is other auxiliary fault information when a fault occurs, such as aging counter, aged counter, Fault Counter, event id, etc.
3.3 Event
Event is the basic unit of fault monitoring and can locate a specific fault in a module.
The difference between Event and DTC
● Multiple Events can map the same DTC
● The same Event cannot map multiple DTCs
● DTC represents the concentrated expression of a certain type of Event, and Event is a specific instance of a certain DTC
● The priority of Event determines the priority of DTC; the dependency between Events determines the dependency of DTC
Event life cycle
An event needs to go through multiple stages from discovery to aging. For example, the event can be reported only after the event enabling conditions are met. It can be stored only after the DEM is internally debounced and meets the storage conditions. After storage, aging processing is required.
Event Report
Fault reporting: SWC or BSW reports the status of diagnostic events to DEM. It consists of two parts, one is diagnostic event (diagnostic event) and the other is filtering (debounce). DEM will assign a unique identification code (EventId) to each diagnostic event to distinguish different events.
Event reporting process
● Determine whether Operation Cycle is enabled
● Whether the event enabling conditions are met
● Whether the 85 service (ControlDTCSetting) is enabled?
●Debounce processing
● Determine whether storage conditions are met
Event enabling conditions
In most cases, event monitoring needs to meet certain conditions. If there are no relevant restrictions, it will cause a lot of information interference, making it impossible to quickly check the root cause. Through the event filter, the allowed or suppressed events can be achieved. Reporting effect.
Event reporting method
● Cyclic reporting: will not be cleared by the 14 service and can monitor fault status in real time, but the number of reported Events is too large, which increases the RTE load.
● Triggered reporting type: can reduce RTE load, but is also easily cleared by 14 services
3.4 Diagnostic Monitor
A diagnostic monitor is a routine entity that determines the correct functionality of a component. Diagnostic monitors can identify specific fault types (such as short circuits to ground) on monitoring paths that represent the physical system or circuit being monitored (such as sensor inputs). Each monitoring path is associated with a diagnostic event.
3.5 DEM debounce
In order to prevent false alarms, DEM Debounce only determines the final status of the event after going through the debounce algorithm, namely PASS, FAIL, and No Result. Generally, dithering strategies are divided into two types including TimeBase and Counterbase:
● TimeBase is a process of debouncing Events through timing, and is suitable for timeout failures.
● CounterBase debounces Events by counting, and is suitable for trigger-type faults.
3.6 Event Memory Management：
Event memory management is defined as the process of adding, updating, and deleting event memory entries in the DEM module. The DEM module determines whether the event memory entry is new or currently exists in event memory.
Event retention
Event retention defines the DEM module's ability to record and process events (DTC), UDS status information, and event-related data (e.g., freeze frames, extended data).
The DEM specification stipulates a total of 6 conditions for event storage. For more information, please refer to the DEM specification manual.
Event Displacement
Event replacement means that the least important, already existing event memory entries are replaced by new event memory entries that need to be stored. During the replacement process, the least critical event memory entries are lost. If the new event memory size exceeds all possible events, no replacement will occur. If the event displacement strategy is disabled, that is, DemEventDisplacementStrategy is set to DEM_DISPLACEMENT_NONE, DEM disables the event displacement function.
If the event displacement strategy is enabled, that is, DemEventDisplacementStrategy is set to DEM_DISPLACEMENT_FULL or DEM_DISPLACEMENT_PRIO_OCC, DEM replaces events according to the following principles:
● Event Priority (the most important judging principle, the smaller the number, the higher the storage priority, applicable to FULL or PRIO_OCC strategy)
● Event Active or Passive status (Active storage priority is higher than Passive priority, applicable to FULL policy)
● Event Occurence Time (replace older storage events in chronological order, replace older storage events in chronological order)
Aging of Event
The DEM module provides the ability to delete specific events from the event memory if its failure conditions do not meet the failure conditions within a certain period of time (operation cycle). This process is called "Aging" or "Unlearning". After an event ages, DEM will delete relevant event snapshot data (freeze frames) and extended data records.
DemAgingCycleCounterThreshold or DemAgingCyclecounterthresholdforfslc defines the completed aging cycle count value after which event memory entries are removed (aged) from event memory. When the Aging Counter reaches DemAgingCycleCounterThreshold, the DTC status bit bit3: confirmedDTC is set to 0. Each Event memory entry has at least one Aging Counter.
04 FIM
The Function Inhibition Manager is responsible for providing a control mechanism for software components and their functionality. Through FIM, these functions can be inhibited (deactivated) even at runtime (after building). Configure and modify during configuration).
functionality: A functionality can be built from the contents of one, several, or partial runnable entities with the same set of permissions/inhibition conditions.
FID: A function is assigned to an identifier (FID - Functional Identifier), and the suppression conditions for that specific identifier. These functions poll the respective FID for permission status before executing. If the suppression condition for a specific identifier is true, the corresponding function will no longer be executed.
4.1 FIM Core Variables
● Diagnostic Event: A "diagnostic event" is an identifier provided by DEM to a specific diagnostic monitor function for reporting errors.
● Monitor Status: "Monitor Status" is the status calculated by DEM based on the report value of the monitoring function. Possible values are defined by Dem_MonitorStatusType
● Monitored Component: "Monitored Component" is an identifier provided by DEM to a specific monitored component (hardware component or signal). The FAILED status of a "monitored component" represents the results of all assigned monitoring functions and fault information inherited from other DEMComponents
● Summarized Event: FIM configuration should support summarized events. A summary event consists of multiple single diagnostic events; therefore, a specific summary event is only a representative of multiple diagnostic events. Summarized Event can be used as a suppression condition for SWC
● Function Identifier:
a. Each functionid in FIM should be guaranteed to be unique
b. The FIM module should use FunctionId to directly point to relevant function information (permission status, etc.)
FIM implements the calculation of functional permissions. These calculated objects are SWCs or Logic Units, and the permission status of each FID is calculated based on the EventIds assigned to the specific FID. Calculate the permission status of each EventIds and perform an "AND" to determine the final permission status
● Function Identifier permission state: FID permission state contains information about whether the function represented by its FID can be executed (True to execute/False to prohibit). SWC components access status through FIM_GetFunctionPermission
4.2 FIM Core Functionalities
FIM Data Structure
The configuration process of FIM should create a data structure in the FIM module to store the suppression relationship (EventID - FID -applicable mask).
A configurable number of EventIds and suppression masks are assigned to a FID. The number of EventIds and suppression masks for each FID must match so that for each configured event, there is a corresponding suppression mask. The suppression mask contains suppression conditions for FIDs, provided that the associated EventIds have a specific status (Dem_EventStatusExtendedType). These masks define which states of events the FID is sensitive to.
Each FID has a suppression mask, and both are assigned to a specific FID EventId. If the event has a certain status, and if the event status matches the configured mask, suppression of the FID will be activated.
Interaction with DEM
The function of the FIM module is to provide service functions for controlling SWC (allow/suppress) based on DEM events. When the monitoring status of the reported event changes, if DemTriggerFiMReports is enabled, DEM notifies FIM of the change in monitoring status through the API function FIM_DemTriggerOnMonitorStatus. FIM uses Dem_GetMonitorStatus to recalculate function suppression when notified of a monitor status change.
Each FID has an Inhibition Counter. The suppression counter contains the number of currently suppressed EventIds. If the state matches the mask, the suppression counter is incremented; otherwise, the suppression counter is not updated. This applies to FIM_GetFunctionPermission (if the permission status must be calculated at query time) and FIM_MainFunction.
If FIM_DemTriggerOnMonitorStatus reports a monitor status change, perform the following operations:
● If the state of EventId changes resulting in a release state (mask does not match monitor state), the suppression counter must be decremented
● If a state change of EventId results in a suppressed state (mask matches monitor state), the suppressed counter must be incremented
● If the suppression counter is > 0, the FID permission status is set to FALSE, otherwise the FID permission status is set to TRUE
Interaction with SWC：
For each FID, the SWC should provide a list of events and a mask that result in FID suppression. The FIM module should respond synchronously to incoming queries to ensure immediate control of the functionality. The FIM module implements this behavior by storing the permission status as a state variable or calculating the event status when querying the permission. If a function (FID) is set to be unavailable using the interface FIM_SetFunctionAvailable, its permission status FIM_GetFunctionPermission always returns FALSE.
4.3 FIM Usage Example
The configuration of FIM actually establishes the mapping relationship between EventId and assigned FunctionId.
The following figure shows the implementation process of FIM:
Step1: Front-Left Window-lifter SW-C reports the fault to the Error Management module
Step2: The DEM module identifies the Event anti_Pinch fault
Step3: The DEM module will call the corresponding function interface of the FiM module to notify FIM of the impact of the Event Status on the corresponding FID.
Step4: The SWC module polls the corresponding FID and then makes the corresponding function suppression response
05 Conclusion
Today, Xiaoyi gave you a detailed introduction to the AUTOSAR diagnostic module in this article. In summary, the three diagnostic-related modules are responsible for implementing different functions in the diagnostic process. DCM is mainly responsible for diagnostic communication management, and DEM implements the processing of diagnostic events. The FIM module is designed to suppress related functions after a fault occurs. That’s it for today about the AUTOSAR diagnostic module, thank you all for reading!