Autosar Diag. Comm.

Manager

Presented by:
SHANKU KAK
Crevavi Technologies Pvt. Ltd.
 Diagnostic Communication Manager
The Dcm module provides a common API for diagnostic services. The functionality of the. Dcm
module is used by external diagnostic tools during the development, manufacturing or service.
The Dcm module ensures diagnostic data flow and manages the diagnostic states, especially
diagnostic sessions and security states. Furthermore, the Dcm module checks if the diagnostic
service request is supported and if the service may be executed in the current session according
to the diagnostic states.
• In the AUTOSAR Architecture the Diagnostic Communication Manager is located in the
Communication Services (Service Layer).
• The Dcm module is network-independent. All network-specific functionality (the specifics of
networks like CAN, LIN, FlexRay or MOST) is handled outside of the Dcm module.
• The PDU Router (PduR) module provides a network-independent interface to the Dcm
module. The Dcm module receives a diagnostic message from the PduR module.
• The Dcm module processes and checks internally the diagnostic message. As part of
processing the requested diagnostic service, the Dcm will interact with other BSW modules
or with SW-Components (through the RTE) to obtain requested data or to execute requested
commands. This processing is very service-specific. Typically, the Dcm will assemble the
gathered information and send a message back through the PduR module.
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 consists of the following 3-submodules:

• Diagnostic Session Layer (DSL)

• Diagnostic Service Dispatcher (DSD)
• Diagnostic Service Processing (DSP)
INTERFACE
 DSL(Diagnostic Session layer)
DSL is used to process the data flow of diagnostic data requests and responses; monitor and ensure the
timing of diagnostic requests and responses.
1. Handling diagnostic requests
When receiving a diagnosis request, PduR calls the Dcm_StartOfReception () and Dcm_CopyRxData ()
functions to place the received diagnosis request data in the Buffer of the DCM module, and then PduR
calls the Dcm_TpTxConfirmation () function to notify the Dcm module that a new diagnosis request has
been received.

2. Handling diagnostic responses

When it is necessary to respond to the diagnostic request, the DSL module transfers the data to the PDRU
module by calling PduR_DcmTransimit () and Dcm_CopyTxData (), where the PduR_DcmTransimit ()
function only passes the length information and address information, and the data is passed to the PduR
module through the Dcm_CopyTxData () function When the data transmission is successful, the PUDR
module informs the DCM that the data is successfully received through the Dcm_TpTxConfirmation ()
function.

3. Manage security levels

