After reading this article you will understand.
1. What is use of DCM module of AUTOSAR.
2. Positive response and Negative response
3. Description about DSP DSD and DSL
4. DCM Module configuration in AUTOSAR.
3. Configuration of DSP :
1. What is use of DCM module of AUTOSAR.
2. Positive response and Negative response
3. Description about DSP DSD and DSL
4. DCM Module configuration in AUTOSAR.
1. AUTOSAR DCM Module :
In case of vehicle diagnostics, diagnostic tester tool sends a diagnostic request to ECU and ECU responds to diagnostic request. Diagnostic request handling is performed by DCM module of AUTOSAR. 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).
Negative response format and NRC codes are defined by UDS protocol ISO14229-1. Incoming service request number and service request format and positive response format defined in ISO 14229-1.
Fig.1 DCM AUTOSAR |
Fig 1 shows shows diagnostic request response flow through AUTOSAR stack. Request from tester tools received by PduR and PduR transmits requested message to DCM module. Then DCM takes action on requested message and communicated with SWC via RTE (if required) or DEM module to read snapshot data in case of $19 or other BSW modules.
DCM checks security level and session access of requested service. Checks service is supported or not, validates length of requested message. For valid process, invokes certain action based on requested service and provides response to tester tool via PduR. DCM is subdivided into three parts shown in fig. 2, activities mentioned above performed in different parts of DCM.
Fig. 2 DCM Sub-parts |
DCM sub-parts are and their functionality is as per ISO14229 document.
1. Diagnostic Session Layer (DSL)
2. Diagnostic Service Dispatcher (DSD)
3. Diagnostic Service Processor (DSP)
1.1 Diagnostic Session Layer (DSL) :
As shown in figure 2. DSL communicates with PduR module, accepts incoming diagnostic request from PduR and sends request to DSD sub module. Receives response from DSD sub module and sends to PduR.
Functionalities of DSL :
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.
1.2 Diagnostic Service Dispatcher (DSD) :
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.
Functionalities of DSD :
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
1.3 Diagnostic Service Processor (DSP) :
DSP receives service request from DSD sub module, performs check and executes a particular action based on request (Acquire data or execute required function in DEM or SWCs) and assembles response and sends to DSD.
Functionalities of DSP :
1. Once message from DSD is received check for message format (NRC 0x13) check subfunction supported before execution of particular function. (Checks Sub-function is supported or not. Checks against service table and checks sub-function is present in service table or not. Sends NRC 0x12 sub-function not supported)
2. The DSP sub-module shall assemble the response message excluding response service identifier
3. Service implementation (i.e. UDS service implementation e.g. implementation service 0x19 or 0x 10 as per ISO14229)
2. Diagnostic Request and Response :
A tester tool is connected to ECU via bus interface, bus interface may be CAN or Flexray. i.e UDS over CAN or UDS over Flexray. Diagnostic tester tool sends command or fires a command i.e. called as request message. Format of request message for each UDS service is defined in ISO 14229-1. Requested message contains service ID and service IDs defined by ISO14229-1 documents. Format of response message is also defined by ISO14229-1
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.
3. DCM Configuration :
DCM is all about diagnostic request and response. So while configuration of DCM module you must know services supported. Security access and session state of each service. To configure DCM means, you need to configure DSD DSL and DSP.
1. Configuration of DSD :
As name suggests Diagnostic Service Dispatcher, DSD contains service table, where all supported services and sub services added with security and session access.
2. Configuration of DSL :
a. Diagnostic buffer configuration required for Rx and Tx diagnostic request and response.
b. Configuration of Tx and Rx PduRs
c. Configuration of Protocol
d. Protocol timing configurations
3. Configuration of DSP :
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).
Note: SWS version of DCM module used for reference to explain configuration and DEM concepts in this blog is 4.0.1
Excellent description.Thank you
ReplyDeleteThanks a lot for the posts, we need more details plz
ReplyDeleteThank you Tbatou Driss. Sure I will add more details. Please let me know what you would like to know about.
ReplyDeleteNegative response starts from 7F followed by service ID and NRC. Ex: 7F 22 7F.
ReplyDeleteThank you for feedback. Corrected the typing mistake.
ReplyDeleteHi Padmanabh one correction in Functionalities of DSL point 3
ReplyDeleteKeeps track of current session, if current session is not default session (i.e. it may be programming or Extended session) then checks for server timeout and if server timeout occurs resets the session to default session.
can you please explain configuration of CAN driver to DCM module?
ReplyDeleteI don't have enough experience in configuration of CAN Driver, but there is can hardware object for Diag Request and Diag response, and PDU for Diag Request and Response is routed to DCM.
ReplyDeleteFunctionalities of DSP and dsp configuration varies in your explanation. Kindly cross check
ReplyDeleteKindly requesting post about Ethernet Stack and Ethernet Protocol
ReplyDelete