OBDonUDS and CAN FD Explained: The Next Generation of Vehicle Diagnostics

For years, generic OBD2 scanning followed a familiar pattern: connect at the 16-pin port, identify the emissions ECU, request standard parameter IDs, and read diagnostic trouble codes. Newer vehicles increasingly add terms such as OBDonUDS and CAN FD to that workflow. These changes can make an older scan tool appear connected while still failing to retrieve the information a technician expects.

OBDonUDS and CAN FD are related, but they are not the same technology. One defines diagnostic services and data; the other changes how CAN frames carry information. Understanding that separation helps workshops buy compatible interfaces, interpret connection problems, and avoid assuming that every tool with an OBD connector supports the newest vehicles.

Start with the Layers

Vehicle diagnostics use several communication layers. At the top, an application protocol defines requests such as reading data, obtaining trouble-code details, or clearing emissions information. Lower layers package those messages, move them across the network, and place electrical signals on the vehicle wiring.

Unified Diagnostic Services, or UDS, is the standardized diagnostic service family in ISO 14229. It is used for many manufacturer-level tasks and can operate over different transports, including CAN and Ethernet. CAN FD is a data-link technology. DoIP is an IP-based transport over automotive Ethernet. A technician can therefore encounter UDS over classical CAN, UDS over CAN FD, or UDS over DoIP.

For a broader comparison of the physical networks, see our DoIP vs CAN bus diagnostics guide.

What Is OBDonUDS?

OBDonUDS is the name for the regulated OBD communication defined by SAE J1979-2. SAE describes it as communication between a vehicle’s OBD systems and test equipment required by OBD regulations. It uses selected services from the UDS architecture in ISO 14229, along with standardized definitions for emissions and propulsion data.

Traditional SAE J1979 is often discussed in terms of modes and PIDs. OBDonUDS reorganizes the exchange around UDS services and data identifiers while preserving the goal of giving generic test equipment access to required OBD information. It can provide standardized trouble-code, readiness, snapshot, monitor, and live-data functions through the newer service structure.

This does not make every manufacturer-specific UDS function public. OBDonUDS covers regulated information; coding, immobilizer work, configuration, proprietary tests, and programming may still require OEM software, licensed data, authentication, or a secure gateway authorization. Our secure gateway module guide explains why protocol compatibility and permission are separate questions.

What Is CAN FD?

CAN FD means Controller Area Network Flexible Data-rate. Classical CAN carries up to eight data bytes per frame. CAN FD can carry up to 64 bytes and use a higher bit rate during the data portion while retaining a controlled arbitration phase. CAN in Automation identifies the larger payload and faster data phase as its two main advantages.

For diagnostics, a larger frame can reduce the number of segments needed to move longer messages. A faster data phase can also reduce transfer time when the vehicle, interface, and software all support it. That is useful as ECUs expose more data and software packages become larger.

CAN FD does not automatically make every scan eight times faster. Gateway routing, ECU response time, bus loading, security checks, transport settings, and the diagnostic application’s own behavior still matter. It is better to think of CAN FD as increased network capacity, not a universal performance guarantee.

How OBDonUDS and CAN FD Work Together

The technologies occupy different layers. OBDonUDS defines what the tester and vehicle say. CAN FD can provide the link that carries those messages. ISO 15765-2:2024 defines the transport and network services for diagnostics over CAN and supports application layers including enhanced diagnostics, legislated OBD, and WWH-OBD. The standard notes that other specifications decide whether classical CAN, CAN FD, or both are required.

Technology	Main Role	Workshop Question
OBDonUDS	Regulated diagnostic services and data definitions	Does the software understand SAE J1979-2 requests and responses?
CAN FD	CAN data link with larger payloads and optional faster data phase	Does the interface hardware and driver support CAN FD?
DoCAN	Transport and network layer for diagnostics over CAN	Can the complete stack carry diagnostic messages correctly?
DoIP	Diagnostics over Internet Protocol and Ethernet	Does the tool support vehicle discovery, routing, and Ethernet communication?

Why Older Scan Tools May Fail

The 16-pin connector does not prove protocol support. An older interface may have a classical CAN transceiver but no CAN FD capability. Its firmware may not recognize the required frame format, its driver may expose only older APIs, or the diagnostic application may not implement J1979-2. Some low-cost adapters also advertise broad compatibility without identifying the standards they actually support.

Common symptoms include:

The interface powers up but automatic protocol detection fails.
Generic codes are available on one ECU while newer modules remain invisible.
Live-data lists are incomplete, incorrectly decoded, or unavailable.
The application connects through one transport but cannot perform the requested OBD service.
A newer vehicle works with an updated OEM tool but not with an older generic scanner.

Do not immediately blame the vehicle. Confirm the model-year and market requirements, then check the scan-tool maker’s explicit support for SAE J1979-2, CAN FD, and the relevant vehicle. The interface, firmware, driver, and application database must all agree.

What Workshops Should Check Before Buying

Protocol statement: look for explicit OBDonUDS or SAE J1979-2 support, not only “OBD2 compatible.”
Hardware capability: verify CAN FD transceivers and firmware support on every channel the application requires.
Software coverage: confirm the exact vehicle, model year, engine or propulsion type, and market.
Pass-thru support: if using OEM software, verify the required J2534 level and vendor approval. Our J2534, OEM VCI, and ELM327 comparison explains the hardware categories.
Update policy: determine whether protocol and database updates are included, licensed separately, or tied to a subscription.
Security access: check whether legitimate gateway authentication is needed for active tests or clearing faults.

The Transition Is Already Underway

Adoption is not identical across every vehicle class or region. California’s Air Resources Board says heavy-duty manufacturers that currently use SAE J1979 will transition to J1979-2 beginning with the 2027 engine model year. CARB also identifies a limited group of Volvo and Mack families that began using the protocol from the 2024 model year. Tool certification and coverage continue to evolve, so current vendor confirmation matters.

SAE’s second-generation scan-tool practice, J1978-2, was revised in December 2025 and specifies functions for tools accessing regulated services on J1979-2 and J1979-3 vehicles. That is a useful reminder that future-ready diagnostics require both vehicle standards and matching test-equipment behavior.

Conclusione finale

OBDonUDS modernizes regulated OBD communication around selected UDS services. CAN FD expands the capacity of the CAN data link that may carry those messages. Neither term alone guarantees complete vehicle coverage, programming access, or security authorization.

For workshops, the practical response is simple: buy interfaces by documented protocol support, keep firmware and diagnostic software current, and test the complete stack on representative vehicles before promising coverage. The familiar connector remains, but the communication behind it is becoming more capable and more demanding.