WWH-OBD (ISO 27145) Explained: UDS over CAN & DoIP (2025)

Updated at 14 Aug, 2025

- Where WWH-OBD fits, how it maps to J1979-2/-3 and implementation examples, covering both CAN and DoIP transports.

WWH-OBD (ISO 27145) Explained: UDS over CAN & DoIP (2025)

WWH-OBD is the worldwide harmonized OBD communication standard defined by ISO 27145 that applies Unified Diagnostic Services and supports both CAN transport and DoIP.

Vehicle diagnostics is shifting from legacy PIDs to a unified UDS based model. WWH-OBD, defined by ISO 27145, runs over CAN or Ethernet and gives engineers a consistent method to request emissions related data across markets. This guide shows where WWH-OBD fits, how it compares to OBDonUDS, and how to implement it in a garage or across a fleet.

In the domain of vehicle diagnostics, On-Board Diagnostics has been central since the early 1980s. OBD II, deployed widely from 1996, introduced services, Parameter Identifiers, and Diagnostic Trouble Codes.

As vehicles add electrified powertrains, advanced ECUs, and over the air workflows, engineers require a model that scales beyond fixed PIDs and regional variants. That is the space WWH-OBD addresses.

Why WWH-OBD

WWH-OBD exists to reduce fragmentation in diagnostic workflows and to remove regional divergence that increases test cost and integration risk. Under the harmonized model, OEMs publish one consistent dictionary of emissions related data elements that sit on top of UDS services, and tool vendors target a single set of request and response shapes with stable encodings for scaling and units.

This improves repeatability in service bays, enables cross market analytics for fleets, and streamlines software verification because conformance can be validated once against ISO profiles rather than multiple regional variants. The model also supports two transports so that both legacy CAN based setups and newer Ethernet equipped architectures are covered without changing application semantics.

Migration is incremental since UDS services are already present in many ECUs for flashing and security, and WWH-OBD leverages the same infrastructure for readouts and DTC handling. The outcome is a simpler supplier interface, fewer exceptions in scripting, easier training for technicians, and a better foundation for remote diagnostics where bandwidth and latency vary by site. For compliance teams, a single harmonized path reduces audit overhead and accelerates evidence generation for regulatory submissions while keeping the service layer stable across model years.

What is WWH-OBD

World Wide Harmonized On-Board Diagnostics is an ISO standard family that profiles UDS for emissions related diagnostics with a global scope.

The standard defines how external test equipment discovers ECUs, selects sessions, reads identifiers and monitor results, and retrieves or clears diagnostic trouble codes, while keeping payload structure and units consistent across markets. WWH-OBD applies to commercial vehicles first and is designed to extend to passenger vehicles as adoption grows.

The architecture is transport agnostic at the application layer, which means the same service flows operate over DoCAN for classic setups and over DoIP for Ethernet enabled platforms that require higher throughput or multi ECU concurrency.

By centering on UDS, the standard benefits from robust negative response handling, timing control, security access, and session management that service engineers already use for calibration and flashing. For organizations planning a future proof diagnostic stack, WWH-OBD provides the path to unify workshop tools, telematics gateways, and cloud analytics under one dictionary with Versioning and change control while remaining compatible with existing plant and field equipment that still relies on CAN.

Protocol Stack

The WWH-OBD stack maps cleanly onto the OSI model to make responsibilities explicit. At the application layer, UDS services define function codes, request formats, and response semantics for actions such as ReadDataByIdentifier, ReadDTCInformation, and ClearDiagnosticInformation.

The presentation and session concepts are covered by UDS session control and timing parameters like P2 and P2 star, which govern allowable response delays. Transport is provided by DoCAN or DoIP. DoCAN segments large service data units into multiple CAN frames with flow control, block size, and separation time, and works with both 11 bit and 29 bit identifiers depending on ECU addressing. DoIP encapsulates the same UDS packets inside TCP, uses UDP for discovery and vehicle identification, and offers higher concurrency along with clean error reporting and link supervision.

