AUTOSAR Module DCM — Diagnostic Communication Manager

• DCM is a BSW module which provides functionality to handle diagnostic requests from external diagnostic tool.
• DCM handles communication between tester tool and ECU.
• DCM validates incoming request then processes valid request and if request is valid and processed correctly then DCM sends Positive response with requested data. If DCM detects invalid request, DCM sends Negative response with Negative Response Code (NRC).
• The DCM module is network-independent.

AUTOSAR DCM

Common Diagnostic terms in 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.
• Some of the examples of Diagnostic Services are as per below table:

2. Diagnostic Request and Response :

• Diagnostic tester tool sends command or fires a command i.e. called as request message. Format of request message for each UDS service, which is defined in ISO 14229–1, is called Diagnostic Request.
• Requested message is checked validated by DCM and if message is validated, positive response is generated. How to identify response is positive? If service fired is 0x10 in response you will get 50. i.e. received response starts from ServiceID + 40.
• If requested message is invalidated or processed incorrectly then DCM sends negative response with NRC. Negative response starts from 7F followed by service ID and NRC. If you fire command 22 FD 78 (read DID FD78), service 0x22 is not supported then DCM will send negative response 7F 22 11. 11 is code for service not supported. NRC codes for each service can be found in document ISO 14229–1.
• So, any kind of response whether Positive Response or Negative Response is known as Diagnostic Response.

DCM is further sub divided into following modules:

1. Diagnostic Session Layer (DSL)

2. Diagnostic Service Dispatcher (DSD)

3. Diagnostic Service Processor (DSP)

DCM Sub-Modules

Following is the diagram for the DCM sub module interaction:

DCM sub-Module Interaction

Diagnostic Session Layer (DSL):

• DSL sub-module is developed in conformance with ISO 14229, hence its implementation is completely network or bus independent.
• Diagnostic protocols have strict timing requirements for perfect communication, DSL also guarantees to achieve such timing requirements.
• Diagnostic buffer configuration for Rx & Tx diagnostic request & response.
• It is also responsible for the configuration of diagnostic protocol used in the ECU as well as PDURs for Tx & Rx.
• 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.

Following are the configuration to be done in DSL module:

1. Diagnostic buffer configuration required for Rx and Tx diagnostic request and response.
2. Configuration of Tx and Rx PduRs.
3. Configuration of Protocol.
4. Protocol timing configurations.

Following are the functionalities of DSL module:

1. Implements concurrent tester present logic

2. Reads current security level of ECU. Reads current diagnostic session state of ECU Resets or sets new security level and session state of ECU

3. Keeps track of current session, if current session is not default session (i.e. it may be programming or default session) then checks for server timeout and if server timeout occurs resets the session to default session.

4. Handling of different diagnostic protocol. i.e. DSL distinguishes between OBD or UDS protocol so you can configure OBD or UDS protocols, or UDS protocols with different sets of services and and assign them to different diagnostic protocols.

5. DSL is responsible for NRC 0x78

6. Protocol timings can be modified ( P2, P2*)

7. Forward response from DSD sub-module to PduR.

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.
• DSD sub module receives incoming diagnostic request by DSL module. DSD validates requested service and sends request to DSP sub module. Also gathers response and sends to DSL sub-module.
• 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. 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.

Followings are the configuration of DSD module:

• DSD contains service table, where all supported services and sub services added with security and session access.
• Configuration related to adding service table i.e. which services & sub-services are supported in the ECU is to be added in the DSD container.
• Also, for each services & sub-services, appropriate session access and security access also need to be provided in the DSD container which means that particular services & sub-services will give Negative Response, if appropriate session and security access criteria are not met.

Following are the functionalities of DSD module:

1. Checks Security and Session access of incoming request. i.e. if ECU is in default session and request should be executed in extended session then DSD sub-module sends NRC 0x7F (Service not supported in actvie session)
2. Sends positive response or send negative response or suppress response.
3. Checks whether service is supported or not. (If service 0x22 is not configured and tester tool sends 0x22 service then DSD sub-module should check service table for supported services and sends NRC 0x11 if service is not supported)
4. DSD sub-module collects positive or negative response from DSP sub-module, adds diagnostic service identifier and response data returned by application and forwards diagnostic response message to DSL sub-module

Diagnostic Service Processor (DSP):

• DSP 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.
• 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.

Followings are the configuration of DSP module:

1. DSP contains configuration related to services. i.e. configuration related to service no.22 (for service no. 22 configuration of DID need to be performed) or configuration related to service no. 31 (for service no. 31, routine need to be add. Need to configure start stop request).

Following are the functionalities of DSP module:

1. 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.
2. 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.
3. 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.