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 sub-function support. Interacts with other BSW modules and SWC’s to acquire the data required for the service response. It also assembles the service response.
Function Inhibition Manager (FIM)
FIM provides a control mechanism to SWC’s and BSW for controlling the functionality available. A functionality can be defined as a set of runnables with the same set of inhibit conditions.
Functionality and runnable entity are different and independent types of classifications. Runnable entities are mainly characterized by their scheduling requirements. In contrast to that, functionalities are classified by their inhibit conditions.
Functionalities are assigned an identifier (FID) along with an inhibit condition. Functionalities can execute only if its inhibit condition is not TRUE.
The FIM is closely related to the DEM since diagnostic events and their status information are supported as inhibit conditions. Hence, functionality which needs to be stopped in case of a failure can be represented by a particular identifier. If the failure is detected and the event is reported to the DEM, the FIM then inhibits the FID and therefore the corresponding functionality.
Development Error Tracer (DET)
The Development Error Tracer provides functionality to support error detection and tracing of errors during the development of SWC’s and other Basic Software Modules. For this purpose the Development Error Tracer receives and evaluates error messages from these components and modules.
DET provides a configurable list of error hooks which can be executed in case of an error report and interfaces to report error, error recovery and information retrieval.
In the subsequent articles, we will go into the details of these modules.