Diagnostic Communication Manager module

in AUTOSAR – DCM
In this article, we will discuss the Diagnostic Communication Manager (DCM) module in
AUTOSAR.

The DCM module ensures and manages the flow of diagnostic data along with diagnostic
sessions and security states. The DCM module services the request only after checking whether
the requested service is supported under the active the diagnostic session and under the active
security level.

The DCM module supports most of the services listed under UDS ISO-14229-1 and OBD ISO-
15031-5 standards.

The network specific functionalities are handled outside the DCM module making it a network
independent module. The DCM module receives a diagnostic request from the PDUR module. It
checks for the support of the service under the active session and states. If the service is
supported then it interacts with other BSW modules or SWC’s to collect the service response. It
assembles the response and sends it back through the PDUR module.

The DCM module can be subdivided into three sub modules like Diagnostic Session Layer
(DSL), Diagnostic Service Dispatcher (DSD) and Diagnostic Service Processing (DSP)
Diagnostic Session Layer (DSL): It manages the diagnostic sessions, security level and the protocol /
application layer timing. It also ensures the data flow concerning the diagnostic request and response.
This sub-module interacts with the PDUR module to manage the data flow. DSL informs the DSD about
the incoming request and provides the data.

Diagnostic Service Dispatcher (DSD): It checks the validity of the incoming service request
and also tracks the progress of the service request. If the diagnostic request is valid, it processes
the stream of diagnostic data. It receives the diagnostic request and forwards for data processing.
It transmits the response after data processing.

Diagnostic Service Processing (DSP): Manages the diagnostic service request. Analyzes the
requested service for the format (message length and structure) and subfunction support.
Interacts with other BSW modules and SWC’s to acquire the data required for the service
response. It also assembles the service response.
DSL Functionalities

DSL

Request Handling Forward requests from the PduR module to the DSD submodule.
Concurrent Tester-Present (keep alive logic).

Response Handling Forward responses from the DSD submodule to the PduR module.
Guarantee response timing to tester.
Support of periodic transmission.(Only handling of periodic messages triggered by SWC)
Support ResponseOnEvent(ROE) transmission.(Only handling event msg trigg by SWC)
Support of segmented response.
Support of ResponsePending response triggered by the application.

Security Level Handling Manage security level.

Session State Handling Manage session state.

Keep track of active non−default sessions.
Informs depending modules on session change.
Allows modifying timings.

Diagnostic Protocol Handling Handling of different diagnostic protocols. (UDS, KWP)

Manage resources.

Communication Mode Handling of communication requirements (Full/Silent/No COM)

Handling
Indicating of active / inactive diagnostic.
Enabling / disabling all kinds of diagnostic transmissions.
DSD Submodule:
The DSD submodule is responsible to check the validity of an incoming diagnostic request and keeps
track of the progress of a service request execution.

The DSD submodule provides the following functionalities:

 Receive a request message and transmit a positive response message

 Receive a request message and suppress a positive response
 Receive a request message and transmit a negative response message
 Send a positive response message without corresponding request
 Segmented Responses

DSL Module
Request Handling
Forward requests from the PduR module to the DSD submodule
DSL offers 3 API services for this purpose which are called by PDUR as shown in below order:
1) Dcm_StartOfReception()
2) Dcm_CopyRxData()
3) Dcm_TpRxIndication()
Whenever a new reception of Diagnostic service request, starts with DcmRxPduId, PduR
indicates that to DCM module by calling the service Dcm_StartOfReception( ). The entire
request is the N-SDU. It could be fit in a single frame (one N-PDU) or multiple frames (multiple
N-PDUs). In when this service is called, the data of first frame or single frame is provided, total
size of entire request (N-SDU) is given and the pointer to the buffer where data is copied is
provided. DCM has the provision to either accept the request or reject the request due to
request UDS service not being supported or available buffer size not large enough to
accommodate entire request. The detail of this service is given in detail below.
Once start of reception API returns OK, we proceed with the reception of complete N-SDU by N-
PDU after N-PDU (consecutive frames). This is done by calling the API Dcm_CopyRxData( ).

If the reception of a diagnostic request is finished the PduR module will call
Dcm_TpRxIndication( ) to give a receive indication to the Dcm module.
The DSL submodule shall forward received data to the DSD submodule only after a call of
Dcm_TpRxIndication with parameter Result = E_OK.

Concurrent ”TesterPresent” (”keep alive logic”)

 It is possible, that functional ”TesterPresent” commands are sent by the tester in
parallel to physical requests/responses. This is called ”keep alive logic” in ISO14229-1
[2].

 This functional ”TesterPresent” will be received on a separate DcmRxPduId.

 When the PduR module calls Dcm_TpRxIndication() with parameter Result = E_OK and if
the request is a ”TesterPresent” command with ”suppressPosRspMsgIndicationBit” set
to TRUE, the DSL submodule shall not forward this request to the DSD submodule for
further interpretation.

Response Handling
Forward responses from the DSD submodule to the PduR module
dddd