We developed a UDS stack as an add-on to the Apex.Grace product that makes it possible for ROS developers to integrate with standard automotive protocols like ISO 14229. The implementation also leverages the ISO 13400 standard as a transport protocol for diagnostics over IP. The diagnostic stack uses common ROS communication mechanisms like publish, subscribe, and services to send information between processes. Developers can develop these processes independently using Apex.Ida middleware.
Introduction
Unified Diagnostic Services (UDS) is an automotive diagnostic protocol standardized by ISO in the document ISO 14229. UDS is an application protocol using the OSI model's fifth and seventh layers, defining 27 services identified by their SID (service ID). The UDS protocol uses a client-server model where the ECU plays the server role. The clients are either implemented as a computer program installed on a standard PC or in specific (typically rugged) hardware. Mechanics in workshops or OEM production lines can use such special hardware, and product developers usually use computer programs on their development machines. The clients connect to the ECU with either CAN, LIN, FlexRay, or Ethernet; i.e., the UDS protocol is independent of the lower layers of the OSI model.
The services' primary objective is to allow users to discover operating conditions to diagnose faulty or undesirable behavior. The client can check ECU fault memory, update the ECU with new firmware, or interact with parameters and hardware I/O using standardized services.
Architecture
The diagram above shows the high-level building blocks in the Apex.Grace UDS stack. The DoIP Transport node at the bottom of the figure handles communication with the client outside 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 part 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, or even proprietary solutions without modifying the UDS server itself.
The UDS Server is the primary process of the UDS stack. In this node, all requests from the transport layer are collected and validated. Inside the UDS server stack are three essential layers: the session, the security and the service layer, described in the following sections.
The session layer is responsible for putting the UDS stack into different sessions. The external client requests a session change by sending a dedicated service request called DiagnosticSessionControl to the UDS server. The session and security layer accept or deny the change request, and the UDS server switches the state accordingly. The UDS server broadcasts the change to a new session as a ROS topic, and other processes in the system can act on the change. By entering a special (diagnostic) session, the UDS stack enables or disables the availability of diagnostics services to the external client. During the deployment of the UDS stack, the user can configure which diagnostic services are available in a session.
The security layer checks that an external client request can execute in the current session. As input to this decision, it needs to know the current session, the current security level, and if the requested service can run on this security level. The external client can request a new security level by executing the SecurityAccess request in which the client and the server follow a challenge-response login procedure. The UDS server enters a new security level if that challenge-response sequence succeeds.
The service layer of the UDS server routes requests like ReadDataByIdentifier and WriteDataByIdentifier to application node(s) using the ROS 2 service communication paradigm. When the service layer routes the request from the UDS server to the application node, the application node is woken up by the middleware so that it can process the request from the UDS server on demand.
The final block in the UDS stack is the Diagnostic Fault Management block. This node is responsible for collecting fault information from application nodes and storing that fault information in the Apex.Grace persistent storage database. The type of faults is application-dependent, and traditionally it contains hardware-related defects like harness problems or some malfunction in a sensor or actuator. The information stored in the database is associated with the type of fault, the number of occurrences, and the environmental conditions related to the situation when the fault occurred. Vehicle manufacturers and workshop mechanics use this information to troubleshoot a vehicle failure. They also collect quality metrics associated with a specific hardware component.
Summary
By implementing a UDS and DoIP stack inside Apex.Grace, it has been shown that standard and accepted automotive protocols can be easily integrated into an agile SDV development. The implementation also proves that Apex.Grace is ready for production ECUs.
In Apex.Grace version 2.2, the first version of the UDS stack is released with a subset of functionality. In this version, Apex.Grace supports session management (DiagnosticSessionControl, TesterPresent) and security functions (SecurityAccess) in addition to ReadDataByIdentifier and WriteDataByIdentifier. In future releases, we will add Diagnostic Fault Management, RoutineControlById service, and functionality for reading and writing files.
If you are interested in Apex.AI products for your projects, contact us. We’re always looking for talented people to join our international team. Visit our careers page to view our open positions.