AUTOSAR for dummies — #3.3.1 — Vehicle Diagnostics

In this article, we will see about the AUTOSAR architecture of Vehicle Diagnostics. For those who are new to vehicle diagnostics, it the feature provided by ECUs to find out where a fault is occurring in the system ECU is controlling. For example, let’s say your car’s performance seems to have dropped considerably and you have taken it to the service station. The service professional will connect a tester device to your car and read out some values. In this particular case, the Engine ECU reports a fault with the turbocharger. So the service professional has found the cause of the fault in a few minutes instead of spending hours opening and dismantling the vehicle components. Though the problem needs to be investigated and solved further manually, this saves a considerable amount of time needed for diagnosing the problem. Another more familiar feature of diagnostics is to indicate faults in the vehicle to driver using malfunction indicator lamps in dashboard

Now that we have established what vehicle diagnostics are, let’s move on to the AUTOSAR part. In AUTOSAR vehicle diagnostics is supported by

1. Diagnostics Communication Manager
2. Diagnostics Event Manager
3. Function Inhibition Manager
4. Development Error Tracer
5. Diagnostic Log and Trace

1. DCM: The DCM handles communication with external diagnosis tools. It checks if the requested diagnostic service from the tester device is supported and in this case, it checks if the service can be executed in the current session (diagnostics have different sessions which have restrictions on what data can be accessed, this is done to restrict access to different users. For eg. OEM controlled devices will have more access to vehicles than a service station device). DCM consist of the below modules

• Diagnostic Service Dispatcher(DSD) checks the validity of the incoming diagnostic requests and keeps track of the progress of the request. This is where the supported diagnostic services should be added. For each service supported security levels and sessions in which the service is supported should be configured.
• Diagnostic Service Processing (DSP) Module analyzes the format of the service request and interacts with other components of the AUTOSAR BSW to fetch the data required for the processing. Here DIDs, memory access, routines, security levels, sessions, etc. should be configured.
• Diagnostic Session Layer(DSL) takes care of the flow of data related to the diagnostic requests and the responses. Diagnostic session and security states are managed by this layer.DSL informs the DSD about the incoming request and provides the data.

2. DEM: Dem handles and stores the diagnostic events detected by diagnostic monitors in both Software Components (SW-Cs) and Basic Software Modules (BSWM). In simple terms DEM stores the fault which is detected by BSW or ASW component, each fault will have a unique ID which could be used to identify the fault. The stored fault could be used by other modules to take corrective action or suppress some features

• BSW components report fault with the Dem_ReportErrorStatus API.
• ASW SWCs report fault with the Dem_SetEventStatus API through RTE

3.FIM: By means of FIM, functionalities( parts of ASW runnables or BSW functions) can be inhibited (i.e., deactivated) according to the FIM’s configuration. The functionalities of the runnables are assigned to a unique function identifier (FID)along with an inhibit condition for that particular FID. Functionalities poll for the permission state of their respective FIDs before execution. If an inhibit condition is true for a particular FID, the corresponding functionality is not executed anymore. FIM is closely related to the Dem as diagnostic events and their status information can serve as possible to inhibit conditions. Hence, functionality which needs to be stopped in case of a failure can be represented by a particular FID. If the failure is detected and the event is reported to the Dem, FIM then inhibits the FID and therefore the corresponding functionality

4.DET: SW components can report the error and the module and the function in which error has been detected and the type of the error to the Development Error Tracer module. This is a highly useful module to debug SW errors in development phase for the Developers and Testers

5.DLT: DLT provides a log and trace interface in ECUs.

Originally published at https://www.vtronics.in on November 9, 2019.