DSL provides Dcm_GetSecurityLevel () and DslInternal_SetSecurityLevel () two functions to get the
current security level and set the security level respectively.
For the configuration level, the DSL menu is mainly for configuring diagnostic frames, including physical
addressing and functional addressing, the maximum Buffer for a single communication, and time
parameters, including the time to reply 0x78 and to prevent diagnostic service abnormalities, the
• Forward requests from PduR to DSD module - Diagnostics have their own PDUs (for both TX
and RX) with their own unique PDU ID, whenever a new diagnostic request reception starts on
any of the diagnostic PDU, PduR indicates this to DCM. PduR communicates this information to
DSL sub-module which is further forwarded to DSD (Diagnostic Service Dispatcher). PduR requests
the buffer to be filled with diagnostic request from DCM module using
API: Dcm_ProvideRXBuffer() ,PduR also provides the number of bytes expected to be received
This API never returns the filled buffer until its fully filled with expected amount of bytes. After
complete reception of diagnostic request (successful or with errors), PduR module calls
the Dcm_RxIndication() API to give a receive indication to DCM. After completely reception of
request from PduR, DSL blocks this DCM PDU ID (received PDU ID) and new requests from same
protocol type
• Concurrent “TesterPresent” – it implements a “keep alive logic” which is a service
implemented in UDS called as TesterPresent, client (tester tool) sends this request to DCM to
indicate client is still present. DCM don’t send any response for this request as its use is to just
indicate that client is present. DSL also don’t forward this to DSD as there is nothing of interest in
this request.
• Forward responses from DSD to PduR - DCM sends its response to tool in a dedicated TX
PDU with unique PDU ID via PduR. DSP (sub-module of DCM) sends this response to DSD which is
further forwarded to DSL and lastly DSL forwards this to PduR. The request and response PDU IDs
are linked with each other during DCM configuration, this guarantees correct response to request
received. The DSL module forwards the response PDU to PduR only after the minimum specified
delay between request reception and response. DSL uses PduR_DcmTransmit() to indicate length
information of response PDU to PduR. After reception of this information, PduR module
calls Dcm_ProvideTXBuffer() to request DCM module for the response PDU to be transmitted.
• Guarantee timing to tester by sending busy responses - Many times the diagnostic
request takes more time for processing, in that case if there is no communication from
server (DCM) to tester tool for specified maximum response time, it may think the ECU is not
responding and end diagnostic session. To resolve this, DSL sends busy responses to tester
tool periodically until the request processing is not completed. The busy response is a
negative response (protocol) with NRC (Negative response code) 0x78 which
means Response pending. DSL uses a separate buffer to send such busy responses. But this
may lead to deadlock so to avoid deadlock, during configuration integrator can set the
maximum busy responses by setting DcmDslDiagRespMaxNumRespPend configuration
parameter. If the number of busy responses if greater than this parameter, DCM module
stops the processing of that request and sends the negative response NRC 0x10 which
indicates General Reject.
• Support for ROE transmission - The UDS has a service named ResponseOnEvent (0x86)
using which the tester can request the ECU to start and stop transmission of responses
initiated by a specified event. When registering transmission based on event, the tester has
to specify the corresponding service to which response is to be sent.
• Support of periodic transmission - The UDS has a service to let tester request periodic
transmission of data record values from ECU. DSL module handles this request in two ways:
1. If any request processing is going on and using the same PDU ID which is to be used for
periodic transmission, DSL would allow such requests only after completing the processing of
ongoing request; 2. Or if configured to use separate PDU ID and protocol, the DSL allows this
request and sends on separate PDU (which is not used for normal diagnostic requests).
• Support of segmented response - When there is a need to send responses that are
greater than configured and allocated diagnostic buffer, DSL can segment the response data
in pieces and sends the response. With this, the ECU can save memory because there won’t
be any need to allocate big buffers for big responses. This segmentation is supported on in
sending responses, i.e. segmented requests are not supported by DSL.
• Support of ResponsePending response triggered by the Application (SWC) - In some
cases, the application needs to send immediate ResponsePending responses unlike above
described functionality for sending busy responses in which the DSL waits for the minimum
time between request and response. This can be used in flash programming scenario,
application will send ResponsePending before entering into bootloader.
• Manage Security Level - DSL sub-module provides interfaces to get current security level
and also to sent new security level. DSL module also saves the current active security level.
During DCM initialization, the security level is set to 0x00 this means ECU is locked for that
period
• Manage session state - DSL provides interfaces to get current active session and also to
set a new session. During DCM initialization, the session state is “Default Session”. DSL
module saves the state of current active session.
• Keep track of non-default session - Whenever a non-default session is going on and the
session timeout occurs without receiving any diagnostic request, DSL module resets the
current session and enters into default session.
 DSL ctd.
• Informs depending modules of session change - Whenever a session change occurs,
DSL notifies the corresponding module involved in that session regarding the session change.
• Allow to modify timings - As DSL is the one to take care of timing requirements of
protocol, it allows to modify timings of session layer as the protocol related timing
parameters has no influence on Transport layer. To modify timings of protocol, UDS has
defined following services: UDS Service DiagnosticSessionControl (0x10) and UDS Service
AccessTimingParameter (0x83).
• Handling of different diagnostic protocols - DCM as said in introduction, supports
different diagnostic protocols like UDS or OBD, etc. DSL sub module handles this.
 DSD(Diagnostic Service Dispatcher)
