Basics and Functional Behavior
From an application developer’s point of view, AUTOSAR diagnostics are relatively straightforward. There is, however, some terminology to learn before understanding AUTOSAR diagnostics. If you are unfamiliar with the services offered in the AUTOSAR BSW or how applications communicate in AUTOSAR-compliant software, please read the linked articles for more information.
The AUTOSAR basic software (BSW) offers three primary modules which can be used for diagnostics: diagnostic event manager (DEM), diagnostic communication manager (DCM), and function inhibition manager (FIM). The DEM has several responsibilities. At a high level, it processes and stores diagnostic events from software components (SWCs) and BSW modules. It also provides fault information to the DCM upon request. The DEM communicates with SWCs via the RTE and with BSW modules via C-API. This article will highlight the internal functionality of the DEM as specified by the AUTOSAR standard.
The DEM contains artifacts called diagnostic events which are packed full of functionality. Each diagnostic event has a status which indicates the result of a diagnostic monitor. These monitors are algorithms implemented by SWCs and BSW modules. They are used to diagnose faults in physical circuits (e.g. short to ground or open circuit). They can be assigned a priority to determine which faults may be removed from memory if the event memory is full. The DEM will even count the number of occurrences of an event. This is just scratching the surface of the DEM’s functionality.
Now that some high-level functionality has been described, it is time to dig into further detail. Let’s start with diagnostic trouble codes. A DTC is a unique identifier which represents at least one diagnostic event. The DEM can distinguish between OBD-relevant DTCs and other (e.g. UDS or J1939) DTCs. DTCs can also be organized by groups. AUTOSAR defines two provided groups: emission-related DTCs and all DTCs. It also supports the creation of user-defined DTC groups outside of the two provided groups. One example of a user-defined group might be powertrain DTCs. DTCs can be assigned one of two levels of significance: fault or occurrence. A fault is a failure in the ECU or monitored component. An occurrence indicates a problem with system-level behavior.
A single DTC can represent the status of one or several diagnostic events. More than one event being represented by a DTC is known as Event Combination. The DEM can be configured to allow each event to share a single memory entry (combination on storage), or it can assign unique memory entries per event (combination on retrieval). In the case of combination on storage, data related to each event (e.g. freeze frame) will be common. With combination on retrieval, each event will have unique data. The same concept applies to diagnostic aging, which will be discussed in a future post.
It may be helpful for technicians or engineers to know certain data at the time a diagnostic event takes place. Examples include vehicle mileage or the value of an oil temperature sensor. These data are known in AUTOSAR as “event-related data” which can be further decomposed into artifacts known as freeze frames and extended data records. These are configurable per event.
The DEM offers the ability to suppress DTCs at runtime. In this scenario, a DTC is processed as normal by the diagnostic monitor, but it is inaccessible by a tester. For example, if a service tool prompts the DCM to request the status of a specific diagnostic event, and each DTC associated with that diagnostic event is suppressed, the status would be unavailable. The DEM would return a message indicating that the wrong DTC was requested. Software which is affected by a particular DTC’s status would not be affected by suppression. For example, if a failed DTC causes functional degeneration of the software, the degeneration would happen whether the DTC is suppressed or not. The DEM is also capable of containing diagnostic events which are configured as unavailable. These events would be defined in the configuration but nonfunctional at runtime. The use case given in the AUTOSAR standard is if a control unit and its software support multiple hardware variants. The event may only be relevant on specific hardware sets. The advantage here is that the same software and ECU can be applied to different hardware. Like suppressed DTCs, these events would be unavailable to the outside world.
One of the DEM’s primary functions is to process and store the results of diagnostic monitors. In many applications, a monitor will report its result to the DEM. The DEM can then debounce the event if configured in order to provide a status of passed or failed. AUTOSAR also provides the option for the diagnostic monitor to debounce an event and send the event’s status to the DEM.
Debouncing a signal improves its quality. The DEM is able to debounce signals using either a counter-based or a time-based mechanism. Alternatively, the DEM can be extended for more complex debounce algorithms. Diagnostic monitors are also able to implement internal debounce algorithms. In other words, the debouncing is performed in the SWC. In this case, the monitor is responsible for reporting its status to the DEM. Debounce algorithms are configurable per diagnostic event, thus, some events may be debounced DEM-internally while others are debounced within a monitor.
This post covered a digestible amount of information regarding AUTOSAR’s diagnostic event manager. A soon-to-be-released second post will dive deeper into debouncing mechanisms, more of the DEM’s functional behavior, and its interaction with SWCs and BSW modules. One final note: system architects should be mindful of cross-core communication in multicore systems. Client-server interfaces can be costly when it comes to computing efficiency, and they are used by the DEM to communicate with application software. A BSW implementation which takes advantage of a master/satellite DEM design will mitigate performance risk. Be on the lookout for a future DISTek blog post to discuss responsible software architecture in a multicore system!
