A growing list of late-model vehicles has stopped answering the standardized OBD-II questions most scan tools know how to ask. Here is why “supports UDS” does not solve that problem—and why OBDAI went all the way to SAE J1979-2.
There are 2025 and 2026 vehicles on the road right now that many of the generic scan tools mechanics already own cannot test. The 2027 models are next—and by then the transition is no longer optional.
Not obscure vehicles. Not one manufacturer making one weird engineering decision.
Ford Explorer, Expedition, Maverick, and Bronco Sport. Chevrolet Tahoe and Suburban. Honda CR-V, Pilot, Passport, and HR-V. Toyota RAV4 and Land Cruiser. BMW X-series and 4- and 5-series vehicles. Mercedes-Benz GLC, CLE, C-Class, and E-Class vehicles. Acura, Buick, Cadillac, GMC, Kia, Lexus, Lincoln, Mazda, Mini, Subaru, and more.
That does not mean every trim of every model named above behaves the same way. It means this is no longer a future problem, and it is not confined to one make, one price class, or one kind of powertrain.
Can I get OBDonUDS? Check eligibility, rollout order, and the deadlines.
Manufacturers have started documenting the change publicly. Ford’s May 2025 OBDonUDS bulletin identifies J1979-2 implementations in specific Maverick, Mustang, Bronco Sport, Explorer, Expedition, Expedition Max, Navigator, and Transit configurations. The bulletin is available through the National OBD Clearinghouse Vehicle OEM Database.
The connector is still under the dashboard.
The adapter may still power up.
Your scan tool may connect perfectly to the adapter.
Then it asks the vehicle for standardized OBD-II data and gets nothing useful back.
The car is not necessarily broken. The scan tool may simply be speaking the language that OBD-II used for the last thirty years.
Some new vehicles have moved on.
Prefer the short cut? Watch the 90-second vertical OBDonUDS demonstration.
If this transition began with the 2023 model year, why have independent shops not been screaming about it for three years?
Because the first wave was still living inside the dealership ecosystem.
When a nearly new vehicle turns on the check-engine light, most owners take it back to the dealer. The dealer has the factory diagnostic system, the car gets handled there, and the independent shop never sees the communication failure.
Now those warranties are beginning to run out.
There may still be separate powertrain or emissions coverage on a particular component. Most customers do not know every overlapping warranty that applies to their vehicle. Once they believe the manufacturer’s ordinary new-car warranty is over, many stop automatically returning to the dealer and start looking for an independent shop they trust.
That is the wave that matters.
The 2023 OBDonUDS vehicles are beginning to age and accumulate mileage out of the dealership-first period. The 2024 cohort follows. Then the 2025s. Every year, more of these vehicles move into independent repair bays.
That is when a standards transition becomes a shop-revenue problem.
The customer arrives with an ordinary late-model vehicle. The connector fits. The scan tool powers up. The shop has successfully tested hundreds of OBD-II vehicles with the same equipment.
Then this one will not answer.
If the tool cannot speak J1979-2, the independent shop loses the diagnostic before it can sell the repair. The owner gets sent back to the dealer or to another shop with the right equipment.
The transition happened in the vehicle first.
The business impact begins when the customer stops automatically going back to the dealer.
In this industry, generic does not mean cheap, stupid, or amateur. It means standardized.
A generic OBD-II scan tool asks for the emissions-related information that vehicle manufacturers are required to make available through a common standard. That common layer is what lets one tool communicate with a Ford, Honda, BMW, Toyota, or Chevrolet without buying a separate factory system for every brand.
The $30 code reader and the $8,000 professional scan tool may be radically different products. The expensive tool may add every module, bidirectional controls, coding, resets, guided tests, repair information, and years of reverse-engineered OEM coverage.
But when both tools enter the standardized OBD-II layer, they are supposed to ask the same published questions and understand the same published answers.
That shared language is one of the most important things the automotive industry ever built. It gave independent shops and ordinary vehicle owners access to diagnostic evidence that had previously been fragmented across manufacturers.
Calling it “the generic stuff” as though it is beneath a professional technician misses the point.
The generic standard is the only diagnostic language every manufacturer is required to share.
The story starts with SAE J1979.
The standard was first issued in 1991 as regulators and the industry were building what became OBD-II. By the 1996 model year, full OBD-II compliance was required across new light-duty cars and trucks in the United States.
J1979 defined the familiar diagnostic test modes and the request-and-response messages that vehicle manufacturers and scan tools would use for emissions-related data:
Over the next three decades, that standard expanded enormously. New parameters were added for gasoline, diesel, hybrid, and electrified powertrains. More monitor data became available. More diagnostic evidence was standardized.
But the basic conversation remained recognizable: the scan tool asked for a mode and parameter. The vehicle answered in the J1979 format.
We now call that first-generation path J1979-1 because a second generation exists.
Modern vehicles already use Unified Diagnostic Services—UDS, formally ISO 14229—for an enormous amount of manufacturer-specific diagnostic communication.
So the industry created SAE J1979-2, called OBDonUDS, to carry the standardized OBD-II dataset through UDS services and data identifiers.
J1979-2 was issued in 2021. Its U.S. phase-in began for the 2023 model year, with a transition through 2026. During that transition, manufacturers could support the older path, the new path, or both where allowed. For 2027, the new standardized path becomes mandatory under the adopting requirements.
The physical connector did not need to change. CAN did not disappear. The requirement to expose standardized diagnostic information did not disappear.
The question changed.
Where an older tool asks for current data with a Mode 01 request, an OBDonUDS tool uses UDS service $22 and standardized data identifiers. Trouble codes, freeze frames, monitor tests, readiness, vehicle information, and other regulated information move through the J1979-2 service structure.
It is still OBD-II.
It is still the generic, standardized diagnostic layer.
It is OBD-II over UDS.
And if a vehicle is configured to answer only that new standardized path, a tool that knows only J1979-1 can plug in, light up, and still fail before the diagnostic job begins.
This is where the scan-tool market is going to confuse a lot of mechanics.
Look at the feature page for an expensive professional scan tool and you may see UDS, DoIP, topology mapping, ECU coding, module programming, active tests, forty resets, and coverage for dozens of makes.
That sounds comprehensive because it is a long list.
It does not answer this question:
Does the tool implement SAE J1979-2 OBDonUDS as a complete standardized scan-tool workflow?
UDS is a diagnostic framework. Manufacturers use it for their own module functions, identifiers, routines, programming, and security. A tool may use UDS to perform an OEM-specific service function on one vehicle and still not implement the standardized J1979-2 path that replaces the old OBD-II modes.
Those are different claims.
“Supports ISO 14229 UDS” does not automatically mean:
A UDS logo can be true and still answer the wrong question.
This is not an argument that expensive professional tools are useless. They are not. If you need an ABS bleed, battery registration, key programming, manufacturer-specific relearn, module coding, or bidirectional control, that OEM-level coverage can be worth every dollar.
But understand what those companies have been competing to sell.
They compete on the number of makes, modules, resets, active tests, coding functions, and proprietary operations they can put on a feature sheet. Those capabilities require constant reverse engineering and vehicle-by-vehicle maintenance. They are expensive to build, expensive to keep current, and easy to market because “forty service functions” sounds more valuable than “we implemented every part of the generic standard correctly.”
The standardized layer became the checkbox everybody assumed was finished.
It was not finished.
Many tools never surfaced the complete J1979-1 dataset mechanics already had available. Mode 06 is the obvious example. The vehicle runs its own monitor tests and reports the measured results against the manufacturer’s limits, yet many inexpensive tools omit that evidence and many professional tools bury it in raw or poorly decoded tables.
OBDAI spent this year completing that older language: the full current J1979-1 parameter set, monitor-test decoding, cross-drive trends, readiness, freeze frames, fault history, and the evidence pipeline ARIA reasons over.
Then we built the second language.
Not because “UDS” would look good in a protocol list.
Because without J1979-2, there are new cars the tool cannot diagnose at all through the standardized path.
OBDAI’s OBDonUDS path exists now.
It is implemented in the product. It is running through our OBD BLE GEN2 hardware on the bench. It is not a roadmap slide, a mockup, or a renamed connection mode.
When the legacy standardized probe receives no response, OBDAI follows the J1979-2 detection path and asks the vehicle whether it speaks OBDonUDS. Once detected, OBDAI can establish the UDS conversation, discover supported data, collect responses from multiple ECUs, read current parameters, retrieve confirmed, pending, and permanent DTC information, preserve fault snapshots, read readiness, process monitor-test results, collect vehicle identification, and carry the evidence into the same cloud and ARIA workflow used for J1979-1 vehicles.
We have exercised that flow over both 11-bit and 29-bit CAN addressing. We have tested functional requests, physical ECU requests, multi-frame responses, and the J1979-2-only readiness-group data that can tell ARIA not merely that a monitor is incomplete, but which DTC-level monitor evidence is still waiting to complete.
That last part is exactly why merely translating the old modes was not enough. J1979-2 is capable of giving a technician more diagnostic context than J1979-1 ever could.
SAE designed OBDonUDS to do more than translate the old diagnostic modes. J1979-2 adds DTC-level readiness, extended fault records, readiness-to-DTC mapping, and multiple fault snapshots—new diagnostic context that did not exist in the classic workflow. That distinction is documented in the official SAE J1979-2 standard description.
The remaining work is field validation across real vehicles. A bench simulator can prove that the implementation speaks the standard correctly and that the entire OBDAI pipeline handles the result. It cannot represent every timing decision, gateway, ECU combination, or manufacturer implementation we will meet in the field.
That is what the first qualifying cohort is for.
There are engineering, development, and regulatory-compliance systems that advertise J1979-2. They are not what an independent technician buys to turn vehicle evidence into a customer-facing diagnostic job.
I have been building vehicle emissions inspection programs since 1998. It is a small field, and I have spent my career in it.
Among AI-powered diagnostic platforms built for independent technicians and shops, I have not found another company publicly documenting the complete path we have implemented: automatic J1979-1/J1979-2 detection, the standardized OBDonUDS services, multi-ECU evidence collection, monitor and readiness data, fault snapshots, cloud continuity, and an AI reasoning layer that understands what changed.
That is the market in which I am willing to say it plainly:
OBDAI got there first.
If another scan-tool company supports SAE J1979-2, it should say SAE J1979-2 or OBDonUDS explicitly. It should be able to describe what it does after the legacy request receives no answer. It should be able to show standardized DTCs, readiness, freeze frames, monitor tests, and vehicle information coming through the new path.
Do not ask a salesperson whether the tool “supports UDS.” That question is too broad.
Ask this:
Does this tool explicitly support SAE J1979-2 OBDonUDS as a generic scan tool—not just manufacturer-specific UDS functions?
If the specification does not name J1979-2 or OBDonUDS, do not let a generic “UDS supported” badge answer a different question.
A protocol name does not make a shop money.
Finishing the diagnostic does.
If your tool cannot start the correct standardized conversation, you do not get the live data. You do not get the fault evidence. You do not get the freeze frame, readiness picture, monitor-test results, ARIA analysis, or professional report.
The job stops at “no communication,” and the vehicle goes somewhere else.
OBDAI is built for people who use ARIA to make money. That is our definition of PRO: not a job title, not the size of the building, and not whether somebody else considers you a “real mechanic.” If you use vehicle evidence to diagnose a problem, explain it, document it, and create billable work, you are the person we are building this for.
OBDonUDS protects that workflow as the vehicle fleet changes underneath it.
The connector looks the same.
The old question is already going unanswered.
OBDAI knows the new one.
OBDonUDS will roll out in stages on OBD BLE GEN2 hardware.
PRO goes first. The field beta launches in September 2026 for qualifying existing GEN2 PRO customers. The full PRO release follows quickly after the field beta. Qualifying GEN2 Premium customers will receive OBDonUDS in 2027.
That creates two different deadlines with two different purposes.
If you already purchased a GEN2 Premium or PRO package but never redeemed the licence, redeem it by September 30, 2026 at 11:59 PM Pacific.
Redemption activates the licence you already bought at the price you paid and places the account in the qualifying OBDonUDS cohort.
A new GEN2 PRO customer who wants to be considered for the beta must also purchase and redeem by September 30.
New customers who purchase an eligible GEN2 Premium or PRO package by October 31, 2026 at 11:59 PM Pacific will purchase at current pricing and qualify to receive OBDonUDS with the rollout for their tier at no additional OBDonUDS feature charge.
That is the currently scheduled cutoff. OBDAI may extend the offer. If it is extended, the published eligibility and current-price deadline will move together.
The order is:
Purchases made after the cutoff will be governed by whatever OBDonUDS plans, eligibility rules, and pricing are offered at that time.
Choose OBD BLE GEN2 + PRO — $299.00 for the first year including the adapter, then $265.00 per year
Already purchased? Redeem by September 30.
Redeem your licence — setup and activation instructions
These public primary sources support the standards history, implementation schedule, scan-tool requirements, and named Ford examples discussed above:
Share:
