What is UDS?

Chances are if you’ve worked in automotive software, or have an interest in cars, you’ve come across the term UDS. At its core, Universal Diagnostic Services, more commonly known as UDS, is a set of special functions that every vehicle controller is expected to implement to allow external entities the ability to query it. Queries can range from “how fast are you spinning your motor” to “give me 20 bytes of data located at address 0xA0000000” to “download 256 bytes to a location I previously specified”. Every one of these queries takes the form of a UDS request, and the reply back from the controller is a UDS response.

Let’s Get Some Terms out of the Way

When starting the conversation about UDS, its helpful to align on some terms and assumptions. First off, the going assumption is that we are talking about UDS in the context of automotive electronic control units, otherwise known as ECU’s.

Now, when talking about UDS, what we’re talking about is the protocol that is specified in ISO14229. That is, a special set of bytes exchanged over some medium (UDS is technically medium agnostic, meaning we could be talking UDS over CAN, FlexRay, LIN, Ethernet, whatever). UDS is a client-server driven protocol, with the ECU always acting as the server, and the entity sending requests to the ECU being named the client. For historical reasons, many in the industry will refer to the UDS client as the tester.

If you ever get confused about which one is the client and which one is the server in this relationship, just think of it like websites. The thing with all the goodies on it is the web server, and the guy who wants all the goodies is the web client. Similarly, the ECU has all the information you actually want, and so it is the server. And you, the requester, are the client.

So why do we call the UDS Client the tester? It starts with why we need UDS in the first place. An automobile is an incredibly complicated machine – its literally an orchestra of electrical, mechanical, and software elements all working in perfect harmony to provide propulsion (and these days a whole lot more). As such, when things go wrong, it can be incredibly difficult to figure out why. Imagine pulling in your car to the mechanics because you hear funny noises coming from the engine. The mechanic might have an idea of what the problem could be based on the noise, but more likely than not she’ll have to ask the on-board ECU’s to retrieve as much information as possible about the state of the car. She’ll likely use different functions provided by UDS to test the portions of the car she thinks are at fault. And because automotive folks aren’t known for their creative naming, the entity running these UDS requests has been colloquially named the tester.

Finally, UDS itself is broken down into varying functions called services. A service is simply some functionality that is provided by the ECU to the tester. Like the graphic above shows, there is a service to read pieces of information. Similarly, there is a service to write in pieces of information from the client to the server. An example of this could be the serial number of the ECU (this could be done during manufacturing, in which case the tester isn’t a mechanic, but rather a computer on the assembly line). There are even services that are used to reprogram an ECU after its been installed in a vehicle. We’ll go through in detail each service in later posts.

What’s the Point of UDS?

As alluded to above, the stated purpose of UDS is to help mechanics repair your car. Of course, there are many secondary uses to UDS which make it such an important topic in automotive circles – but the primary goal of UDS is to allow the service personnel to capture all the relevant data from your vehicle to help them figure out what, if any, problems are present. As an interesting side note, with many American states legislating right to repair laws, these service professionals could soon be regular folks like me and you.

Secondary uses of UDS are widespread throughout the industry, and UDS is often adapted by engineers to perform all the functions outside the normal operating scope of a particular ECU. For example, many manufacturers (all the way from OEM’s down to Tier 2’s) will use UDS services in their assembly plants to ensure the component just manufactured is operating correctly. Sometimes test engineers will have access to special UDS services that allow them to gather deep insights into the software running on their controllers during debugging. And as mentioned earlier, UDS provides key functionality for updating the software of an ECU.

What’s Next?

Now that we have an abstract understanding of what UDS is and what it’s used for, we can take a deeper dive into the actual protocol behind it. That’ll be in the next post: The UDS Protocol.