Below transport, the network and data link layers are handled by CAN and Automotive Ethernet respectively, and the physical layer is the vehicle harness or workshop network connection. This separation lets engineering teams tune timing and segmentation per transport without touching the application dictionary, which keeps validation focused and reduces risk when moving from bench to vehicle or from local test rigs to remote service hubs.

The table maps the WWH-OBD diagnostics path onto the OSI model and shows how the same UDS application rides over two transports. Use it to align tools and test setups across CAN and Ethernet without changing application logic.

OSI Layer WWH-OBD Component CAN Path (DoCAN) Ethernet Path (DoIP) Standards / Notes
L7 Application UDS services: ReadDataByIdentifier, ReadDTCInformation, ClearDiagnosticInformation UDS over ISO-TP frames UDS payload over TCP ISO 14229, ISO 27145, SAE J1979-2 and J1979-3 mapping
L6 / L5 Session UDS sessions, timing (P2, P2*), SecurityAccess, NRC handling Same semantics Same semantics ISO 14229-2, 14229-3
L4 Transport Segmentation and flow control ISO-TP (BS, STmin, FC frames) TCP sessions, UDP discovery ISO 15765-2 (DoCAN), ISO 13400-2/-3 (DoIP)
L3 Network Addressing and routing Not used beyond CAN ID routing IPv4 with DoIP addressing ISO 13400-2 network layer
L2 Data Link Frame format and media access CAN 2.0 or CAN FD, 11 or 29 bit IDs Ethernet MAC, 100BASE-T1 ISO 11898-1/-2, IEEE 802.3bw
L1 Physical Connectors and signaling OBD-II DLC (SAE J1962), vehicle CAN wiring Vehicle Ethernet, DoIP diagnostic access SAE J1962, ISO 15031-3, ISO 13400-3

OSI View

Thinking in layers helps practitioners diagnose problems rapidly and choose the right tools. With OBD II, much of the logic was packed into mode and PID sets that assumed CAN and a narrow service range. In the WWH-OBD view, the application logic is entirely UDS based, so diagnostics, flashing, and security share the same service architecture and differ only in identifiers, sessions, and access levels. The transport choice determines performance and ergonomics in the bay. DoCAN is simple to set up via the OBD connector and is ideal for handhelds and quick reads. DoIP enables high speed sessions over Ethernet for heavy data workflows such as retrieving multi ECU monitor states, reading extended DTC lists, or pairing diagnostics with data logging under load. Service tools discover vehicles on the workshop LAN, negotiate connections, and can coordinate concurrent requests with proper timing. When faults occur, isolation is straightforward because errors map to a specific layer, such as transport flow control, UDS negative response, or physical link, which allows technicians to target the root cause without guessing across the stack.

The OBD-II and WWH-OBD differences and similarities on their OSI model

Data Model and DTCs

WWH-OBD moves away from fixed one byte PIDs and relies on structured UDS data identifiers to carry typed payloads with explicit scaling and units. Identifiers include vehicle information such as VIN, calibration IDs, monitor results, and emissions related parameters that service tools can correlate across ECUs. The dictionary sets endianness, bit layout, and error handling so values decode the same way regardless of platform. For faults, the model uses three byte DTC codes with an associated status mask and extended data records, which improves triage and trending. The extra detail captures severity and test completeness, supports healing logic when conditions remain normal, and enables clear separation between pending and confirmed failures. Retrieval uses UDS ReadDTCInformation subfunctions that can filter by status or severity so tools fetch only relevant items, which reduces bandwidth and speeds up dashboards in a workshop or in a fleet back office. For long term analysis, the structured fields allow reliable mapping to cloud schemas, and the presence of units and ranges makes it possible to enforce validation rules and detect outliers that indicate sensor drift or data corruption during transport.

Transports

