autosar dcm

AUTOSAR DCM

Introduction To AUTOSAR Diagnostic Communication Manager

The AUTOSAR DCM is extending for Diagnostic Communication Manager. The functionality of the DCM module is used by external diagnostic tools during the development, manufacturing, or service. It ensures the diagnostic data flow and manages the diagnostic states, especially diagnostic sessions and security states. Furthermore, it also checks if the diagnostic service request is supported and if the service may be executed in the current session according to the diagnostic states. This AUTOSAR DCM tutorial will help you to learn how to work with the DCM module. This Tutorial is following the AUTOSAR DCM 4.3.

Block Diagram Of AUTOSAR DCM Module

The below figure shows how the AUTOSAR DCM module is communicating with other modules in BSW layer.

autosar dcm block diagram
AUTOSAR DCM Block Diagram

In the Communication process, the AUTOSAR DCM receives a Diagnostic message from the PDU Router. In DCM, internally the Diagnostic message will be processed, checked, and handed on to the AUTOSAR Software Components for further processing. Depending on the Diagnostic service Identifier the corresponding calls in the Application Layer will be done. The DCM shall be network independent. This requires a network independent interface to the PDU Router (which handles the networks CAN, LIN, FlexRay).

DCM Module Design

The AUTOSAR Diagnostic Communication Manager (DCM) provides a common API for diagnostic services in the AUTOSAR Basic Software. The DCM receives a Diagnostic message from the PDU Router. DCM internally the Diagnostic message will be processed, checked, and handed on to the Autosar SW Components for further processing. Depending on the Diagnostic service Id the corresponding calls in the Application Layer will be done. The design of the DCM module consists, of both High-Level Design (HLD) and Low-Level Design (LLD).HLD specifies, the identification of APIs needed for the implementation of DCM, and the LLD points out the detailed design of APIs.

The purpose of the Diagnostic Service Dispatcher (DSD) is to process a stream of diagnostic data. Receive a new diagnostic request over a network and forward it to a data processor. Transmit a diagnostic response over a network when triggered by the data processor. The Diagnostic Session Layer (DSL) ensures data flow concerning diagnostic requests and responses. DSL also supervises and guarantees diagnostic protocol timing. Furthermore, DSL manages diagnostic states (esp. diagnostic session and security). The Diagnostic Session Layer (DSL) ensures data flow concerning diagnostic requests and responses.

DSL also supervises and guarantees diagnostic protocol timing. Furthermore, DSL manages diagnostic states (esp. diagnostic session and security) and communications states required by the Communication Manager. The DSP provides an interface to the DSD and implements various diagnostic services as defined for different protocols like UDS or OBD. DSP – Process specific Service (respectively Sub Service) Requests. The DSP is mainly a container for completely implemented diagnostic services that are common amongst the different applications (e.g. access to the fault data) and thus do not need to be implemented by the application.

Components Of DCM

The Diagnostic Communication Manager (DCM) is an intermediate layer between the application and the vehicle network communication (CAN, LIN, FlexRay and MOST) which is capsulated by the PDU Router. The DCM has an interface with the PDU Router. The DCM itself is network independent. So the protocol and message configuration will be done in layers below the DCM. DCM module as consisting of the following 3-submodules:

  1. Diagnostic Session Layer.
  2. Diagnostic Service Dispatcher.
  3. Diagnostic Service Processing.
AUTOSAR DCM Sub-Modules Interface Diagram

Diagnostic Session Layer (DSL) In AUTOSAR DCM

The DSL submodule ensures data flow concerning diagnostic requests and responses, supervises and guarantees diagnostic protocol timing, and manages diagnostic states (especially diagnostic sessions and security).

