UDS

In vehicle-diagnostics captures, the first things people often remember are a few hex service numbers: 0x10, 0x22, 0x27, 0x2E, 0x31, 0x34. Those numbers matter, of course, but memorizing service IDs alone still leaves later implementation, troubleshooting, and flashing analysis confused, because what you need to grasp first is not “which number means which function.” It is “why vehicle diagnostics cannot rely only on a few private commands, and instead need a full application-layer order.”

The most important judgment about UDS is this: it defines a unified diagnostic interaction model above the ECU. It does not solve CAN arbitration, and it does not solve long-message segmentation. It solves how a tester and an ECU start a diagnostic session, how they declare current permissions, how they read data, how they execute control, how they report failure, and how these actions become reusable across ECUs and toolchains.

Why Diagnostics Cannot Rely on Private Commands Alone

If you only build the smallest experiment, an ECU exposing a few custom commands may already be enough to read some state, write some parameters, or run a test. But once the system gets bigger, that approach starts to fall apart quickly.

First, diagnostic entry points across ECUs become both more similar and less compatible over time. Reading IDs, reading trouble codes, clearing faults, writing parameters, and downloading software are all common needs. If every vendor, every generation, and every module invents its own command format, the cost of test tools, production lines, service tools, and gateway adaptation rises continuously. Second, many actions naturally need state and permissions. You cannot always flash, and you cannot always run actuator control just because a request arrived. Third, when diagnostics fail, knowing only “it failed” is not enough. The tool needs to know whether the condition was not met, the service is unsupported, the session is wrong, the security level is insufficient, or the response is still being prepared.

UDS exists to pull those recurring problems into a unified service model. It optimizes first for semantic consistency, tool compatibility, and engineering diagnosability, not for the smallest byte count.

The Smallest Useful UDS Mental Model

It is more accurate to think of UDS as “a set of diagnostic services with context and error semantics” than as “a list of service IDs.”

At least five things need to be true:

requests and responses must revolve around clear service semantics
the ECU must know which diagnostic context it is currently in
some high-risk actions must be constrained by permissions or security access
failures should not be collapsed into one vague error; they need negative responses that guide the next step
when an operation takes time, the protocol must let the ECU say “I am still processing, not disconnected”

Once you hold those five points, Diagnostic Session Control, Security Access, Read Data By Identifier, Routine Control, and the rest stop feeling like isolated functions.

A Real Flow Is More Useful Than a Service-ID List

The most stable way to understand UDS is usually not to start from the service table. It is to follow one real diagnostic action.

For example, if a tester wants to read some ECU identification and state, it usually does not start with a high-privilege command. It first checks whether the current session is suitable. If needed, it switches to an extended diagnostic session or another session that allows the current action. Then it may read several data identifiers, or DIDs, to get software version, part number, configuration state, or sensor values.

If later it needs a more sensitive action, such as writing parameters, running actuator tests, or flashing software, it usually also has to pass security access. That means the ECU first gives a seed, the tester computes a key using the agreed algorithm, and only after that verification do some services actually open.

If the requested action is fast, the ECU responds positively right away. If it cannot finish yet, it can first tell the tester “the request was received, but I need more time,” and the tool keeps waiting for the final result instead of mistaking it for a transport timeout.

That is the core idea: UDS is not a bare command list. It is an application-layer interaction model with session, permission, error semantics, and timing expectations.

What Session Mechanisms Are Really Solving

When people first look at UDS, Session can feel like one more layer of hassle. In reality it handles a very practical problem: the same ECU is not allowed to do the same things at all times.

During normal driving, some actions should be closed off. During service or calibration, more actions are allowed. During flashing, the ECU needs an even stricter context. The session mechanism makes “what is currently allowed” explicit instead of scattering the logic across private commands.

The cost is direct too: tools and implementations must become state-aware. When something fails, do not only look at the service itself. First ask whether the session is right, whether the session has timed out and dropped back to default, and whether the ECU has taken permissions back because no keep-alive was maintained.

Why Security Access Cannot Be Skipped

