Basics of Autosar Module - DEM [Diagnostic Event Manager]

 

DEM is a software component in Autosar BSW responsible for managing the diagnostic events reported by other software components. When I say other software components its can be an application SW-C or an software component of BSW. We will understand the term Diagnostic Event later.

So a software component detects an diagnostic event. If it wants that event to be managed, then it reports it to DEM module. Then DEM module manages the event for the software component. The Sw-C can check the status of the event it reported with DEM at anytime. And depending on the status of that event either DEM module or the software component can take some action.

I mentioned many interactions between Sw-C and DEM module. And DEM provides API for each of them as listed below:

Interaction	API
Report Event to DEM	Dem_SetEventStatus(EventID, EventStatus)
Check Event Status

 

Note: The Event is detected inside the Sw-C only and the function which checks for occurrence of the event is known as Monitoring function.

 

What is an Diagnostic Event?

Each component in automotive software must behave according to its specifications so as to serve its purpose. But sometimes due to some problem, it may deviate from its expected behavior and this may result in some malfunction and cause problems like accident also. So it is necessary to have some mechanism which checks continuously if a component is behaving as expected or if some mal-function is happening. This is called as diagnosing the component and the function which performs a particular diagnosis on the component is called a monitor function.

            Each monitor function checks for a particular behavior and if it identifies some significant deviation, then we say a diagnostic event occurred. An event in English means something occurring which is of a significance. Here also this is an event of diagnostics and is significant and demands some kind of an action. Hence the term Diagnostic Event.

            So each critical component has its own monitors and they check the behavior of the component and raise diagnostic events. A diagnostic event is identified by EventID(number) or its EventName(string).

 

All the events which can be reported will be configured in DEM module beforehand. Each Diagnostic Event is configured as DemEventParameter. Every time the monitor function performs the check, the result of the check is reported to DEM. The result of diagnostic event check is called Event status.

Configuration of Diagnostic Events is shown below in DaVinci Configurator:

Example of an Diagnostic Event:

Imagine there is a software component responsible for reading the battery supply voltage. The battery voltage must be between 3.3volts to 4.5 volts which is the valid range. There can be a monitor function to check for Short-to-ground. It keeps checking if the value of battery voltage read is zero or not. If anytime the battery voltage becomes 0volts then it raises Diagnostic event and reports it to DEM.

 

Why Diagnostic Event

Diagnostic Events are the means by which the Software performs self diagnosis and stores the status of its health in fault memory. But these diagnostic events are internal to the system and not visible to the outer world. All this self diagnosis is part of On-Board Diagnostics where the system diagnoses its health and stores it so that a technician can read it via tester tool and fix the problems. He uses UDS services for this and those tester diagnostic communication is handled by another Autosar module called DCM. But As said before, diagnostic Events are not visible to either DCM or Tester tool. For that purpose we have DTCs. DTC stand for Diagnostic Trouble codes and we will learn about it in next section. 

Note: Autosar provides possibility of disabling an event configured in two ways.

1. Configuration parameter : DemEventAvailable
2. API : Dem_SetEventAvailable( )
   

With this we can mark an Dem Event as not available. An event which is not available is treated as if it was not included in the Dem configuration.

Diagnostic Trouble Codes [DTC]

A ‘Diagnostic trouble code’ defines a unique identifier (shown to the diagnostic tester) mapped to a ‘Diagnostic event’ of the Dem module. The Dem provides the status of ‘Diagnostic trouble codes’ to the Dcm module

The link between Dem Event configuration to the DTC configuration is shown in below diagram:

There are two different kinds of DTCs:

• Non OBD-relevant DTCs (UDS DTCs) 
• OBD-relevant DTCs

 In DEM, DTC number is represented as UINT32. In General, OBD related DTCs are 2 byte long [WWH-OBD has 3 bytes DTCs] and non OBD DTCs are 3 byte long. Non OBD includes UDS[ISO14229] and J-1939 protocols. They are represented as shown in below diagram.

DTC Groups:

    You know DTC is 3 bytes length and each DTC represents a particular fault in the system. Imagine when some problem occurs in the car, then upon diagnostics, system logs some DTCs in its fault memory. The technician checks that and fixes the problem and now he must clear all those DTCs in the system as the problems no longer active in the system. So it is a tedious job to clear each DTC one by one. So Autosar and UDS protocol allows to group a range of DTCs and the group is identified with a similar 3 byte code as well. If the ID for DTC group is used in UDS services like clear DTC or DTC settings etc, then same operation is performed for all the DTCs in the range. 

    Now by default, all the DTCs configured is grouped together in a group with ID 0xFFFFFF. If you need to create more DTC groups then you can. The DTC ID for the group can be chosen from range 0x000100 to 0xFFFE00. The DTC group can be created in DEM configuration in "DEM >> DemGeneral >> DemGroupOfDTCs" 

Example of configuration is shown in below diagram

Here range of  DTC group is starting from the ID of group DTC till ID of next DTC group. In this example the range of NewDTCGRoup is 0xD80F01 till 0xD80F3F.