Diagnostic Log and Trace (Dlt)
Translate in your language
Background:
In general embedded systems programming, we use UART or any serial interface to send or receive debug messages or information of the live or running code on hardware. But we need to implement that functionality by writing a separate code to perform the operation of receiving and transmitting debug messages from UART or serial interface. If we use RTOS, we can also get information related OS on serial interface like UART which is apart from application information.
Similarly, AUTOSAR has a dedicated module in layered architecture to perform the same work of transmission of debug/diagnostic information messages via UART or serial interface or CDD (Complex device driver) and reception of Dlt commands from a external Log tool. Such debug information can be sent from Application (SWC), DEM (Diagnostic Event Manager), DET (Default Error Tracer) and RTE. Dlt module further sends this received information to DCM or CDD or Debug Interface (serial interface) to transmit this to developer/tester.
Dlt module in detail:
Dlt is a basic software (BSW) module which is also a part of Com Stack, provides the facility of Logging and Tracing for SWCs, DET, DEM and RTE. Dlt module is located above PduR and below RTE. Tracing here means VFB trace which has all the information of data exchanges for a SWC via ports. Dlt Module performs following functionalities:
- Logging: This functionality involves logging of errors,warnings and info messages from SWCs via standardized AUTOSAR interface, gather all log and trace messages from SWCs in a centralized service component in BSW, log messages from DET or DEM.
- Tracing: This functionality is useful for logging the RTE or VFB trace.
- Control: Dlt also handles some control functionalities like enable/disable log messages or control trace levels individually by configuration using a specialized tool.
- Generic: Generic functionalities like: Dlt module is available during debugging and production phase, Dlt is accessible using a standard diagnosis or platform interface, Dlt module also provides security mechanisms to prevent misuse in production phase.
Dlt receives information like: state of application from SWC, or log message, development errors from Default Error Tracer [DET] (which is responsible for tracking errors in BSW occurring during development in runtime), diagnostic messages from Diagnostic Event Manager [DEM] (which is responsible in managing the diagnostic messages having diagnostic information like Freeze frame,Diagnostic trouble codes [DTC]). Dlt further converts this information in a standard Dlt format which follows the Dlt protocol (as given in figure below) and passes this information to Pdur for further sending it on communication bus. Dlt provides APIs which are accessed by above listed modules for transmitting information to Dlt.
Diagnostic Log and Trace protocol:
Information (log message) sent by SWC or other modules cannot be sent directly on communication bus, as it will contradict the aim of AUTOSAR to standardize communication. Before sending the message on communication bus, Dlt converts the message and modifies it in a standard message by following protocol which has specific format, message sequences and semantics of protocol called Dlt Protocol. Dlt protocol allows external logging tool to communicate with Dlt (using standard Dlt commands) for setting filter on log messages to be received based on severity level (fatal error, information, or warning). External logging tool can also in runtime inform SWCs to generate only logs matching filter level, or change the communication bus on which the message is to be sent, or store filter level configuration in non-volatile memory to avoid configuring Dlt again. Lets study what that protocol is.
Above figure (Fig.2.1) is Dlt message format as per protocol and figures 2.2,2.3 are expanded headers of the Dlt message, Dlt message has three parts:
- Standard Header: As shown in Fig.2.2, It is a 16 byte header which consists of fields like: header type (contains general information about Dlt message which indicates which fields in standard header are present or not and also indicates if extended header is used), 8-bit Message Counter (this is counter to count Dlt messages received by Dlt module), Length (16-bit length of message), Optional ECU ID (It is used to identify which ECU has sent Dlt message), Optional Session ID (it is used to identify the transmitter of a log or trace message within a ECU), Optional Timestamp (it is used to add timing information a Dlt message has been generated)
- Extended Header: As shown in fig 2.3, It is a 9 byte header which consists of following fields: Message Info (It contains information of Verbose or non Verbose message, Type of message [Log message,Trace message,Network message,Control Message], Message Type info [which is dependent on Type of message] for instance, if type of message is Log, then this field indicates different types of Log messages like Fatal, Error, Info, Warning,Debug, Verbose),Number of Arguments (It indicates the number of arguments in the payload of Dlt message),Application ID (It is a abbreviation of SWC which generates the Dlt message), Context ID (It is user defined ID to logically group Dlt messages generated by a SWC).
- Payload: This contains the parameters that are logged or traced or it can also have control information. In verbose mode, this will have meta-data which indicates the type information of payload like: boolean,Raw,String,Variable, Fixed point, etc. But in non verbose mode, this information has to be constructed as meta-data is not transmitted in it.
Dlt communicates with external logging tool asynchronously without any external stimulation or connection request as we do in TCP. Applications (SWCs) can register for receiving notifications from Dlt to get notified about filter setting changes done by logging tool. Application can send log message in verbose or non-verbose mode. In verbose mode, meta-data is added with log message which is useful for the logging tool to interpret log messages and help the tester. In non-verbose mode, no meta-data is sent with log message instead a separate FIBEX file is used which has all the meta data which the logging tool uses to interpret messages.
Services/Commands supported by Dlt:
| Service ID | Dlt Command Name | Description |
|---|---|---|
| 0x01 | SetLogLevel | Set the Log Level |
| 0x02 | SetTraceStatus | Enable/Disable Trace Messages |
| 0x03 | GetLogInfo | Returns the LogLevel for registered applications |
| 0x04 | GetDefaultLogLevel | Returns the LogLevel for wildcards |
| 0x05 | StoreConfiguration | Stores the current configuration non volatile |
| 0x06 | RestoreToFactoryDefault | Sets the configuration back to default |
| 0x0A | SetMessageFiltering | Enable/Disable message filtering |
| 0x11 | SetDefaultLogLevel | Sets the LogLevel for wildcards |
| 0x12 | SetDefaultTraceStatus | Enable/Disable TraceMessages for wildcards |
| 0x13 | GetSoftwareVersion | Get the ECU software version |
| 0x15 | GetDefaultTraceStatus | Get the current TraceLevel for wildcards |
| 0x17 | GetLogChannelNames | Returns the LogChannel’s name |
| 0x1F | GetTraceStatus | Returns the current TraceStatus |
| 0x20 | SetLogChannelAssignment | Adds/ Removes the given LogChannel as output path |
| 0x21 | SetLogChannelThreshold | Sets the filter threshold for the given LogChanne |
| 0x22 | GetLogChannelThreshold | Returns the current LogLevel for a given LogChannel |
| 0x23 | BufferOverflowNotification | Report that a buffer overflow occurred |
Above table lists down the supported services/commands by Dlt module which are to be used while sending commands from external logging tool. I won’t be going in detail explaining each command, because it will make this article lengthy 🙂 .
Communication of Dlt with other layers/modules:
1. Communication with application layer (SWC):
SWCs can communicate with Dlt in two ways:
- Using Dlt interfaces to send Log and Trace messages
- Using a port provided by Dlt to get notifications on changes in log threshold level and trace state by logging tool. This will only generate Log or Trace messages of interest.
As discussed above, Dlt module uses a tuple of Application ID/Context ID to identify messages but Dlt module also supports multiple instances of SWCs (in AUTOSAR SWC can have multiple instantiation, so messages can be generated by each instance of SWC and Dlt supports it) which use same tuple of Application ID/Context ID, to differentiate between multiple instances of messages from same SWC, a new field is also added with that tuple named Session ID. But this again makes the problem more complex 😀 , so Dlt provides a dedicated provider port for each configured SWC instance which acts as a Session ID in port defined argument for the provider port. The assignment or non assignment of tuple of Application ID/Context ID to respective SWC can be done during configuration or runtime with a call to RegisterContext and UnregisterContext respectively.
2. Communication with RTE for VFB Trace:
As discussed in beginning of this article, Dlt module can get VFB trace from RTE which has information of Data exchanges between SWC and RTE without any information to SWC. To allow Dlt to record VFB trace, this has to be configured during RTE configuration with “Dlt” in configuration parameter RteVfbTraceClientPrefix. This configuration generates VFB Trace hook function which is implemented in Dlt module which uses interfaces provided by RTE.
3. Communication with DEM:
DEM stores the events and event ID of events generated by SWCs and BSW modules. Every event has Diagnostic Trouble Code (DTC), Extended Data Records, and a Freeze Frame, we will discuss these terms in more detail in Diagnostics related article. DEM communicates with Dlt by calling Dlt’s Dlt_DemTriggerOnEventStatus function on each change in state of event to notify Dlt of this change. While calling this function, DEM provides EventID of event. Dlt uses this EventID to get more information about the event. In this function, Dlt module compares the old status with new status of event, if there is change in status of event, then Dlt builds a Dlt log messages with new status and sends it.
4. Communication with DET:
DET module is responsible for reception of reporting of errors from SWCs and BSW modules. Such errors are forwarded to Dlt module as message with suitable content using the API Dlt_DetForwardErrorTrace. The log level for DET errors is “Error”.
4. Communication with NVM:
As discussed above, Dlt can store the filter configuration persistently by storing it in non volatile memory. For this, Dlt module has to talk with NVM module. The command to be used by logging tool (from above shared table) is StoreConfiguration with service ID 0x05.
Transmission of Log and Trace messages from Dlt:
Above figure depicts the path of Log message transmission from SWC to lower layers.
Note: I have combined some blocks for simplification so this figure may not match with original AUTOSAR figure, but the gist is same.
The steps as per above figure are:
- Generate timestamp: If configured, timestamp will be added to the message.
- Filter message: Message filtering means to accept or discard an incoming log or trace message based on the Application ID/Context ID tuple, which is assigned to that message. Here messages with log level as configured in filter are only passed others are discarded.
- Select target LogChannel: Dlt module in this step, selects the target channel as per configuration for log message.
- Check Message length and apply the current LogChannel threshold: Dlt module can be configured to only pass a maximum size of message, if configured then it enforces it in this step and discards all the log messages which are large in size. This step also check if the Log level threshold (check commands table) matches with configured level for selected channel, if not then the log message will be discarded.
- Copy Dlt message to LogChannel specific buffer: In this step, Dlt module copies the message (if passed in above steps) to the buffer of selected channel.
Further the Dlt message is passed to PduR and is passed on to respective handles.
Here ends this article! I hope I explained it in easy language and you understood it.
Please let me know your doubts in comment box. If you find any incorrect information, please report it. I will highly appreciate if you will subscribe for newsletters from below!
Thanks for reading 🙂
Thank you so much for a nice blog on DLT. I am a little bit curious to see the callstack of DLT when it is using Ethernet. for example Dlt->PduR->(TP)SoAd->TCp/Ip->EthIf->EthDrv
Could you please add little more info about how it will be called when we use external logging tool(Dlt Viewer).
Thanks in advance.
Hi,
Thank you for your comment. The callstack which you gave seems correct. I never used ethernet so I won’t be able to answer your query.