AUTOSAR DEM Module

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