AUTOSAR Diagnostics

Diagnostic Communication Manager

Diagnostic Communication Manager (DCM)

Translate in your language

Background:

As per Murphy’s Law, if anything that can go wrong, will go wrong! 🙂 So considering this, we have to prepare for problematic situations while developing any ECU software because things can go wrong. 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. Some sophisticated applications have services which implements service sessions which are grouped by user access role and security in such debug or diagnostic communications. Such applications implement these Diagnostic services to allow tester, or diagnostic engineer to get information from ECU regarding error occurred, or status or general information. These services are used by external diagnostic tools which sends diagnostic request to ECU and ECU replies with desired information.

Since AUTOSAR aims in standardizing software development of ECU, almost each component is standardized in it, hence Diagnostics is no exception. AUTOSAR has Diagnostic Communication Manager (DCM) as the name suggests, is a part of communication services which is used in providing Diagnostic services. 

The reader is expected to have knowledge of UDS and OBD protocol before proceeding further.

DCM in detail:

Diagnostic Communication Manager (DCM) is a basic software (BSW) module which is also a part of Com Stack and lies in Communication Services block, provides the functionality to handle diagnostic requests from external diagnostic tool. AUTOSAR DCM supports standard diagnostic protocols like UDS – ISO14229-1, OBD – ISO15031-5 over CAN, FlexRay and MOST bus. DCM module provides common APIs for diagnostic services, this functionality may be used during development or manufacture or service and maintenance of vehicle. DCM module is responsible for ensuring diagnostic data (messages) flow and managing diagnostic states, especially diagnostic sessions and security states.

DCM highlighted in COM Stack
Fig: DCM highlighted in generic COM Stack

Above figure depicts the location of DCM in AUTOSAR Com Stack and its a generic block or network independent block which is instantiated only once. All network (CAN, FlexRay, MOST) specific operations are carried out in network dependent blocks. DCM is above PDU router (PduR) and it receives diagnostic request message from PduR. The DCM module processes this message and checks if it is supported. If it is supported, then DCM communicates with BSW modules or SWCs via RTE to get information if required or execute commands to satisfy the received diagnostic request. After gathering the information required, DCM assembles the reply message and sends it via PduR. 

Typically, the client has to send diagnostic request messages to ECU (DCM) using a special diagnostic tool which understands UDS or OBD protocol. Diagnostics are used during manufacturing, during service (Its obvious! 😀 ), or during development. Figure below gives pictorial overview of diagnostic with AUTOSAR based ECU.

Fig: Overview of  communication between diagnostic tool and AUTOSAR DCM
Fig: Overview of communication between diagnostic tool and AUTOSAR DCM

Sub-modules of DCM:

Sub-modules of DCM
Fig: DCM divided in sub-modules

The DCM module is further divided in sub modules like:

  • Diagnostic Session Layer (DSL): DSL sub-module is responsible for ensuring smooth data flow of diagnostic requests and responses. Diagnostic protocols have strict timing requirements for perfect communication, DSL also guarantees to achieve such timing requirements. Diagnostic protocol like UDS has diagnostic sessions and states which allows controlling access to information and requests grouping, DSL also handles this work.
  • Diagnostic Service Dispatcher (DSD): DSD sub-module as the name suggests, acts like a dispatcher whose work is to forward received diagnostic requests to Diagnostic Service Processor (DSP) and forward diagnostic responses received from DSP to DSL for transmitting it over network.
  • Diagnostic Service Processor (DSP): DSP sub-module is the main part of DCM where diagnostic requests are processed and actions are taken on the requests as needed and a response is generated. DSP get diagnostic request message from DSD and DSP transmits the response to DSD.

Lets understand each sub-module in detail:

Before going any further first lets understand some terms of UDS

1.Diagnostic Services:

Diagnostic services are services given in UDS protocol which the DCM module has to support. These services are nothing but diagnostic requests sent by diagnostic tool to get some information or status or do some setting. Each service is denoted by service ID and while requesting information for a specific service, we have to pass the Service ID (SID) from diagnostic tool.

2.Diagnostic Session:

Diagnostic session is a term used in UDS to indicate a activity window based on time dedicated to perform diagnostic activity with ECU. Types of diagnostic sessions are:

  1. Default Diagnostic Session
  2. Programming Session
  3. Extended Diagnostic Session.
  4. Safety System Diagnostic Session.

Every session supports a specific type of diagnostic service. On startup, default diagnostic session is active and different sessions can be accessed as and when requested by diagnostic tool. Some services are available under Default Diagnostic Session or some which can be used to program ECU are available under Programming Session. Now lets continue with understanding sub modules of DCM.

