A car is a high-risk vehicle. To minimize the risks of breakdowns or accidents, it is necessary to conduct regular inspections of its mechanisms to constantly monitor their operation. In the case of a new unit, in the first year, it is enough to carry out periodic surface inspections. However, older vehicles require regular complete diagnostics, especially of the electronic equipment. This procedure is also necessary before buying a used car because with a superficial pre-sale inspection it is not possible to discover all the shortcomings in its operation. In order to transfer information from onboard devices to diagnostic systems, special data transfer protocols were established. We will discuss below the most common among them: XCP, OBD, and UDS protocol.
UDS Protocol: An Overview
UDS (Unified Diagnostic Services) is an automotive protocol that allows diagnostic systems to communicate with a car’s electronics (ECUs) and reprogram them. The “unified” element indicates that the protocol is universal (that is, it allows interacting with a wide range of ECUs), is international, and does not depend on a particular manufacturer.
The architecture of this protocol is based on a four-level model (each level combining several standards), similar to the OSI network model.
The UDS protocol is widespread, considered a factual standard, and used by most manufacturers of the automobile industry so that their products – namely, onboard electronics – are suitable for detailed diagnostics in service stations.
UDS: Use cases
Now, let us look at the main use cases of the UDS protocol:
- Malfunction diagnostics. One of the main uses of the UDS protocol is troubleshooting. In particular, when a problem occurs in the car, the fault code memory (FCM) stores the next diagnostic trouble code (DTC). To retrieve this, the ReadDTCInformation command is used.
- ECU reprogramming. The UDS protocol supports the ECU software update function. This is necessary to eliminate existing errors or add new functions and modules to the ECU.
- Remote routine activation. During diagnostics, you may need to check for malfunctions in a given range of parameters or start the procedure for performing system tests. In this case, the remote routine activation service of the UDS protocol can be used.
- Data exchange. And finally, the UDS protocol allows reading any information from an ECU (in specific identifier formats). Information can be static (such as the ECU serial number, for instance) or dynamic (current state of sensors, crankshaft speed, etc.).
XCP Protocol: An Overview
XCP (Universal Measurement and Calibration Protocol) is a network protocol used to connect calibration systems to electronic control devices. Among other things, it is used to access data about the state of the vehicle’s internal components.
XCP protocol is a derivative of the CCP protocol, which was actively used in the 1990s. It incorporates a number of advancements and optimizations to CCP, such as support for synchronous and asynchronous data interfaces. In addition, XCP can be used as a standardizer (of course, via Ethernet or USB cables) for analog diagnostic devices and converters.
XCP: Use cases
XCP operates based on a Single-Master/Multi-Slave communication model. For this reason, the most common use case for XCP is in easily scalable onboard diagnostic solutions. The main goal for XCP’s creation was to optimize interaction with ECUs by ensuring the maximum potential for system resource scalability. Thanks to this, XCP is suitable even for 8-bit microcontroller devices.
OBD Protocol: An Overview
OBD (On-board Diagnostics protocol) is a solution that is used to examine and diagnose exhaust emission monitoring ECUs in modern automobiles.
In the early 1990s, when carburetors and other mechanical fuel injection systems were replaced by microchip-based electronics, the previous diagnostic methods became ineffective. Moreover, there have always been cars, the original design of which did not include monitoring of exhaust gases. In this case, car service stations would need to have a separate diagnostic device for each separate case with descriptions of codes and repair instructions for cars of each manufacturer. This situation drove the need for the creation of OBD.
Originally, every manufacturer used their own systems and methods to control emissions. The Society of Automotive Engineers consequentially introduced several standards aimed at helping independent car mechanics by eliminating the problem of diagnostic device compatibility.
In terms of implementation, the initial version of the OBD system included oxygen sensors, exhaust gas recirculation (EGR) systems, a fuel supply system, and an engine control unit. This system did not require compliance with any norms or standards.
Modern cars carry the second revision of the protocol, OBD-II, which allows monitoring body parts and additional devices, as well as diagnosing a car’s control network. OBD-II is no longer a design of engine exhaust control system, but rather a set of rules that every manufacturer must follow in order for an engine control system to meet state regulations for the composition of exhaust gases.
OBD: Use cases
A typical use of OBD is any modern car with an on-board computer.
Despite the fact that the purpose of all three considered protocols is the same – car diagnostics – they provide varying capabilities.
Both the OBD and UDS protocols are focused on diagnostics, but comparing them is not really correct. UDS is designated for the offline diagnostics of vehicle malfunctions at a service station, while OBD is an onboard self-diagnosis service for ECUs that analyzes the engine’s harmful emissions.
As for the XCP protocol, its main goal is to create the foundation for a scalable network able to connect to all onboard ECUs for monitoring, diagnostic, and data exchange purposes.
Advice for Projects
Based on the above considerations, we can conclude that the UDS protocol is the most universal and suitable for the widest possible range of projects. In particular, it allows ECU reprogramming (the other two protocols have no such option).
In turn, XCP is the ideal choice for scalable onboard diagnostic systems that feature low bandwidth delays or require real-time fault analysis.
As you can see, each of the listed protocols varies greatly in its capabilities; therefore, which one you choose to implement in your solution will depend on the project requirements. One way or another, if you want to get a professional, properly working product, you definitely cannot do without the help of specialists. In particular, our team specializes in creating and deploying projects based on the UDS, XCP and OBD protocols. To understand or discuss the options for potential cooperation, contact us now.