After reading this article you will learn.
1. What is DEM module of AUTOSAR.
2. What Diagnostic Events, DTCs and DIDs.
3. Brief about Event Debouncing.
4. Concept of DTC status byte.
5. Aging of diagnostic event.
6. Snapshot data structure and storage.
7. DEM Module configuration in AUTOSAR.

1. AUTOSAR DEM Module :

Diagnostic Event Manager (DEM) is part of service layer of AUTOSAR architecture. DEM module is responsible for diagnostic event processing and storing of event related data to memory and read event related data from memory and provide information to DCM module. UDS service no. $19 is completely related to DEM module.

Software Components (SWCs) and BSW modules use DEM APIs to report an event status i.e. event is  passed or failed. Fig. 1 show DEM module and interfaced with other SWC and BSW modules. DEM communicate with SWCs, NVM module and DCM module.

Fig. 1 Diagnostic stack of AUTOSAR

SWCs communicate with DEM module through RTE, using Client Server port or Sender receiver port. SWC communicates to report status of event to DEM and DEM reads data from SWCs to collect snapshot data. DCM module communicates with DEM and vice versa using AUTOSAR interface to read Diagnostic information (i.e. Service No. 19 Read DTC status or Read Snapshot data).  DEM communicates with NVM using AUTOSAR interface. DEM uses NVM to read and write diagnostic information into memory. Other BSW modules communicates to DEM module to report BSW event status whether event is  passed or failed.

Below are some basic points need to understand to configure DEM module.  

2. Diagnostic Event and DTC :

In this section we will see what is diagnostic event and what is diagnostic trouble code. Consider a software component which monitors a health of battery (monitored by monitor function) . One event diagnostic event is associated with battery health. Monitor function will report a status of event to DEM. Event id is assigned to an event. This event id is unique per event. SWCs or  BSW modules reports event status to DEM using event id. e.g. event id 27 is associated with battery health event. Event ids are assigned by DEM module. 

Diagnostic trouble code (DTC) is associated with an event. When event is reported as passed or failed, status of DTC changes.  DCM uses DTC number to read information about diagnostic event and DTC (e.g. 19 02 or 19 04 service). e.g. DTC C08088 is assigned to event battery health. As per UDS (ISO 14229) protocol, DTC status is stored in a byte called DTC status byte.

In short, monitor function (a runnable entity in SWC) monitors a event and reports event status to DEM module (event passes/failed) through RTE call. Based on event status DTC status changes. 

AS per ISO14229-1 for each diagnostic event, DEM module maintains a UDS DTC status byte information. DTC number is of 4 bytes. There are globally common DTC numbers and supplier specific DTC numbers.

2.1 Event Debouncing :

There are three types of event debouncing mechanism provided by DEM module.
1. Time Based Debouncing
2. Counter Based Debouncing
3. Monitor Internal Debouncing

Time based and counter based debouncing is  implemented by DEM, while monitor internal is implemented by software component. Event is tested and considered as failed if debouncing condition mentioned above (maturation criteria) is satisfied. 

2.2 DTC Status byte : 

In ISO14229-1 DTC status byte is defined. Bit 0 to Bit 7 represents DTC status. Test Failed means monitor has evaluated error condition and debouncing is performed (i.e. maturation criteria is met)

Bit 0 : Test Failed
Bit 1 : This Failed This Operation Cycle
Bit 2 : Pending DTC
Bit 3 : Confirmed DTC
Bit 4 : Test Not Completed Since Last Clear
Bit 5 : Test Failed Since Last Clear
Bit 6 : Test Not Completed This Operation Cycle
Bit 7 : Warning Indicator Requested

2.3 Snapshot Data and Extended Data :

When event is failed then event related data can be stored into NVM. ISO14229-1 defines two kinds of  event specific data : 1. Snapshot data 2. Extended data. When battery health monitoring DTC is set, you may want to store battery voltage, battery current, this is what snapshot data. 

To store snapshot data and extended data trigger is required. Trigger condition can be when test failed bit is set or confirmed dtc bit is set.

What is DID? 
Full form of DID is diagnostic data identifier. Freeze frame/Snapshot data contains a DID or multiple DIDs. DID is a number assigned to identify a data. When DTC is set and data need to store into NVM. Data is battery voltage and battery current. Then one DID is assigned to battery voltage (e.g. DID FD22) and one DID is assigned to battery current (e.g. DID D025). 

Size of DID is user defined. It may be 1 byte or may be 8 bytes. These DIDs are assigned to snapshot data/freeze-frame. Freeze-frame may have a number associated with it (Depends on configuration). DIDs are required for Extended data also.

NVM defined memory blocks for Snapshot data to be stored. RAM blocks for those memory NVM blocks are defined by DEM as Dem_Cfg_PrimaryEntry_0 upto Dem_Cfg_PrimaryEntry_N. N is configurable. Generally configured as 8. While writing to NVM data from RAM block (Dem_Cfg_PrimaryEntry_0) is copied to NV block.

Structure of  Snapshot data is shown in below image. This is what gets stored into NVM.

Note : Below image is taken from Vector Technical Reference manual of DEM. All rights reserved to Vector.

Fig.2 Structure of Snapshot Data

Important Point :
When Snapshot data need to store into memory, from where it is collected? . Snapshot data is made-up of DIDs. So DEM (BSW) will read each DID from application using client server port interface and DEM will act as client and application as server.