The transport layer determines throughput and behavior under load but does not change application semantics. With DoCAN, requests are segmented into ISO TP frames when payloads exceed a single frame, and flow control from the ECU manages block size and inter frame space to prevent buffer overruns. Engineers tune separation time and select 11 bit or 29 bit addressing based on network layout and gateway rules. DoIP encapsulates the same UDS payloads in TCP and uses UDP for discovery with vehicle identification and entity status announcements on the workshop subnet. This approach allows multiple concurrent connections and higher sustained throughput, which is valuable during ECU programming, bulk reads, or automated test scripts that touch many identifiers across several controllers. In remote setups, DoIP can traverse controlled networks with proper firewall rules and authentication so central service teams can support sites without shipping hardware. Choosing between the two comes down to available connectors, performance needs, and operational constraints in the workshop. Both transports maintain consistent error signaling so tools can recover and retry without custom logic per vehicle.

Standards Set

WWH-OBD builds on a stable set of ISO standards that divide concerns clearly. ISO 27145 defines the harmonized OBD framework and profiles how UDS services and data dictionaries are applied to emissions related diagnostics. ISO 14229 defines UDS itself, including session control, security, service codes, response formats, and negative response behavior. ISO 15765 defines transport over CAN through ISO TP segmentation and flow control, while ISO 13400 defines diagnostics over IP for Ethernet equipped platforms, including discovery, connection management, and payload encapsulation. Together these documents let teams design repeatable test procedures, select compliant tools, and write scripts that will remain valid across model years. Many organizations supplement the standards with machine readable descriptions such as ODX for data and OTX for procedures to strengthen traceability. Even when those layers are not adopted, the standards are designed to be self sufficient so that a minimal UDS implementation on either transport can achieve full WWH-OBD coverage without proprietary extensions or vendor lock in.

Capabilities

Harmonized capabilities focus on emissions related diagnostics that must be available in every market under a common profile. Service tools can read vehicle information, retrieve monitor readiness and results, list and clear DTCs, and access additional identifiers that support root cause analysis or confirm repairs. Because the profile sits on top of UDS, it inherits advanced features like controlled sessions for programming, seed and key mechanisms for security, and clean negative response codes for robust error handling.

The same dictionary works over CAN or Ethernet so workshop staff can pick the most convenient transport without retraining or rewriting scripts. For fleets, the profile makes it possible to collect comparable data across brands and regions, which improves statistical quality and reduces false alarms during large scale monitoring. The common structure also supports a gradual migration from legacy tooling because intermediate gateways can translate transport while leaving application semantics intact, which helps with budget and change management.

Fault Semantics

Fault handling in WWH-OBD is designed to support decision making rather than simply indicating that something went wrong. DTCs carry an explicit status mask that shows whether a fault is pending, confirmed, or has healed under the prescribed number of drive cycles. Extended data records provide snapshots such as odometer at first detection, engine run time since clear, or environmental conditions that occurred when the fault was detected. Severity classes indicate how urgent the repair is likely to be, which allows service teams to triage work orders and avoid unnecessary downtime. The model also aligns with global technical regulation categories so emission related failures are tracked consistently for compliance reporting. Because everything is standardized, dashboards can aggregate across vehicles and produce meaningful rates by class and severity, while technicians can drill into single events with predictable structure. Clearing follows UDS rules so the system knows which data gets reset and which learned values persist, which reduces confusion after maintenance and helps confirm that a repair actually addressed the root cause.

WWH-OBD vs OBDonUDS

WWH-OBD and the SAE OBDonUDS family share the same UDS foundation and both intend to replace legacy OBD modes and PIDs. WWH-OBD aims at global harmonization under ISO governance with a unified dictionary that travels between transports, while OBDonUDS provides a service mapping for combustion engines and a dedicated profile for zero emission vehicles. Many organizations will need both because mixed fleets include ICE and EV platforms with different regulatory needs. The important takeaway for implementation is that the tooling stack can be common, since the application layer is UDS, and differences are in data dictionaries and compliance scope rather than in transport or service logic. Teams can design one set of components and load the appropriate profile per vehicle type while keeping operator experience and data pipelines identical.

