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.
- Configuration parameter : DemEventAvailable
- API : Dem_SetEventAvailable( )
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:
- 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:
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.