The DSD module is responsible for checking the validity of diagnostic requests (diagnostic sessions,
security access levels, verification of application permissions), and tracking the progress of service
request execution.
1. Inspection and diagnosis services
When the DSL receives a new diagnostic request, the DSL notifies the DSD through the internal
interface. DSD calls Dcm_GetSesCtrlType () and Dcm_GetSecurityLevel () to obtain the current
Session and security level. The DSD module will check whether the diagnostic request SID is in the
"Service Identifier Table" of the current Session. If it is not in the table, DSD will send NRC 0x7F.
Service support, but the current Session does not support this sub-service, DSD will send NRC 0x7E;
then check whether the current security level meets the conditions, if the current security level
does not support the diagnostic request, DSD will send NRC 0x33. Finally, check the length of the
data.

2. Summarize the response data

After the DSP module completes the processing of the diagnostic request, the DSD is responsible for
collating the response data. And send to DSL.

• The DSD module adds the service identifier (SID) (0x7F if it is negative feedback) and the data
flow of the response to "Dcm_MsgContextType". Then DSD transfers it to the buffer and adds
the SID to the first byte of the buffer.
• For configuration, DSD is mainly to configure the services that need to be implemented, and the
• Support checking the diagnostic service identifier and adapting the diagnostic
message: DSD validates the received diagnostic request message from DSL and if supported
it is forwarded to appropriate DSP or else it is rejected by sending negative response. Every
diagnostic request has a Service Identifier(SID) to indicate the type of request. DSD has
the Service Identifier Table which has predefined supported SIDs, this table is generated
after configuration and is provided by DSL. DSD checks this received SID from request in the
Service Identifier Table and if received SID is present in the table, it is forwarded to
appropriate DSP or else it is rejected by a negative response with NRC 0x11 i.e. Service not
supported to the DSL.
• Handling of suppression of positive response message: UDS has a facility to suppress
the positive response message reception on each successful procession of diagnostic
request. This is handled by DSD. DSD checks if bit named “suppressPosRspMsgIndicationBit”
in received diagnostic request is TRUE, if it is then DSD won’t send positive responses. This
setting will be ignored if the busy responses is going on.
• Verification functionality: DSD sub-module is also responsible for verifying the received
diagnostic request. DSD sub-module will only accept the diagnostic request if it passes three
verifications:
– Verification of Diagnostic Session: As discussed above, a diagnostic session is a activity
window to perform diagnostics. Every session has a specific set of supported diagnostic
services. On reception of a new diagnostic request, DSD will get the current diagnostic
session information and will verify if the current received service request is allowed for
current session.
 UDS service for DiagnosticSessionControl (0x10) is bypassed of this verification, or
else the tester won’t be able to change the diagnostic session then If the
received service request is not allowed in current diagnostic session, then DSD sends a
negative response with NRC (0x7F) which means Service is not supported for active
session.
– Verification of service security access levels: Some diagnostic services have restricted
security access levels. DSD sub-module takes care of verification of such services. When
a new diagnostic request is received from DSL, DSD gets the current active security level
from DSL and checks if the new diagnostic request is allowed for current security access
level. If the received diagnostic request is not allowed in the current security level, then
DSD sub-module sends a negative response with NRC (0x33). Again UDS service
SecurityAccess (0x27) is bypassed this verification, or else the tester will never be able to
access security restricted data. If the received service request is not allowed for current
security level, then DSD sends negative response with NRC 0x33 which means Security
access denied.
– Verification of the application environment or permission: Diagnostic cannot be
performed if ECU state is not proper or if environment is not appropriate. Like in after-
run ECU state, it is not allowed to process OBD requests.
• Distribution of diagnostic message to DSP: If the diagnostic service passes all the
checks (as described above), then DSD searches for a appropriate service executable
functionality of DSP and calls the corresponding DSP service interpreter.
 DSD(Diagnostic Service Dispatcher)
