Every fleet platform, dashcam system, or diagnostics app that reads live vehicle data starts with the same question: how do you actually get that data out of the car? The answer sounds simple — plug into the OBD II port — but what happens after you plug in is where most of the real engineering work lives. Reading engine RPM, vehicle speed, or a diagnostic trouble code requires implementing the OBD II communication standard correctly, and “the” standard is actually five separate protocols, each with its own quirks, timing rules, and electrical behavior.
This post covers what connecting to a vehicle actually requires: which parameters are realistically available and how reliably, the protocols involved, how OBD II differs from OBDonUDS, what it costs to build this yourself, and when licensing an existing implementation makes more sense.
What Is OBD II, and What Does “Connecting” Actually Mean?
On-board diagnostics (OBD) is the standardized system built into every modern vehicle that lets an external device request data from the vehicle’s electronic control units, or ECUs — the small computers that manage the engine, transmission, and other subsystems. OBD II, mandated for all vehicles in the USA from 1996, is defined by SAE J1979 and sits behind the 16-pin diagnostic connector typically found under the dashboard. That connector is technically standardized separately as SAE J1962, though it’s commonly called “the J1979 connector” since J1979 defines the messages and parameter IDs (PIDs) sent over it — this is what makes OBD II diagnostics possible without a manufacturer-specific tool for every make and model, and what powers automotive OBD tools generally.
Think of OBD II as a shared language, not a direct line. The vehicle doesn’t just hand over data — you have to ask for it, in the right format, using the right protocol, and wait for a response that follows its own timing rules. A vehicle that “supports OBD II” doesn’t necessarily support every parameter in the standard; manufacturers only implement what’s relevant to the systems their vehicle actually has.
What OBD II gives you, when implemented correctly, breaks down into three categories:
- Engine and vehicle operation — RPM, speed, coolant temperature, throttle position, engine run time, fuel level, fuel system status, HEV/EV battery level
- Diagnostic health — malfunction indicator lamp (MIL) status and diagnostic trouble codes (DTCs), the standardized codes a vehicle sets when it detects a fault
- Vehicle identification — the vehicle identification number (VIN)
How Reliable Is Support for These Parameters, in Practice?
The standard defines what a compliant vehicle can expose — not what every vehicle does. In a sample of 3,404 U.S. vehicles spanning model years 2010–2026, we measured how consistently each parameter actually showed up: MIL status and DTC count at 100%, engine run time and vehicle speed at 99.7%, engine RPM at 99.5%, coolant temperature at 96.6%, throttle position at 94.5%, fuel level at 88.8%, and HEV/EV battery level at 87.5% across the 264 hybrid and electric vehicles sampled. Odometer was the outlier — just 27.0% overall.
That low odometer number tells a story about how the standard itself has evolved, not just how well any one implementation works. Splitting the same sample at 2020 shows why: fuel level support moved from 87.1% (MY2010–2020) to 93.8% (MY2020–2026) — a modest, expected improvement. Odometer support moved from 3.8% to 93.3% over the same split. Before 2020, the odometer was almost never exposed as a standard PID at all; on recent model years, it’s now nearly as reliable as fuel level.
The OBD II Communication Standard: Five Protocols in One
Here’s the part that catches most teams off guard. OBD II requires support for ISO 9141-2, KWP 2000, SAE J1850 PWM and VPW, and CAN (ISO 15765-4) — four distinct physical and data-link layer protocols, five if you count the ISO and KWP variants separately. Each was developed by different manufacturers at different points — PWM is largely a Ford protocol (Ford SCP), VPW largely GM (GM Class 2) — so a Ford and a GM vehicle from the same model year may not speak the same protocol at all.
A device that only implements CAN (ISO 15765-4) — the newest and most common protocol — will fail to connect to a meaningful share of older vehicles still on the road. Fleet operators running mixed-age vehicles, or hardware makers targeting broad compatibility, don’t have the option to skip the legacy protocols.
Which Protocol Does a Given Vehicle Use?
There’s no universal lookup table that tells you in advance which protocol a specific vehicle uses — the device has to detect it, cycling through known timing and initialization sequences until it gets a valid response. With OBDonUDS now part of the picture, detection typically needs to attempt a standard OBD II connection first and fall back to OBDonUDS if there’s no response, since a growing number of newer vehicles no longer answer to the legacy protocols at all. Get the detection logic wrong, and you either fail to connect or connect intermittently in a way that’s hard to debug once the device is already in the field.
OBD II Is Being Replaced — Not Removed
A newer standard, OBDonUDS (formally SAE J1979-2), re-expresses the same diagnostic parameters using UDS (Unified Diagnostic Services, ISO 14229) — the deeper diagnostic protocol layer already used for factory-level vehicle diagnostics. It’s a real technical upgrade, not a renamed version of the same thing: two-byte parameter addressing opens up more than 65,000 possible PIDs versus OBD II’s one-byte addressing, and DTCs expand from two bytes to three, supporting over 16 million unique codes. The request mechanics change too — the older standard used Modes 0x01 through 0x0A; OBDonUDS uses UDS services such as Mode 22 instead.
OBDonUDS can replace OBD II on vehicles at any point from the 2024 to 2027 model year so the transition is already underway. We encountered our first vehicle that exclusively supported OBDonUDS, with no OBD II at all, in May 2024, and have seen others since. From 2027 onward, all new vehicles must support OBDonUDS, and once a vehicle makes that switch, it will no longer support legacy OBD II. The good news: OBDonUDS runs over the same CAN hardware and the same 16-pin connector as OBD II — pins 6 and 14 specifically — so supporting it is a software update, not a hardware redesign.
Getting protocol detection right — and keeping it right as new model years arrive — is the majority of the ongoing engineering work behind any OBD II/OBDonUDS implementation. A protocol stack that works cleanly on the test bench often behaves differently once it meets the accumulated quirks of a real, mixed vehicle fleet. We’ve run into most of those quirks ourselves — compatibility testing across more than 60 vehicle manufacturers, and more than 10,000 individual vehicles tested since we started building OBD software in 2009, tends to surface every edge case eventually. That testing is a large part of why more than 76 companies across 20 countries currently license our implementation, now running in over a million devices worldwide, rather than write their own.
Build vs. License: Two Paths to Reading Vehicle Data
Once you understand what OBD II actually requires — five protocols, ongoing vehicle validation, and now a second SAE standard in OBDonUDS — the question becomes how you get there. There are two paths, and they lead to very different timelines.
Building Your Own OBD II Stack
Building in-house means licensing the SAE standards themselves, then writing, testing, and maintaining the implementation.
The cost breaks into three stages: a foundation cost of roughly 1.5 engineer-years to build the core OBD II stack (CAN, ISO, KWP, PWM, VPW) plus ongoing vehicle validation at around 8 hours and $100 in direct cost per vehicle, an on-going cost as that same validation repeats continuously with every new model year, and an upgrade cost of roughly 0.5 engineer-years to add OBDonUDS on top.
- Full control over the codebase and how it integrates with your existing systems
- No per-unit licensing cost once it’s built
- Requires dedicated engineering time, pulled away from other product priorities
- Vehicle validation is an ongoing cost, not a one-time task — new model years need continuous testing, and older vehicles become harder to source over time
Licensing a Ready-Made Stack
Licensing OBD software rather than building it means starting from source code that’s already been built and tested.
- Working code from day one, ported originally from a high-density ARM Cortex reference design and adaptable to any suitable processor
- Automatic protocol detection built in, using a tested sequence rather than logic you build and debug yourself
- Coverage across all required protocols — five protocols under the two governing SAE standards, OBD II (J1979) and OBDonUDS (J1979-2)
- Fully commented C source code, a user API, and a demonstration application included
- One-time licensing fee, less flexible than a fully custom build, though the code remains yours to adapt
- Fully supported by our team of North America based engineers, on call to answer your questions
Learn more about the OBD Software Stack.
Who Actually Needs This, and Why.
Mixed Fleet Telematics Companies
Fleet platforms that build hardware and manage fleet software for large trucks often also need to support a number of light- to mid-duty vehicles so that coverage works across every vehicle in a fleet. A gap in this support is a gap in fleet visibility the moment a customer adds a smaller truck to their fleet.
Telematics Hardware Manufacturers
Telematics device makers launching a new product line need broad protocol and vehicle coverage from the first shipped unit — field failures traced back to protocol detection are expensive to diagnose and worse to explain to a customer.
AI Video Telematics & Dashcam Platforms
Video-first platforms use OBD II data to contextualize what the camera captures — vehicle speed at the moment of a hard-braking event, for example. That context is only as reliable as the underlying connection to the vehicle.
Frequently Asked Questions
OBD II (On-Board Diagnostics II) is the standardized system, defined by SAE J1979, that lets an external device query a vehicle’s ECUs for live data and diagnostic information. It’s been required on U.S. vehicles since 1996, though implementation details vary by manufacturer and model year.
People often search ‘OBD vs OBD II’ expecting two very different systems, but OBD II is simply the current, standardized generation of on-board diagnostics; the original OBD systems it replaced were largely manufacturer-specific, with no common protocol or connector. When people say “OBD” today, they almost always mean OBD II.
The DTC meaning is straightforward: a diagnostic trouble code is a standardized code a vehicle’s computer sets when it detects a fault — anything from a loose gas cap to a failing sensor. DTCs are read through the same OBD II protocol stack used for live parameters; in our own testing, MIL status and DTC count were the most consistently available data points in the entire sample.
OBD II requires support for ISO 9141-2, KWP 2000, SAE J1850 PWM and VPW, and CAN (ISO 15765-4). A device built for a broad, mixed-age fleet needs all of them, not just the newest CAN-based protocol.
People commonly use “J1979 connector” for the physical 16-pin OBD II connector under the dashboard, though it’s technically standardized separately as SAE J1962. SAE J1979 governs the messages and parameter IDs sent through it, and OBDonUDS uses the same connector and pins.
Based on our own build, roughly 2 engineer-years covers core OBD II and OBDonUDS development, but vehicle validation is the larger cost — over 40,000 engineer-hours testing more than 4,500 vehicles in our case. Reaching broad compatibility this way typically takes years.
OBDonUDS (SAE J1979-2) will replace the legacy OBD II protocols, using UDS as the underlying communication layer, and some manufacturers already ship vehicles that support it exclusively. From 2027 onward, all new vehicles must only support OBDonUDS. It runs over the same CAN hardware and connector as OBD II, so supporting it is a software update, not a hardware change.
Final Thoughts
Reading vehicle parameters is conceptually simple — connect, ask, receive data. The OBD II communication protocol underneath that simplicity is five separate standards, each with its own compatibility edge cases and real-world support gaps, layered on top of a diagnostic transition to OBDonUDS that’s already underway.
Whether you build that implementation yourself or license one that’s already been through the process, the vehicle doesn’t care — it just needs a device that speaks its protocol correctly. We’ve spent since 2009 making sure ours does, across more than 60 manufacturers, over 10,000 vehicles tested, and 76+ companies in 20 countries who license it — now running in over a million devices worldwide — rather than build their own.
If you’re deciding which path makes sense for your product, book a demo to see the OBD Stack in action, explore the OBD Software Stack page directly, or check our FAQ and articles for more on how the protocol stack works under the hood.