1. Diagnostic Session Layer (DSL):

DSL sub-module is developed in conformance with ISO 14229-1 [9] and ISO 15765-3 [12], hence its implementation is completely network or bus independent. DSL module helps in session handling, taking care of accurate timings as required by protocol, and managing security. DSL interacts with different other modules to achieve its tasks, modules like:

  • PduR: DSL module receives diagnostic requests from PduR and DSL module sends the response for the diagnostic request to PduR
  • DSD sub-module: DSL sub-module informs DSD of incoming diagnostic requests and provides the data. DSL also receives response for diagnostic request from DSD which it forwards to PduR further.
  • SWCs or DSP submodule: DSL module provides access to security and session state.
  • ComM module: DSL sub-module has to take care of accurate communication timings, it achieves it with the help of ComM. 

Lets study in detail functionalities provided by DSL:

  • Forward requests from PduR to DSD module: Diagnostics have their own PDUs (for both TX and RX) with their own unique PDU ID, whenever a new diagnostic request reception starts on any of the diagnostic PDU, PduR indicates this to DCM. PduR communicates this information to DSL sub-module which is further forwarded to DSD (Diagnostic Service Dispatcher). PduR requests the buffer to be filled with diagnostic request from DCM module using API: Dcm_ProvideRXBuffer() ,PduR also provides the number of bytes expected to be received This API never returns the filled buffer until its fully filled with expected amount of bytes. After complete reception of diagnostic request (successful or with errors), PduR module calls the Dcm_RxIndication() API to give a receive indication to DCM. After completely reception of request from PduR, DSL blocks this DCM PDU ID (received PDU ID) and new requests from same protocol type, for instance if a UDS type session is going on, new requests of UDS cannot be received.  
  • Concurrent “TesterPresent”: The DCM automatically resets the ongoing diagnostic session and enters into default session if no exchange of data is taken place between DCM and Tester tool for a specific period. To resolve this, ISO14229-1[9] implements a “keep alive logic” which is a service implemented in UDS called as TesterPresent, client (tester tool) sends this request to DCM to indicate client is still present. DCM don’t send any response for this request as its use is to just indicate that client is present. DSL also don’t forward this to DSD as there is nothing of interest in this request.
  • Forward responses from DSD to PduR: DCM sends its response to tool in a dedicated TX PDU with unique PDU ID via PduR. DSP (sub-module of DCM) sends this response to DSD which is further forwarded to DSL and lastly DSL forwards this to PduR. The request and response PDU IDs are linked with each other during DCM configuration, this guarantees correct response to request received. The DSL module forwards the response PDU to PduR only after the minimum specified delay between request reception and response. DSL uses PduR_DcmTransmit() to indicate length information of response PDU to PduR. After reception of this information, PduR module calls Dcm_ProvideTXBuffer() to request DCM module for the response PDU to be transmitted.
  • Guarantee timing to tester by sending busy responses: Many times the diagnostic request takes more time for processing, in that case if there is no communication from server (DCM) to tester tool for specified maximum response time, it may think the ECU is not responding and end diagnostic session. To resolve this, DSL sends busy responses to tester tool periodically until the request processing is not completed. The busy response is a negative response (protocol) with NRC (Negative response code) 0x78 which means Response pending. DSL uses a separate buffer to send such busy responses. But this may lead to deadlock 😀 , so to avoid deadlock, during configuration integrator can set the maximum busy responses by setting  DcmDslDiagRespMaxNumRespPend configuration parameter. If the number of busy responses if greater than this parameter, DCM module stops the processing of that request and sends the negative response NRC 0x10 which indicates General Reject.
  • Support of periodic transmission: The UDS has a service to let tester request periodic transmission of data record values from ECU. DSL module handles this request in two ways: 1. If any request processing is going on and using the same PDU ID which is to be used for periodic transmission, DSL would allow such requests only after completing the processing of ongoing request; 2. Or if configured to use separate PDU ID and protocol, the DSL allows this request and sends on separate PDU (which is not used for normal diagnostic requests). 
  • Support for ROE transmission: The UDS has a service named ResponseOnEvent (0x86) using which the tester can request the ECU to start and stop transmission of responses initiated by a specified event. When registering transmission based on event, the tester has to specify the corresponding service to which response is to be sent. 
  • Support of segmented response: When there is a need to send responses that are greater than configured and allocated diagnostic buffer, DSL can segment the response data in pieces and sends the response. With this, the ECU can save memory because there won’t be any need to allocate big buffers for big responses. This segmentation is supported on in sending responses, i.e. segmented requests are not supported by DSL.
  • Support of ResponsePending response triggered by the Application (SWC): In some cases, the application needs to send immediate ResponsePending responses unlike above described functionality for sending busy responses in which the DSL waits for the minimum time between request and response. This can be used in flash programming scenario, application will send ResponsePending before entering into bootloader.
  • Manage Security Level: DSL sub-module provides interfaces to get current security level and also to sent new security level. DSL module also saves the current active security level. During DCM initialization, the security level is set to 0x00 this means ECU is locked for that period !
  • Manage session state: DSL provides interfaces to get current active session and also to set a new session. During DCM initialization, the session state is “Default Session”. DSL module saves the state of current active session.
  • Keep track of non-default sessions: Whenever  a non-default session is going on and the session timeout occurs without receiving any diagnostic request, DSL module resets the current session and enters into default session.
  • Informs depending modules of session change: Whenever a session change occurs, DSL notifies the corresponding module involved in that session regarding the session change.
  • Allow to modify timings: As DSL is the one to take care of timing requirements of protocol, it allows to modify timings of session layer as the protocol related timing parameters has no influence on Transport layer. To modify timings of protocol, UDS has defined following services: UDS Service DiagnosticSessionControl (0x10) and UDS Service AccessTimingParameter (0x83). 
  • Handling of different diagnostic protocols: DCM as said in introduction, supports different diagnostic protocols like UDS or OBD, etc. DSL sub module handles this. 
