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 (0x10) 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!

8 thoughts on “Diagnostic Communication Manager”

  1. Chris

    Can you tell how to use Da Vinci tool? such as how to configure CANTp. My biggest puzzle is how to use the tool to get the functionality I wanted.

    Reply
    1. Admin_Alpha

      Hi Chris,

      Thank you for reading autosartutorials.com, I would love to add a tutorial on it but there are license complications which don’t allow me to do it. But I am trying.

      Reply
      1. azmat Imtiyaz mulla

        Please explain the complete request and response with service
        With each function what does that data mean like if @10 is a service for default session what response will come give two examples

        Reply
  2. Nedun

    Please correct the Diagnostic Session Control (0x22) to (0x10) it’s wrongly typed under Verification Functionality of DSD submodule

    Reply

Let me know your comments or doubts...

This site uses Akismet to reduce spam. Learn how your comment data is processed.