Decoding the Implementation of UDS Vehicle Diagnostics in AUTOSAR Base Software Module

Decoding the Implementation of UDS Vehicle Diagnostics in AUTOSAR Base Software Module

For all the automotive technology enthusiasts, AUTOSAR needs no introduction. The AUTOSAR consortium was formed by the automotive OEMs to counter the complexities created due to increase in the use of ECUs (Electronic Control Units) in the automobiles.

This AUTOSAR software Architecture ensured the decoupling of product functionalities from the hardware and software services.

This standardization has helped the automotive embedded developers in focusing primarily on the innovations in the product feature development rather than working on different architectures.

This shift in automotive ECU development approach has proved to be equally beneficial for the automotive OEMs and their Tier-1 suppliers. Why, you ask? Post-AUTOSAR, OEMs’ and Tier-I Suppliers have been able to save costs spent on different software development tools required in era of non-standard architecture.

AUTOSAR software architecture has brought about a standardization that the OEMs and suppliers follow to develop software without facing any compatibility issues.

When Vehicle Diagnostics Met AUTOSAR Software Architecture

In automotive, diagnostics is required to be performed on all ECUs to ensure there is no issue with any electronically controlled component of the vehicle. Any issue encountered by the automotive ECU is stored as Diagnostics Trouble Code (DTC) in the Electrically Erasable Programmable Read-Only Memory (EEPROM). These codes can be retrieved later using an automotive diagnostic tool.

Now the vehicle diagnostics system needs to be implemented in the AUTOSAR architecture and this is what this blog aims to explore.

To understand how the diagnostics is implemented in AUTOSAR architecture, let us quickly revisit the architecture.

In the base software layer, there are hundreds of software modules including those categorized under the Microcontroller Abstraction Layer (MCAL), ECU Abstraction Layers and Service layer.

The blog will focus on the service layer of the AUTOSAR Base Software Module as the vehicle diagnostics services are stored here.

There are essentially three modules inside this layer tasked with different responsibility with respect to vehicle diagnostics. We will discuss them in the subsequent sections.

In the diagram below, the different components of the diagnostic stack(DCM, DEM, FIM etc.) can be seen.

Source: Mathworks

1. Diagnostics Communication Manager (DCM)

   The diagnostic communication manager (DCM) has the responsibility of reading and writing the fault codes or diagnostic trouble code in the fault memory of the automotive ECU. It supports the implementation of the diagnostic protocols such as UDS (ISO 14229) and OBD II.

   When an automotive ECU receives a diagnostics request from the tester tool, the DCM preprocesses it. While it handles majority of the requests, any other request is routed to the functional software. Every new version of DCM has an enhanced functional range which increases its ability to handle diverse types of diagnostic requests

   DCM comprises of the service identifiers (SID), data identifiers (DID) sub-functions and routine identifiers to handle the vehicle diagnostics requests.

   While handling the diagnostics requests from external testing tools during ECU software development, vehicle program production or garage servicing, the DCM also manages the session and security states.

   For instance, the DCM checks whether a particular diagnostic request can be supported and also if the execution of that service will be carried out in the current session.

   We will delve little deeper into the different components of DCM and how they interact with each other.

   Diagnostic Session Layer: This sub-module is tasked with ensuring the flow of data related to the diagnostic requests and the responses. Diagnostic session and security states are managed by this layer along with the supervision of timing parameters of the diagnostic protocol.

   Diagnostic Service Dispatcher: The validity of the incoming diagnostic requests needs to be checked and this is where this sub-module comes into the picture. In addition to ensuring the validity of the request, it also keeps track of the progress of the request.

   After the validation is done, this sub-module processes a stream of diagnostic data and also transmits the response post data processing.

   Diagnostic Service Processing (DSP) Module: This is the place where the real processing happens. DSP analyzes the format of the service request and interacts with other components of the AUTOSAR BSW to fetch the data required for the processing. The service response is also assembled by it.

   These three sub-modules interact with each other with the help of defined interfaces. Describing these interfaces is beyond the scope of the blog and we will discuss them in detail in the subsequent blogs.

   In order to make the automotive ECU an AUTOSAR compliant product, DCM needs to be first configured using tools like Vector Tool Chain. During the development process, all the necessary APIs are coded in the DCM including the general DCM definitions.

   Unit testing and integration testing follows the development process. Unit testing is performed using tools like Tessy Test Systems where the source module is analyzed and the functions are tested.

   Integration test is performed on the evaluation board where the data exchanged between the modules is verified. Basically, it tests if all the interfaces are functioning without any issue.

2. Diagnostics Event Manager (DEM)

   DEM is responsible for storing and processing diagnostic errors (events) and all the data associated with it. In addition to it, DEM provides the diagnostic trouble codes (DTC) to the Diagnostic Communication Manager (DCM) as and when required.

   Providing the interface to the application layer of the ECU and to other modules of the AUTOSAR Base Software Module is also one of the responsibilities of DEM.

   There can be two type of event that can be reported to DEM:

   • Base Software Event- Event reported by the base software
   • Software Component Event reported by the AUTOSAR application layer

   The events reported to the DEM need to be first qualified to ensure that whether it is a fault (failure of a component) or just an occurrence (irregular system behavior).

   After the event is qualified, DEM records the event data and communicates with DCM for event handling and FIM (Function Inhibition Module) for functional control (Described in next section).

3. Function Inhibition Module (FIM):

   FIM is essentially the control mechanism for AUTOSAR Base Software and software components. The FIM has to control the functionality available to these components depending on their inhibit conditions.

   An identifier is assigned to the functionalities with an inhibit condition. Only in the scenario of inhibit condition being not true, the functionality is executed.

   The role of FIM is to configure and modify the inhibiting conditions of the functionalities. By doing so, a particular functionality can be adapted easily to a new system context.

   FIM services are primarily focused on the applications residing in the software components; however, the AUTOSAR Base Software (BSW) can also use the services of FIM when required.

   The FIM has a close connection with DEM as the diagnostic events and their status info are considered as inhibit function by the FIM. When a failure is detected, it is reported to the DEM and it is the job of FIM to stop the particular functionality.

Conclusion

The implementation of UDS in the Base Software of AUTOSAR architecture requires two states of designing and highly complex coding during the configuration.

Moreover, the configuration of the Diagnostic Communication Manager (DCM) needs to be done with respect to certain parameters defined by AUTOSAR. This is where AUTOSAR Tool Chains become very important.

These platforms help the developers’ auto-generate certain code and write the rest. Configuration of the parameters also becomes quite easy with the tool chain programs like Electrobit, Vector Tool Chain and a few others.

This entry was posted in Embedded Blog, Blog by Embitel. Bookmark the permalink