2. Diagnostic Session Dispatcher (DSD):

The DSD sub-module is responsible for checking the validity of an incoming diagnostic request. Validity here means verification of Diagnostic Session or Security Access levels or Application permission. This validation helps in processing only valid requests and rejecting invalid requests . DSD sub-module also keeps track of ongoing diagnostic request processing. DSD sub-module interacts with other sub-modules as followed:

    • DSL: DSL calls the DSD sub-module when received a new diagnostic request message. DSD then forwards this request to DSP and keeps track of ongoing request processing. It also transmits the response of DSP to DSL. DSD sub-module also calls DSL to get latest diagnostic session and security state. DSD module also get the confirmation of transmission response message from DSL.
    • DSP: DSD delegates the received diagnostic request (if valid) and also sends confirmation of transmission of response message to DSP. DSP module sends signal to DSD after processing of diagnostic request is done.

Lets understand the functionalities provided by DSD sub-module:

  • Support checking the diagnostic service identifier and adapting the diagnostic message: DSD validates the received diagnostic request message from DSL and if supported it is forwarded to appropriate DSP or else it is rejected by sending negative response. Every diagnostic request has a Service Identifier(SID) to indicate the type of request. DSD has the Service Identifier Table which has predefined supported SIDs, this table is generated after configuration and is provided by DSL. DSD checks this received SID from request in the Service Identifier Table and if received SID is present in the table, it is forwarded to appropriate DSP or else it is rejected by a negative response with NRC 0x11 i.e. Service not supported to the DSL.
  • Handling of suppression of positive response message: UDS has a facility to suppress the positive response message reception on each successful procession of diagnostic request. This is handled by DSD. DSD checks if bit named “suppressPosRspMsgIndicationBit” in received diagnostic request is TRUE, if it is then DSD won’t send positive responses. This setting will be ignored if the busy responses is going on (refer DSL for more information on busy messages). 
  • Verification functionality: DSD sub-module is also responsible for verifying the received diagnostic request. DSD sub-module will only accept the diagnostic request if it passes three verifications:
    • Verification of Diagnostic Session: As discussed above, a diagnostic session is a activity window to perform diagnostics. Every session has a specific set of supported diagnostic services. On reception of a new diagnostic request, DSD will get the current diagnostic session information and will verify if the current received service request is allowed for current session. UDS service for DiagnosticSessionControl (0x22) is bypassed of this verification, or else the tester won’t be able to change the diagnostic session then 😀 ! If the received service request is not allowed in current diagnostic session, then DSD sends a negative response with NRC (0x7F) which means Service is not supported for active session.
    • Verification of service security access levels: Some diagnostic services have restricted security access levels. DSD sub-module takes care of verification of such services. When a new diagnostic request is received from DSL, DSD gets the current active security level from DSL and checks if the new diagnostic request is allowed for current security access level. If the received diagnostic request is not allowed in the current security level, then DSD sub-module sends a negative response with NRC (0x33). Again UDS service SecurityAccess (0x27) is bypassed this verification, or else the tester will never be able to access security restricted data 😀 ! If the received service request is not allowed for current security level, then DSD sends negative response with NRC 0x33 which means Security access denied.
    • Verification of the application environment or permission: Diagnostic cannot be performed if ECU state is not proper or if environment is not appropriate. Like in after-run ECU state, it is not allowed to process OBD requests.
  • Distribution of diagnostic message to DSP: If the diagnostic service passes all the checks (as described above), then DSD searches for a appropriate service executable functionality of DSP and calls the corresponding DSP service interpreter.
  • Assemble of positive or negative  response: DSD sub-module assembles the response for executed diagnostic request based on the response of DSP. If response is positive, DSD sub-module adds the response service identifier (same as that of the received diagnostic request SID) and response data (which is received from DSP) in the response message while assembling. Or if the response is negative, then DSD assembles a negative response message with NRC received from DSP.
  • Initiate Transmission: DSD sub-module forwards the response message to DSL sub-module for further transmission. When the DSL module receives the confirmation of transmission from PduR, it transmits this information to DSD. Which the DSD sub-module further forwards to DSP for its confirmation.