Standard Scope Application Model Transports Notes
ISO 27145 WWH-OBD Global emissions diagnostics UDS with common dictionary DoCAN, DoIP Global alignment goal
SAE J1979-2 OBD for combustion engines UDS service mapping DoCAN, DoIP Replaces legacy modes and PIDs
SAE J1979-3 ZEV diagnostics for BEV and PHEV UDS with ZEV data set DoCAN, DoIP Electric powertrain focus

Standards Compared

Service organizations often support vehicles that span multiple standards. This comparison clarifies how WWH-OBD relates to OBD-II and EOBD for light duty and to heavy duty OBD based on J1939. The matrix highlights the application model, transport expectations, addressing, and typical domains so teams can choose the right interface and data decoders for each asset. With this view, it becomes easier to plan tool purchases, training, and analytics pipelines that account for differences while maximizing reuse where UDS is present.

Aspect WWH-OBD OBD-II EOBD HD OBD
Application UDS profile Modes and PIDs Modes and PIDs J1939 SPNs and PGNs
Transport DoCAN or DoIP CAN 11 bit typical CAN 11 bit typical CAN J1939
Addressing UDS addressing Functional 0x7DF, physical 0x7E0 Similar to OBD-II J1939 addressing
Domains Global emissions diagnostics Light duty North America Light duty Europe Heavy duty on-road and off-highway

DoCAN vs DoIP

Selecting a transport is a tradeoff between convenience and throughput. DoCAN leverages the familiar OBD connector and simple cabling which makes it ideal for mobile technicians and quick checks where bandwidth needs are modest. DoIP uses the vehicle Ethernet interface to deliver high sustained rates and multiple parallel sessions that are well suited to software download, fleet automation, and regression test rigs. Because the application layer is identical, organizations can start on DoCAN and move high volume jobs to DoIP without rewriting their UDS layer. The table summarizes the main differences to support planning for workshops that are upgrading to Ethernet based service infrastructure.

Criteria DoCAN DoIP
Bandwidth 1 Mbit s typical 100 Mbit s typical
Setup OBD port and CAN interface Vehicle Ethernet and workshop LAN
Use cases In-bay tests and handheld readers ECU flashing and remote benches

Request Examples

The following snippets illustrate a minimal end to end path. On the vehicle network, bring up a SocketCAN interface, then send a UDS ReadDataByIdentifier request for VIN to a powertrain ECU and watch for positive responses. In the cloud, query recent telemetry through the AutoPi API which aggregates device side measurements and diagnostic snapshots for fleet analysis. These examples omit security steps such as seed and key for protected services and should be used in a test environment with proper authorization. Always follow workshop safety rules and local regulations when interacting with vehicle networks and never run intrusive services on public roads or without OEM permission. Replace placeholders with your device identifiers and tokens, and consider wrapping these calls in automated scripts that record timestamps, bus load, and response codes to aid troubleshooting during deployment.

# Bring up CAN at 500 kbit s
sudo ip link set can0 up type can bitrate 500000

# Send UDS ReadDataByIdentifier for VIN (0xF190) to ECU at 0x7E0
cansend can0 7E0#0222F190

# Watch responses. Expect 0x62 F1 90 followed by VIN bytes
candump can0,0:0,#FFFFFFFF
# Fetch recent telemetry from AutoPi Cloud
curl -H "Authorization: Token YOUR_API_TOKEN" \
  "https://api.autopi.io/telemetry?device_id=YOUR_DEVICE&limit=100"

Implementation

A practical rollout balances quick wins in the workshop with a scalable fleet architecture. For benches and garages, start by validating UDS service coverage on a representative vehicle with a SocketCAN interface or an AutoPi device. Confirm session control timing, verify that negative responses are handled correctly, and document data identifier decoding with units and scaling.

