OBD-II exists because regulators required it. Its scope is emissions: a standard connector, a standard set of parameter identifiers, and standard trouble codes, all so that any inspection station can confirm a vehicle is not polluting. That standardisation is exactly why it is limited — it was never meant to expose the rest of the vehicle.
UDS, defined in ISO 14229 and carried over CAN via ISO-TP (ISO 15765-2), is the diagnostic protocol manufacturers actually use in production and service. Nearly every controller in a modern vehicle or machine answers UDS requests, whether or not it has anything to do with emissions.
Coverage: which controllers answer
Through OBD-II you generally reach the engine controller and emissions-related systems. Through UDS you address controllers individually — body, transmission, ABS, gateway, aftertreatment, telematics — each at its own diagnostic address. A fault that never surfaces as an OBD-II DTC is frequently sitting in a controller OBD-II simply does not ask.
Identification data
UDS ReadDataByIdentifier exposes data identifiers (DIDs) that OBD-II has no equivalent for: hardware and software part numbers, supplier codes, calibration IDs, programming dates, serial numbers. When you are establishing whether a control unit was replaced, reflashed, or shipped with the wrong calibration, this is the data that answers the question.
Fault detail
An OBD-II fault code gives you a P-code and, at best, a freeze frame. UDS ReadDTCInformation returns manufacturer DTCs together with status bytes describing whether the fault is confirmed, pending, test-failed this cycle, or test-not-completed, plus extended data records and snapshot data captured at the moment of failure. That distinction between 'currently failing' and 'failed once, three drive cycles ago' is often the whole diagnosis.
Sessions and routines
UDS defines diagnostic sessions and routine control, which is how service procedures such as actuator tests and system resets are performed. These operations sit entirely outside the OBD-II model. Treat them with care: they act on live hardware, and some are gated behind security access for good reason.
Why ELM327 is the wrong tool here
An ELM327 interprets a fixed command set. Multi-frame ISO-TP transfers, arbitrary service IDs and precise timing are outside what it reliably does, so UDS work through one is slow, partial, or both. ProtocolWatcher implements ISO-TP and UDS natively on top of the CAN adapter, so requests go to the bus directly with no interpreter in between.
Practical caution
- Manufacturer DID and routine definitions are proprietary. Reading generic identifiers is safe; guessing at write operations is not.
- Use listen-only mode when you only need to observe traffic.
- Capture the session and export it — a UDS trace is the most useful thing to attach to a second opinion.
Both protocols have their place: OBD-II for a fast emissions-level read across any vehicle, UDS when the question is about a specific controller. ProtocolWatcher supports both from the same app.