DCM

Diagnostic Communication manager

here this is a Full Guide form concept to implementation

What is the DCM ?

DCM is the manager responsible for managing the diagnostic communication management(manage the most upper layer) between the Tester tools and the ECU for that it is implementing the diagnostic Standard services (UDS / OBD ) and communicating with other modules to retrieve the needed data or execute specific routine.

In AUTOSAR Doc “ DCM is a BSW module that provide Common APIs for Diagnostic Services that used by external diagnostic tools

Where is DCM in the OSI module?

DCM as AUTOSAR specification is telling us

layer 7[application layer (UDS,OBD]

layer 5[ session layer]

presentation layer is not implemented in AUTOSAR Stack

Layer 4 [ transport layer (CANTP )]

layer 2 [ Data link layer(CANIF)]

(hint for each layer the implement a specific type of ISO standard will change its name ) by adding specific info into the payload

DSL (Diagnostic session layer)

the most bottom layer is DSL and this is the layer that interacts with the lower layers in AOTUSAR DIAG stack and from its name it maintains the session control and we will talk more about it later.

DSD (Diagnostic service layer )

in this layer from it’s name also here we start talk about a service, here we do some basic checks for example if the service is supported or not. Check the security level for the requested service and if it is supported in current session or not

DSP(Diagnostic service processor )

here we also do the remaining checks if the subservice is supported or not also perform the actual implementation for the requested services.

here in this subcomponent the actual and the core implementation for the requested services is implemented in this layer.

As you see this is the deeper look for the DCM inside as the main interactions for each submodule

DSP has a lot of interfaces with other component as this the processor of the diagnostic protocol so it may need to call other modules to perform the requested action as interfaces with memory or Dem to read error logs from it and so on.

DSL as you see here in the gateway for the DCM with the outside world and handle all the session checks as the current active session(this include a timing checks actions) or the current security level

Let’s talk about each submodule in details

DSL Functionalities and use cases:

Communication mode management
Resource Management
Request/response handling and forwarding(important)
Track and manage the current diagnostic states
Management the timing parameters (important)

DSL as it the lower layer and we are in Server - Client communication topology

So the Session timing handling is done by DSL as it is the lower layer and it see all the traffic and all the requests and responses is pass through it so it is the best one that handle the session timing parameters

So as we are a server in the network so we need to add some contains for the active session control and for maintain some basic securities

For example we need to add some contains as a maximum time the programming session will be open form the request it until any request/response is performed

Dsl also with PduR start to receive the complete request before forward it to Dsd

We have 2 types of timing (S3 timing - P2 timing )

First we will talk about P2 timing :

Here we have two timing (P2servermax and P2*servermax )

P2servermax - > this is the maximum time the tester tool will wait for the response

P28servermax - > this is the maximum time will the tester tool will wait for the response if the server need some time to handle the service(by sending NRC 0x78) pending NRC for example the erase routine

The number of consecutive pending 0x78 is configured and if it is zero so it is unlimited number

Now let’s talk about the another timing parameter it is S3 server

This time use to maintain the non-default session opening time

So the server or Dsl will start this timer from the session requested and reset only in the following conditions After response is been sent or service 0x3E is received

So if there is any new request from the client Dsl will monitor S3server timer if it is elapsed then it will return to default session

Autosar section 7.3.4.13 will talk more about active non-default session control

DSD (Diagnostic Service Departure):

This submodule is responsible for doing some checks that if we receive supported SID or not

Then check suppressed bit

Then check if this SID is supported in current session and security level

And the last check is service mode dependencies and format .

Then if all these check are passed then will forward this message to Dsp

Dsd has some NRCs returned from it I will list all the services for each submodule and the returned NRCs

Dsd Use cases (from AUTOSAR SWS Document) :

• Receive a request message and transmit a positive response message

• Receive a request message and suppress a positive response

• Receive a request message and suppress a negative response

• Receive a request message and transmit a negative response message

• Send a positive response message without corresponding request

• Segmented Responses

• Receive a request message and transmit a positive response message

Basic functionality of Dsd

Receive the complete request for the tester through Dsl then start to check the request validity

If the request is valid then forward it to the Dsp and wait for the response then forward it to Dsl

• Receive a request message and suppress a positive response

So if Request is valid and service is fulfilled and in request message SPRMIB is set to 1 then no response is sent by DCM and its made sure by DSD.

In this case if a negative response is generated then its sent to Tester

• Receive a request message and suppress a negative response

In case of functional addressing the DSD submodule shall suppress the negative response for certain NRCs. They are follows: ( 0x11 - 0x12 - 0x31 - 0x3E - 0x7F )

• Receive a request message and transmit a negative response message

The NRC hierarchy and priorities are given in ISO14229-1 UDS document and we shall learn about them later

• Send a positive response message without corresponding request

This is done by two services ( 0x2A[ReadDatabyPeriodicIdentifier] - 0x86[ResponseOnEvent] )

Dsp ( Diagnostic service Processing )

If the request reached here this mean that all basic checks is done by Dsd is passes and now we ready to execute the actual service implementation or call another module that will handle it

So the following checks also is done here in Dsp submodule

Now I will list some supportive information

1 - all NRCs supported by each Submodule in DCM

DSD supported NRCs based on the checks that performed by Dsd here is the list of NRCs that may be returned by Dsd if the request is not forward to DSP[0x11 - 0x33 - 0x3e -0x3F ]
DSP supported NRCs [ 0x12 - 0x13 - 0x22 - 0x24 - 0x31 - 0x35 - 0x36 - 0x37 - 0x72 ]

2 - list all services that handled by each subcomponent

DSL SIDs [ 0x3E - 0x10(partially) - 0x27 - 0x28 - 0x83 ]
DSD SIDs [ there is no specific SID handled in this submodule ]
DSP SIDs handle all the remaining SIDs defined by UDS iso standard

[ diagnostic management - data transmission - stored data trans - i/o control - upload/download ] services.

3 - supported configurations for each Submodule

1 - timing parameters [s3 - P2servermax - P2*servermax]

2 - buffer management [size] as it is interact with PduR

3 - protocols and connections

4 - state management [ session - security states]

1 - Service Table and service identifier

2 - access permission for each service

3 - service availability

1 - DIDs and RIDs

2 - Security access

3 - memory access

5 - the relation between suppressed request and addressing ( physical or functional )

Physical addressing - > one to one and Functional addressing – > one to many

Positive response is always sent and the only way to unsent it through suppressed bit in the request

Negative response is always sent in physical addressing

But the functional addressing only has a special response handling for negative response UDS ISO 14229 mandate that certain negative response must be suppressed

[0x11 - 0x12 - 0x31 - 0x7E - 0x7F ] all other NRCs may be suppressed section(7.4.2.2)

As the DCM location it is indicated that is a network independent so the network handling is the purpose of PduR

Dcm implement UDS but it is not mandatory so DSP as we will see later will interact twill other external modules to obtain and handle the requested services or maintain the bus mode or ECU specific role in BswM

DCM Limitations AUTOSAR V4.3

Parallel requests is not supported (and I will discuss a use case on it )
ResponseOnEvent is not supported
Service 0x84 also is not supported

All other limitations is listed in section 4.1 in SWS AUTOSAR Document

Let’s deep dive into DCM module :

DCM functionality is divided into 3 logical submodules :

Dsl (Diagnostic session layer) - Dsd(Diagnostic service layer ) - Dsp(Diagnostic service processor )

The request flowcontrol

Tester tool - > PduR - > DSL - > DSD - > (DSP | Application)

The response flow control

(DSP | DSD ) - >DSD - > DSL -> PduR -> tester too

Practical example and use case on DCM request

here in this example the tester tool will try to update the VIN (Vehicle Identifier number using service 0x2E)

here VIN is 17 byte long se we need CANTP protocol to handle this request on both communication sides (CANTP is implemented against ISO 15765-2)

CANTP will fragment this request in first frame and consecutive frames and the first frame will contain the SID and DID with a part of VIN number the remaining part will be send in a consecutive frame

DCM will be start to initiate a communication request with DSL so DSL will check this request preconditions and if it valid then will copy the received data with Dcm_CopyRxData() into buffer until the receiving all consecutive frames are received by calling Dcm_TpRxIndication function is called by the CanTP

then Dsp Will start to read the received data and call the configured Dsp Processor for the requested DID

Page updated

Google Sites

Report abuse