Build a small Python harness that wraps common requests such as ReadDataByIdentifier and ReadDTCInformation, then persist results to CSV for review. For DoIP, provision the workshop network with a diagnostic VLAN and enable discovery to simplify connection flows. For fleets, deploy AutoPi TMU CM4 or AutoPi CAN-FD Pro at the edge, define periodic jobs that read identifiers and DTC status with rate limits that respect bus load, and forward the results to AutoPi Cloud.

Use the cloud to set alert rules on fault class and severity, add dashboards for readiness monitors, and export daily summaries to maintenance systems. Secure the stack with device certificates, rotate API tokens, and apply signed OTA updates to keep the edge software current. Document fallback behavior for loss of connectivity and define a clear path for remote support so technicians can escalate issues with complete logs that include raw frames, response codes, and timestamps.

Bench or Garage

Use a SocketCAN capable interface or an AutoPi device. Bring up can0, send UDS requests, and validate positive responses. For DoIP, connect via Ethernet and use a UDS capable suite that supports discovery. Automate with Python to parse identifiers, DTCs, and OBDonUDS data where required.

Fleet

Deploy AutoPi TMU CM4 or AutoPi CAN-FD Pro. Configure periodic UDS jobs to read identifiers, monitors, and DTC status. Buffer on device, forward to AutoPi Cloud, and alert on fault class and severity. Export daily summaries to maintenance systems and secure with token based APIs and signed OTA updates.

Benefits and Limits

A harmonized approach improves reliability, speeds training, and makes analytics more trustworthy, yet it does not remove every edge case. On the benefit side, a single UDS based dictionary produces repeatable results, reduces custom decoders, and allows a common scripting layer to run over both CAN and Ethernet. Throughput can scale with DoIP without changing the application code, which shortens service times and supports remote diagnostics.

For limits, adoption timelines vary by region and vehicle line, so mixed fleets will still see legacy OBD and J1939 in parallel for years. Some ECUs restrict service access by security level, which requires proper seed and key handling and appropriate permissions for field use. Physical constraints such as gateway routing and bus load can affect perceived performance and must be measured and tuned. Finally, compliance reporting can demand specific monitor sets or metadata that require careful mapping even under a harmonized umbrella.

Outlook

The transition from regional OBD variants to a single WWH-OBD profile is already underway in commercial vehicles and will continue as passenger platforms adopt Ethernet and consolidate diagnostics on UDS. Organizations that invest now in transport agnostic tooling, clean data dictionaries, and automated test infrastructure will see immediate gains in workshop efficiency and long term gains in analytics quality.

As more ECUs expose standardized identifiers and monitor sets, remote diagnostics and predictive maintenance become easier to operate at scale because signal semantics are stable and comparable. Over the next cycles, expect higher use of DoIP in production lines and service bays, broader availability of machine readable descriptions, and stronger security controls integrated with service workflows. Planning for these shifts today shortens future migration windows and ensures that diagnostic programs remain compliant, efficient, and ready for mixed powertrains across global markets.

Other posts you will like

Build a Raspberry Pi Touchscreen Car Computer (Step-by-Step)
Raspberry Pi DIY

Build a Raspberry Pi Touchscreen Car Computer (Step-by-Step)

Assemble a Pi-based carputer with touchscreen, power, mounting and software setup. Parts list, wiring tips and configuration for a reliable in-car sys ...

J1939 Explained (2025): PGNs, SPNs & Heavy-Duty Diagnostics
Guides

J1939 Explained (2025): PGNs, SPNs & Heavy-Duty Diagnostics

Learn J1939 basics‚ PGNs, SPNs, addressing and tools for heavy-duty trucks and machinery. Examples and troubleshooting tips included.

CAN Bus Explained (2025): Frames, Arbitration & Tools
Guides

CAN Bus Explained (2025): Frames, Arbitration & Tools

Understand identifiers, arbitration, error handling and analyzers used in automotive systems. Practical examples and diagrams.

STILL HAVE QUESTIONS?

Get in touch with us – We're ready to answer any and all questions.

* Mandatory fields

Email our engineers

We are here to help!