To set an event client server port interface is used. DEM acts as server while SWC acts as client. SWC uses DEM API Dem_SetEventStaus() to report an event status to BSW.

2.4 Event Aging :

When event is stored into NVM, and event is no longer getting failed, then event starts aging and once event is aged, event is removed from memory. Now how this is done? Consider a event is failed and stored into memory. In an operation cycle event does not failed and event status passed only. Then trigger to aging is started. And aging cycle counter is started and incremented in each operation cycle if event is passed only in operation cycle and does not failed. When aging cycle counter reached threshold value defined by user, event is removed from memory.

3. Configuration of DEM Module :

Above part has explained DEM module related basic topics. Now in this topic we will see if you need to configure DEM module then what things need to configure.

Note : Not each and every configuration is mentioned here, but important configuration points considered. 

Fig. 3 DEM Configuration

As shown in fig.3 DEM module provides ports called Pport. Using Pport a SWC can set or clear a DTC. For that SWC need to use DiagnosticInfo Port. Where SWC will acts as Client requesting a service to set a DTC and more, while Dem acts as server. To read snapshot data, DEM reads it from SWC, in that case DEM acts as client and SWC acts as server. Here DEM will use Rport Service Interface named DataServices and a callback function (Server) need to implement in SWC, which will prove current value of DID to DEM

3.1. DEM Configuration :

Remember DEM deal with service 19. i.e DTC, DID, Extended data and Snapshot data, Diagnostic Events. So while configuration keep in mind you need to configure them. Below are some important points to remember while configuration DEM module :

1. Configure DTC : 
    Configure DTC number.
    Configure whether DTC is of UDS or OBD type. 
    Assign a reference of snapshot data and extended data.

2. Configure an event :
    Assign a DTC to an event.
    Enable or disable event aging. 
    Aging threshold 
    Event debouncing algorithm
    Immediate NVM store option enable or disable.

3. Configure DIDs :   
    Configure DID number and Name
    Port for SWC to BSW communication : Client Server or Sender Receiver 
    DID size, data type

4. Snapshot Data and Extended Data :
    Assign DIDs to respective snapshot data and extended data.
    If snapshot is configured to have number then assign number to snapshot data 
    Assign number to extended data

5. NVM Block :
    NVM blocks for DEM should be configured in NVM and reference need to provide in DEM.

6. DEM General Settings :
    To enable aging
    Trigger to store snapshot data
    Event aging type
    Event displacement policy
Note:  SWS version of  DEM module used for reference to explain configuration and DEM concepts in this blog is 4.0.1 

Post a Comment

  1. Its a very nice explanation and one can easily understand and analyze the over view of DEM module .
    Tank you for your great explanation.

  2. Well explained and concise

  3. Hi, your explanation is good. Can you add information regarding event memory (primary memory, mirror memory etc...)

  4. Short and precise.
    Easily understandable without so many jargons.
    Will be nice if u write more articles on autosar.

  5. Thank you. Sure more articles are on the way, till then you can read other AUTOSAR blogs in AUTOSAR section

  6. Whether the DTC code, status byte, freeze frame and exetended data will be stored in NvM or also stored in Fls?

  7. DTC code, status byte, freese frame and extended data will be stored in NvM.

  8. thank you for explaining DEM in a great way, I have a question: what if several DTCs that have the same snapshot in common are already logged, is this snapshot will be logged into nv memory in different blocks ?

  9. what is the role of the Master and satellites in DEM

  10. Hello, Regarding Common Snapshot data, there are NV blocks to store Snapshot data, but while storing not only snapshot data but Dtc number will also get logged (refer fig.2 for more detail), So for each failed event (irrespective of common snapshot data) snapshot data will be saved in different Nv Blocks (Number of NV blocks for DEM are configured already, if NV blocks for DEM arr full then DEM will use a criteria to remove a block from NV memory and allocate block to new event, if event is not in NV memory)

  11. If the snapshot has 2DIDs and each DID are 1byte.Then the size of snapshot nvm block is ? Is it 2byte or we need to add dtc number,status byte size also?

  12. You can configure 2 bytes, but generally you should configure size of dem NV blocks to the maximum size of snapshot data among all snapshot data. As In which dem block your snapshot will go is not decided before.

  13. I would like to know the startup or initialization sequence of DEM module in detail. Any help?

  14. well explained. Thanks a lot!!
    Please also write about the primary failure memory.

  15. Well explained in a simple way...Short and precise.
    Easily understandable.
    Thanks Padmanabh

  16. Thanks for your great efforts!!

  17. Very very well explained,
    Thanks for your efforts

  18. Hello sir, Can you please give more information on what is debouncing?

  19. Thanks for this topic, I have a question if i may what is the meaning of operation cycle and how it is defined in DEM? and what is the difference between it and monitoring cycle ?

    1. Operation cycle is time between start and end of an event.
      It can be ignition cycle (Time between Ignition key on and off), Driving cycle (Engine start and stop). Its is defined by OEM and its can be defined as per the requirements of manufacturer.

      Monitor Cycle is the time between performing the test of DTC to find the status of the DTC.
      It can be seen mutiple times in one operation cycle

  20. Nice article. While reading AUTOSAR Dem specs, I found that the BSW can sue C-API with Dem_SetEventStatus, and SWC uses RTE call SetEventStatus. In the first case, the EventId is a parameter, but there is no such info in the later case. How would the SWC indicates the EventId ?

Post a Comment
To Top