What are DEM, DLT, DCM and DET

Micael Coutinho,Wed Nov 09 2022 • autosar bsw dem dlt dcm det

These modules all sound very similar, but they could not be more different in practice. Learn what they're all about here

The first time I heard about these four modules in Autosar, I honestly thought they were tightly related. That assumption is not wrong, but is far away from the truth. In reality, some of these modules interact with each other (most of them belong to the diagnostics stack, which is a giant topic, but we try to overview it here, in Autosar Diagnostic Stack Overview, coming soon), but they serve different purposes in the Autosar stack. Let's go through these modules one by one and learn what they're all about, shall we?

So, first, let me start with the most different of all:

DET (Development Error Tracer)- Imagine you're configuring an Autosar module from the beginning. You are very likely (unless you're technically gifted or inhuman) to stumble into frustrating errors, which can lead to some time-consuming errors.

The DET module can be enabled in each Autosar BSW module and it will make your life extremely easier during development: when you go and flash your generated and compiled code into an ECU, if you don't get software resets, you can put a breakpoint on the Det_ReportError function and check if the BSW module you enabled it for calls the function. You can also call it yourself. It has the following API:

Std_ReturnType Det_ReportError
(
 uint16 ModuleId,
 uint8 InstanceId,
 uint8 ApiId,
 uint8 ErrorId
)

Each BSW module in Autosar has an ID associated with it. You can also check your generated code for more information on which API has thrown an error and which is the error. You can also do this for Software Components, through the DET service API. Extremely useful! Lastly, some implementations of the DET may store a buffer with all errors, so that you don't have to add a breakpoint and let the program run freely.

DEM (Diagnostic Event Manager)- Now, this module a tad bit more complicated than the DET, and that reflects on the specification size provided by Autosar. Which means, we are coming back to it with the article Autosar DEM Overview (coming soon), because this one is just meant to explain that the modules are not the same.

You have probably heard about the diagnostic trouble codes, as they are one of the most popular topics for automotive enthusiasts. You probably even have one of those OBD decoders on your vehicle! In essence, the DEM provides an interface for BSW modules and SW-C's to communicate events that are relevant for diagnostics. In essence, the "DEM provides a common approach for diagnostic fault memory" (I just think this sentence from the Autosar Specification is perfect). For example, a fault in a temperature sensor, or a short-circuit on the CAN bus. With the DEM, you can communicate these events easily, either through service ports or API's.

You can also check the status of an event and act accordingly. Lastly, it has some interactions with the DCM, providing fault information to it (for example, read the stored DTCs from the DEM event memory). But the interactions do not stop there, as you can also interact with the FIM (Function Inhibition Manager. To learn more about it, please consult the article Autosar FIM Overview (coming soon), because you may want to disable some functionality upon some event status.

DEM dependencies with other modules, as per Autosar Specification { w: 851, h: 643 }

DEM dependencies with other modules, as per Autosar Specification

DCM (Diagnostic Communication Manager)- at the heart of the diagnostics, there are UDS services, which you may have heard about. It serves as the communication protocol that the mechanic uses to communicate with the ECU, to find all kinds of problems. DCM implements this communication from the ECU side, manages the diagnostic states, specifically the diagnostic sessions and security states. It processes the diagnostic messages sent via the diagnostic tools, and it can interact with BSW modules or even Software Components, to gather the necessary requested data or perform specific commands.

An illustration on DCM's usefulness, as per Autosar Specification { w: 634, h: 279 }

An illustration on DCM's usefulness, as per Autosar Specification

As a side note, some of the avaiable UDS service groups are diagnostic and communication management, data transmission, transmission of stored data, input/output control, remote routine activation and upload/download. If you want to learn more about USD services, it might be worth checking out UDS Services 101 (coming soon).

DLT (Diagnostic Log and Trace)- sitting between the DET and DEM in class, you can find the DLT. Its close neighbours are the RTE and Software Components, and it also has a close relationship with the PduR (PDU Router, to learn more about it consult our article Autosar PDU Router Overview, coming soon). Now, let's finish the family and class jokes. The DLT works by receiving log information from the RTE, Software Components, DET and DEM, and transmits this information outside the ECU, through the PduR.

Now, you might be thinking: why do I need DLT, when I can have a debugger and check those modules by myself? Well, first, you have a single place to check everything. Second, your ECU may be closed off, and in near-production stages, it's very common to not have a debugger connection. In this case, the DLT can be used to send and receive log and trace information directly on your preferred bus, or even storing the logs into the NvM module. So, you can make some tests with your ECU, and in the end check what happened, through the DLT.

Alright, as some closing thoughts, I hope this small description has helped you figure out that even though these four modules look very similar in theory, that could not be farther from the truth.

Author: Micael Coutinho (opens in a new tab)

References: