AUTOSAR and UDS are the result of a similar quest. Automotive ECUs were being developed in a non-standardized manner. Every OEM had their proprietary architecture for development of their solutions.
The idea behind AUTOSAR was to standardize the software interfaces so that there is a certain degree of interoperability among various automotive modules developed by different vendors. This AUTOSAR software Architecture ensured the decoupling of product functionalities from the hardware and software services.
Unified Diagnostics Services (UDS) share a somewhat similar origin story. Defined in ISO 14229-1, UDS intended to unify the different vehicle diagnostics services offered by protocols like KWP 2000 on K-Line and CAN. In addition, UDS protocol also sought to meet the new diagnostics requirements that stemmed from advancements in automotive ECUs.
Standardization brought about by both AUTOSAR and UDS has enabled OEMs’ and Tier-I suppliers to save resources spent on tools required in era of non-AUTOSAR architecture.
Besides sharing the origin story and being the harbinger of standardization in automotive ecosystem, UDS and AUTOSAR are closely related. UDS is implemented in the base software module of AUTOSAR and together they manage the vehicle diagnostics. Even in the adaptive version of AUTOSAR, UDS powered vehicle diagnostics has a special role to play.
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
- 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.
- 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).
A snapshot of DEM functions
- Processing of fault monitor result and reporting fault info to DCM
- Event debouncing i.e. qualifying the fault before it is reported as a DTC
- Mapping event to diagnostic trouble code
- Management of DTC status bit
- Fault code removal after repair (DTC unlearning)
DCM and DEM come as part of AUTOSAR configuration. AUTOSAR has defined a standardized format for data that can be used to configure DCM and DEM. The format is called diagnostic extract (DEXT). DEXT is part of the ARXML file and contains information to configure DCM and DEM. Tools like CANdelaStudio can be deployed to create and export DEXT file which in turn can be imported to DaVinci configurator tool to configure DCM and DEM.
- 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.
Does UDS Protocol Work Differently in AUTOSAR Adaptive Platform?
In Adaptive platform, the diagnostic service management (DSM) replaces the DCM module of the AUTOSAR Classic platform. However, their functionality remains essentially the same which is processing/dispatching of diagnostic services according to UDS (ISO 14229).
Another aspect to UDS implementation in Adaptive platform of AUTOSAR is that it supports only Ethernet based network technology. It implies that only DoIP transport layer (ISO 13400) can be used for communication and not CAN or CAN FD, FlexRay and others. In future releases, Adaptive platform will most probably support other transport layer of UDS other than DoIP.
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.