Functions Of DSL In AUTOSAR DCM

  • Diagnostic Session (0x10) layer handling as required by ISO 14229-1 or ISO 15765-3 standard.
  • Simply it handles the implementation of concurrent Tester Present (0x3E) logic.
  • Security Level Management: The DSL Reads the current security level, diagnostic session state of ECU. It also set or resets the new security level and session state of ECU.
  • It keeps track of the current session: If the current session is not the default session (i.e. it may be programming or Extended Diagnostic session) then it checks for server timeout. If the server timeout occurs, it resets the session to the default session.
  • Handling of the different diagnostic protocols: That means the DSL distinguishes between OBD, UDS, or KWP protocol. So we can configure either OBD or UDS protocols, or UDS protocols with different sets of services and assign them to different diagnostic protocols.
  • The Diagnostic Session Layer is also responsible for NRC 0x78.
  • The Client-server communication parameters are handled in the Diagnostic Session Layer. That means the P2 Timer, P2* timer, etc. can be modified in this module as required by ISO 14229-1 or ISO 15765-3. It uses the UDS Service Access Timing Parameter (0x83) for the time change.
  • It also forwards all the response messages from the DSD sub-module to PduR as required in ISO 14229-1 or ISO 15765-3).
  • Support of periodic data transmission: In UDS Protocol is having a service by which the tester can request periodic data transmission from ECU or Server. There are two ways to handle this.
    • If there is any process is ongoing in ECU and the same PDU ID is going to use for periodic transmission. The DSL will allow such type of requests after the completion of the processing requests.
    • If the PDU ID is configured separately for protocol, then it can send immediately with another PDU ID. But this is not used for normal diagnostic requests.
  • It supports Segmented Response: If there is a response message which is more than the configured and allocated buffer size, then the DSL will divide it into multiple responses and send it. Remember that the segmented request feature is not supported by the DSL.
  • It supports Response On Event Transmission: The DSL layer handles the start or stop of any periodic transmission data initiated by a special event of 0x86 service.
  • It Informs session change to Other Dependent modules: If there is a change in the diagnostic session, DSL notifies it to the corresponding module regarding the session change.

Diagnostic Service Dispatcher (DSD) In AUTOSAR DCM

The Diagnostic Service Dispatcher sub-module receives all the incoming diagnostic requests by the DSL sub-module. It also validates all the requested services and sends requests to the DSP sub-module. It also gathers all the response messages and sends them to the DSL sub-module.

Functions Of DSD In AUTOSAR DCM

The main functionalities of the Diagnostic Service Dispatcher layer are:

  • Checks the support of diagnostic service identifier and adapting the diagnostic message: The DSD validates the received diagnostic request messages from DSL. If it supports it will send it to the corresponding DSP layer or else it rejects by sending the negative response code 0x11. The DSD has the Service Identifier Table which has predefined supported Service lists. This table will generate after the completion of configuration and is provided by DSL.
  • Suppression Of Positive Response Message Management: If the client or tester doesn’t want the positive response message, then the client will set the “suppressPosRspMsgIndicationBit” bit of the diagnostic request message. This will get ignored if the busy responses are going on.
  • Service Verification Functionality: The DSD sub-module is responsible for the verification of each service received from the DSL layer. It has three verification steps, such as:
    • Diagnostic session Validation: Each session has its own services and sub-functions, that can support in the corresponding session. That means suppose if the ECU is in default session and request supports in the Extended Diagnostic Session, then the DSD sub-module will send NRC 0x7F (Service not supported in active session).
    • Security Access Service Validation: Due to data protection, some services are having restricted security access levels. The DSD checks the currently received request message from DSL with the currently active security level from DSL. If it matches, it allows, or else it will send the NRC 0x33. This checking is bypass only by the security access service (0x27).
    • ECU Environment Condition Validation: The diagnostic is not permitted if the ECU state is not proper, or the environment condition is not in the appropriate condition. For example, after ECU is in the run state, no OBD requests can be allowed.
  • Diagnostic Message Distribution to DSP: After the validation of a service, it searches for the specific DSP functionality and the call back function executes it.
  • Positive or Negative Response Message Assemble: The DSD sub-module assembles the response message for the executed diagnostic request based on the response of the DSP sub-module. If the response is a success, then it will add the 0x40 with request service and the data received from DSP. If it fails then it will add the negative response service 0x7F with the corresponding NRC received from DSP.
  • Initiate Transmission Of Response Message: After the successful assemble of the response message, it sends to the DSL sub-module for further action. Once the DSL receives the confirmation message from PduR, it forwards it to DSD, and the DSD again forwards it to DSP for transmission confirmation.

Diagnostic Service Processing In AUTOSAR DCM

The Diagnostic Service Processing sub-module does the actual diagnostic service work task. The Diagnostic Service Processing receives the service requests from the Diagnostic Service Dispatcher sub-module. Then it performs a check and executes a particular action based on the type of request. It basically checks what is the service identifier and what type of sub-function. So that it can acquire data or execute a required function in Diagnostic Event Management (DEM) or SWCs. Once it is completed, then it will assemble the response and sends it to the Diagnostic Service Dispatcher sub-module.

Functions Of DSP In AUTOSAR DCM

The main functionalities of the Diagnostic Service Processing sub-module is:

  • It checks for diagnostic message format after receiving any message from Diagnostic Service Dispatcher (DSP). If it is not correct it sends the Negative response Code 0x13.
  • It also checks for sub-function supported or not if the message length is correct. Basically, it will check this Service Identifier and sub-function Identifier is available or not in the DCM service table. If it not supported, it sends the Negative Response Code (NRC) 0x12.
  • The Diagnostic Service Dispatcher is assembling the response message with all the data only except the Response Service Identifier.
  • Each service implementation is done in the DSP layer as per the ISO 14229 standard.