3. Diagnostic Service Processor (DSP):

DSP sub-module is the main module which processes the received diagnostic request from DSD sub-module. Upon reception of function call from DSD sub-module to process a diagnostic request, DSP analyzes the received request message, checks its format, checks if the requested sub function is supported, acquire necessary data from DEM, SWCs, or BSW modules, and lastly assemble response. 

Lets understand some steps:

  • Check format and subfunction support: The DSP module checks if the received request has appropriate message length and structure before processing the request. If the requested diagnostic message fails in format checking then DSP module triggers a negative response with NRC 0x13 to DSD. DSP module also checks whether a specific sub-function is supported before executing the service request. If its not supported, then DSP module triggers a negative response with NRC 0x12 to DSD sub-module. 
  • Assemble response: After processing the request, the DSP module assembles the response message (positive/negative) to be sent to DSD. The message is assembled without service identifier (because this is handled by DSD). DSP module confirms the completion of request processing to DSD.  

In this way, DCM works with its internal sub-modules like : DSL, DSD and DSP to perform diagnostics communication. DCM is more deep topic and has scope for understanding each supported diagnostic protocol, but for the sake of simplification, I have compiled DCM in most possible simple to understand way. 

I hope you understood DCM by reading this article. If you have any doubts or comments please let me know in comments. 

If you find any incorrect information please report it to me.

Thanks for reading 🙂 !

Like us on Facebook!

Subscribe for newsletters!

Diagnostic Log and Trace

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. 
Diagnostic Log and Trace block of Com Stack
Dlt_block in Com stack

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.

Dlt_msg_format
Dlt message format
Dlt_msg_std_header
Fig.2.2: Standard header of Dlt message format
Dlt_msg_ext
Fig.2.3: Extended header of Dlt message format

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 IDDlt Command NameDescription
0x01 SetLogLevelSet the Log Level
0x02 SetTraceStatusEnable/Disable Trace Messages
0x03GetLogInfoReturns the LogLevel for registered applications
0x04GetDefaultLogLevelReturns the LogLevel for wildcards
0x05StoreConfiguration Stores the current configuration non volatile
0x06RestoreToFactoryDefaultSets the configuration back to default
0x0ASetMessageFilteringEnable/Disable message filtering
0x11SetDefaultLogLevelSets the LogLevel for wildcards
0x12SetDefaultTraceStatusEnable/Disable TraceMessages for wildcards
0x13GetSoftwareVersionGet the ECU software version
0x15GetDefaultTraceStatusGet the current TraceLevel for wildcards
0x17GetLogChannelNamesReturns the LogChannel’s name
0x1FGetTraceStatusReturns the current TraceStatus
0x20SetLogChannelAssignmentAdds/ Removes the given LogChannel as output path
0x21SetLogChannelThresholdSets the filter threshold for the given LogChanne
0x22GetLogChannelThresholdReturns the current LogLevel for a given LogChannel
0x23BufferOverflowNotificationReport 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:

  1. Using Dlt interfaces to send Log and Trace messages
  2. 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:

Transmission steps of Dlt message
Fig.3. Transmission path of Dlt message

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:

  1. Generate timestamp: If configured, timestamp will be added to the message.
  2. 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.
  3. Select target LogChannel: Dlt module in this step, selects the target channel as per configuration for log message.
  4. 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.
  5. 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 🙂

Like us on Facebook!

Subscribe for newsletters!