If diagnostic capabilities include writing parameters, actuator control, routine triggering, or flashing, you cannot assume that anyone who can talk on the bus should also be able to do those things.

Security Access solves that problem. It is not there to make the protocol complicated. It exists so that privilege elevation becomes an explicit, auditable, and failure-aware interaction. The ECU can use a seed/key process to confirm whether the tester meets the required access condition and only then open later services.

The cost is also obvious. Permission control is no longer just an if statement inside business code. It affects capture flow, timeout expectations, failure modes, and tool implementation. In the field, when the same write request works in the lab but fails on a production vehicle, checking the security chain is usually much more effective than checking the payload first.

Why Negative Responses Matter More Than Positive Ones

One valuable thing about UDS is that it does not collapse every failure into the same outcome. Negative Response Codes, or NRCs, are really about answering “what should I conclude next?”

If a service is unsupported, that is not the same as “the service is supported but the current session does not allow it.” If the current condition is not satisfied, that is also not the same as “security access failed.” If the ECU is still processing and not finished yet, that should not be misread as a timeout or a disconnection.

That is why, when reading UDS captures, the most informative message is often the negative response rather than the positive one. It does not just say “failed.” It classifies the failure: service capability, permission state, environmental condition, timing wait, or request format itself.

Why UDS Keeps Appearing Together with CAN TP

UDS itself does not handle segmentation, but many high-value services naturally produce long messages, so in engineering practice it almost always appears together with CAN TP, also known as ISO-TP.

A small DID read may fit in one frame, but once you read extended fault information, large calibration data, or flashing downloads, the single-frame limit is quickly not enough. So below the application layer you still have CAN or CAN FD, the transport layer uses CAN TP for segmentation and reassembly, and the application layer uses UDS to define what the long message actually means.

Those layers must stay separate. First Frame and Flow Control solve how a long message is delivered across multiple frames. 0x22, 0x27, 0x31, and 0x34 solve the diagnostic business meaning. They often appear together, but they are not the same layer.

Which Services Are Worth Looking At First

UDS has many services, but the most useful first model usually comes from the following ones.

Diagnostic Session Control switches diagnostic context. Many later services depend on it. Read Data By Identifier is the most common observation entry point. Security Access raises permissions and is the gate for many high-risk operations. Routine Control triggers or manages diagnostic routines and often appears in self-test, erase, or verification scenarios. Request Download and the following transfer flow are used for flashing and large data downloads.

The main thing to avoid is treating each service ID as an isolated island. A steadier view is that these services together form an application-layer workflow. Which one appears first, which one must come before another, and what to check after a failure matters more than memorizing the service name.

What To Watch First in UDS Captures

The easiest way to waste time in a diagnostic capture is to scroll through bytes from start to finish.

A more useful order is usually:

first check what the business is doing: reading data, clearing faults, running a routine, or downloading
then check whether the current session matches that kind of business
then check whether there is a security-access precondition
if there is a failure, first look at which class of failure the negative response indicates
if the message is long, then move down to the CAN TP layer and check segmentation, flow control, and timeout

Seen this way, many problems can be layered much faster. Otherwise it is easy to mistake an application-layer permission issue for a link-layer loss, or a segmentation timeout for a service being unsupported.

Three Final Judgments

To understand UDS, the important thing is not to memorize service IDs first. It is to remember three points.

First, UDS is a unified diagnostic application-layer model. It solves sessions, permissions, service semantics, and failure expression, not the transport underneath. Second, session mechanisms, security access, and negative responses are not incidental details. They are the key constraints that make diagnostics usable in practice. Third, when debugging in the field, first decide whether the issue is in application-layer semantics, permission state, negative-response classification, or lower-layer CAN TP and CAN transmission, and only then decide where to dig deeper.

If you use those three judgments when looking at the diagnostic stack implementation, production scripts, and capture logs, you will build a stable model much faster than by memorizing a service list. The IDs will come naturally later. If the layers and the main path are not established at the start, any complex diagnostic flow becomes hard to reason about.

UDS