The DSD module is responsible for checking the validity of diagnostic requests (diagnostic sessions,
security access levels, verification of application permissions), and tracking the progress of service
request execution.
1. Inspection and diagnosis services
When the DSL receives a new diagnostic request, the DSL notifies the DSD through the internal
interface. DSD calls Dcm_GetSesCtrlType () and Dcm_GetSecurityLevel () to obtain the current
Session and security level. The DSD module will check whether the diagnostic request SID is in the
"Service Identifier Table" of the current Session. If it is not in the table, DSD will send NRC 0x7F.
Service support, but the current Session does not support this sub-service, DSD will send NRC 0x7E;
then check whether the current security level meets the conditions, if the current security level
does not support the diagnostic request, DSD will send NRC 0x33. Finally, check the length of the
data.

2. Summarize the response data

After the DSP module completes the processing of the diagnostic request, the DSD is responsible for
collating the response data. And send to DSL.

• The DSD module adds the service identifier (SID) (0x7F if it is negative feedback) and the data
flow of the response to "Dcm_MsgContextType". Then DSD transfers it to the buffer and adds
the SID to the first byte of the buffer.
• For configuration, DSD is mainly to configure the services that need to be implemented, and the
• Assemble of positive or negative response: DSD sub-module assembles the
response for executed diagnostic request based on the response of DSP. If response is
positive, DSD sub-module adds the response service identifier (same as that of the
received diagnostic request SID) and response data (which is received from DSP) in the
response message while assembling. Or if the response is negative, then DSD assembles
a negative response message with NRC received from DSP.
• Initiate Transmission: DSD sub-module forwards the response message to DSL sub-
module for further transmission. When the DSL module receives the confirmation of
transmission from PduR, it transmits this information to DSD. Which the DSD sub-
module further forwards to DSP for its confirmation.
• DID implementation, including DcmDspData is used to configure the data type,
data length, and interface type of DID; DcmDspDidInfo is used to configure the
read and write function of DID; DcmDspDids is used to summarize DcmDspDidInfo
and DcmDspData, and add DID value.

• The realization of security level, including the number of bits of seed and key, the
maximum number of wrong accesses, and time parameters.

• Session configuration, including the level of the Session, whether the Session
supports jumping to Boot, and the time parameters P2 ServeMax and P2
*ServeMax.
Simulate
DSL DSD DSP User
Request DslInternal_ResponseOnOneDataByPeriodicId(uint8)

Data_Inidcation_functionality()

ReadDataByIdentifierServiceInterpreter()

ReadData(Did specific type):

Std_ReturnType
 module module module Dcm External
PduR Dsl Dsd User Module
Dcm_TpRxIndication(PduIdType, Std_ReturnType)
Xxx_StartProtocol(Std_ReturnType, Dcm_ProtocolType,
uint16, uint16)
Dcm_StartProtocol()

<Module>_<DiagnosticService>(Std_ReturnType,
Dcm_ExtendedOpStatusType, Dcm_MsgContextType**,
alt protocol allowed? Dcm_NegativeResponseCodeType**)
[E_OK] Data_Indication_functionality()

Data_Indication_functionality()
E_PROTOCOL_NOT_ALLOWED]

Dcm_TpRxIndication()
 Autosar Software
SW - C SW – C’s SW – C’s
Filter Providing Data Controlling
Services Monitor (For Event Memory Indicator(e.g. LED,
Entries)
Text msg., etc.)

AUTOSAR ( RTE )

BSW
Filter
Services
Monitor

Communication Services
Memory
Services
EcuM DCM

Dem
NvRAM
FiM J1939DCM Manager

Dlt
System Services

BASIC SOFTWARE
DEM(Diagnostic Event Manager)