Diagnostic Session On UDS Protocol

The diagnostic session is the basis for communication between the ECU and the diagnostic tool. During ‘Diagnostics’ the ECU being analyzed is in a particular session. Basically, there are different types of diagnostics sessions:

  • Default Session.
  • Extended Diagnostic Session.
  • ECU Programming Session.

After Ignition on, all the ECUs will be switched to a Default Diagnostic Session and after receiving the request from Diagnostic Tool, the ECU will be switched to the Extended Diagnostic Session. Further, after receiving the ECU Programming Session start request from the Diagnostic tool, it will switch to the ECU Programming Session.

DCM Configuration In AUTOSAR

The AUTOSAR DCM module is mostly for diagnostic request and response messages. So before you start the configuration in the Basic Software (BSW) module, you should have sound knowledge of UDS or ISO 14229 standard. Next is your system requirements, which means what and all the services, sub-functions, NRC, etc. are supported in your ECU. So that you need to configure it as per this. Basically, you need to configure the DSL, DSD, & DSP.

Configuration Of DSL In AUTOSAR DCM

The Diagnostic Session Layer sub-module is responsible for the configuration of the below parameters. It needs to be

  • Configuration of Diagnostic buffer for Rx and Tx diagnostic request and response message.
  • The Tx and Rx configuration for PduRs.
  • Type of protocol and its parameter details configuration.
  • All the timing parameter configuration.

Configuration Of DSD In AUTOSAR DCM

The Diagnostic Service Dispatcher sub-module is responsible for the configuration of protocol service table. It is having below parameters.

  • Configuration of UDS protocol Service Identifiers supported in your ECU.
  • Sub-functions of each service supported for this ECU.
  • the diagnostic sessions configuration for supporting in your ECU.
  • All the security levels and accesses parameter configuration as per your ECU requirement.

Configuration Of DSP In AUTOSAR DCM

The Diagnostic Service Processing sub-module is responsible for the configuration of the parameters related to the services. It will configure the configuration related to the service number, sub-function, and data parameters. Suppose for service 0x22, all the supported Data Identifiers (DID) need to configure. You need to configure all the supported DTC for service number 0x19.

Low-Level Design of DCM

Low-level design is done by drawing the activity diagram or flow chart of APIs realized by the Diagnostic Communication Manager. It defines the internal logic of the APIs. The flow chart for some of the APIs that are realized are given below:

The configuration of the In AUTOSAR DCM module can be done by using different configuration tools like Davinci Configurator. The routing table is configured during the post-build time and the parameters corresponding to minimum routing are configured at link time.

This tool is developed by Vector, in order to build AUTOSAR compliant software for an ECU. The developer has to depend on configuration tools available in the market since the manual configuration is time-consuming. Moreover, each OEM would be having a specific requirement that needs to be achieved. These requirements can be achieved by extending the standard AUTOSAR specification like adding vendor-specific modules, containers, parameters, etc.

dcm module interface
dcm module interface

The Dcm.h file includes general Diagnostic Communication Manager (DCM) definitions. All the Type definitions of the DCM are defined in Dcm.h file. The Pre-compile-time configuration data of the DCM module is defined in Dcm_Cfg.h file. The Dcm_.h file includes the declaration of APIs of DCM used by different modules. The _cbk.h file declares the data types and APIs of other modules used by the DCM module. The Det.h, Dem.h, and Dem_IntErrld.h files declares the data types and APIs of DET and DEM used by the DCM module.

The ComStack_Types.h contains all types that are used by different modules of the communication stack of the basic software that is platform and compiler independent and Std_Types.h contains all types that are used by other modules of the basic software that are platform and compiler independent. The Compiler.h and Platform_Types.h file declares all the types used by different modules that are compiler and platform dependent. Dcm.c file defines all the APIs realized by the In AUTOSAR DCM module and its header file structure is given in Figure.

Dear AUTOSAR Engineers!!!

Please LET US KNOW HOW YOU ARE GETTING BENEFITED FROM PIEMBSYSTECH. IF YOU HAVE ANY QUERY, PLEASE ASK YOUR QUESTIONS IN OUR PIEST FORUM. PLEASE HELP US TO ADD SOME NEW POINT HERE IF ANYTHING IS MISSING OR IN NEWER VERSION OF AUTOSAR.
Scroll to Top