We introduced Automotive Diagnostic based on ISO 14229 in 2023 with the release of Apex.Grace 2.2. The latest release of Apex.Grace 3.1 now adds a Diagnostic Fault Manager (DFM) and a Fault Monitor (DM) to the Automotive Diagnostics functions. These connect to the existing UDS server using standard ROS communication and provide support for three new services: Read DTC Information (0x19), Control DTC Setting (0x85), and Clear Diagnostic Information (0x14). This enables application developers to evaluate faults and generate Diagnostic Trouble Codes (DTCs) using the debouncing algorithms provided by the Fault Monitor. The UDS server has also been extended to support the service RoutineControlByID.
Introduction
There is a need to ensure that the functionality is behaving as expected in many automotive applications. Traditionally, this supervision has been related to monitoring the electrical connections of sensors and actuators. Fault codes like Short-Circuit to ground, Open-Circuit, or Short-Circuit to supply have been used in workshops (garages) to troubleshoot and replace components. Today's cars have a more advanced—and intelligent—sensor set with increased complexity. In response to this change, the diagnostic functions must allow for more involved diagnostic routines. For example, rather than only monitoring traditional signals, diagnostic functions must detect situations like a camera’s lens being blocked or components that are overheated. Through diagnostic functions like these, the broader diagnostic stack is able to collect statistics on the vehicle's overall performance.
With the introduction of the connected vehicle, it is also possible for the manufacturer to connect to the UDS server remotely and monitor the vehicle's status even before it needs to go to the workshop. Remote monitoring allows for preventative maintenance which lowers cost and increases vehicle uptime. For example, technicians are able to prepare the workshop and order spare parts before the vehicle arrives.
Architecture
The building blocks of the Apex.Grace Diagnostics stack is shown in the diagram below.
The DoIP Transport node handles communication with the tester device connected to the vehicle. It has two responsibilities. The first is to identify the ECU by broadcasting the VIN, MAC, or another unique identifier on a UDP port (usually port 13400). The second is to provide a TCP port to which external clients can connect, and by that, it can send UDS server request packets routed to the UDS server node. The architecture separates the transport layer from the UDS server using the ROS publish-subscribe communication paradigm. This separation opens up the usage of other transport protocols like CAN, FlexRay, and proprietary solutions without modifying the UDS server itself.
The UDS Server is the primary node (process) of the UDS stack. All requests from the transport layer are collected and validated in this node. Inside the UDS server stack are three essential layers: the session, the security, and the service layer—these are described in the previous post (link).
The Fault Monitor is integrated into the application node and is the reporting facility that the applications use to report faults to the Diagnostic Fault Manager. The Fault Monitor interface has a report_event method that the application logic calls after evaluating a possible problem. It takes an argument (Enum type) that can either be FAILED or PASSED. The monitor uses a configurable debouncing algorithm to evaluate if there are any faults to report. If the reported faults exceed the configurable threshold, the Fault Monitor sends this to the Diagnostic Fault Manager (DFM), and the corresponding Diagnostic Trouble Code (DTC) is updated. The monitor comes in two flavors: Counter-based Monitor and Timer-based Monitor. The Counter-based variant is configurable like a low-pass filter, i.e., there need to be several failed calls before the DTC sets. It is the same behavior for healing, i.e., there is a threshold of passed calls before the DTC is deactivated. The Time-based variant uses time, i.e., the first fault reported starts a timer, and if this timer times out, the monitor reports it to the DFM and the appropriate DTC gets set. It is crucial that the Fault Monitor can be integrated into safety-critical applications, which is why it is becoming safety-certified according to ISO 26262 as an ASIL D component.
The Diagnostic Fault Management block collects fault information from Fault Monitors and stores fault information in non-volatile memory using the Apex.Grace Diagnostics Storage (DTC Storage) service. The information stored in the database is associated with a unique diagnostic trouble code (DTC) that identifies the fault. In addition, the DFM is collecting some OEM-specific data, called Extended data. Examples of Extended data can be occurrence counters (number of times this fault has been reported), date and time (when the fault occurred) and aging (time since the last time the fault occurred). Finally, the DFM can also collect Snapshot data (also called Freeze-frames), which is environment data collected from other applications that can help reproduce and troubleshoot faults. Typical examples of snapshot data can be vehicle speed or outdoor temperature.
New service in UDS server
The services related to DTC management (ReadDTC, ClearDTC, and ControlDTCSettings) have been added to the UDS Server. With that addition, the Diagnostic Fault Manager is integrated with the DTC management services.
Another added service is RoutineControlByID, which lets applications start routines on request from the tester client. This service is valuable in production and workshops where the production or maintenance system can request a calibration sequence to be run or force an application into a specific mode before a technician begins to work with the vehicle.
The RoutineControlByID service also provides value during the development phase. Developers can force a particular routine to execute, which either injects faults or runs a specific sequence of tests. This type of developer-specified routine is tailored for a specific use case, so running this inside the UDS server is infeasible. Instead, the UDS server checks that the tester client has the necessary security level and that the UDS server is in the correct operating mode (session). If so, the UDS server sends the routine request to an application using an Apex.Grace service call. The developers writing the application node(s) implement a RID_handler function containing the algorithm. This handler contains a start, stop, and result function to report the result of the routine back to the client.
Summary
In Apex.Grace version 2.2, the first version of the UDS stack was released. In Apex.Grace 3.1 we have extended this package with new functionality that enables developers to use automotive diagnostic fault management and prepare their applications for series production of vehicles that require more advanced sensors and more complex system architectures.
If you are interested in Apex.AI products for your projects, contact us.