by bri3d | 2026-01-11 21:15:37+00:00
> afaik, manufactures can set obd2 codes outside the mandatory codes, but still compatible with the protocol.

No, and I think this misunderstanding drives a misunderstanding of the economic factors. There is no universal automotive diagnostic protocol that manufacturers simply are choosing not to use. There is UDS, but it isn't universal in a meaningfully useful way.

This is actually pretty nuanced: road cars _have_ to support a minimum subset of DoCAN / ISO 15765-4 in most regions (for example, since 2006 in the US). This defines very specific emissions-related parameters and codes which regulators read to perform compliance inspections. It is extremely limited and does not provide for meaningful programming, adaptation, or "extended" diagnosis in any way. Additionally, ISO 14229 is only required for emissions critical control modules, so everything else (ADAS, infotainment, body control, sensors, etc etc) can live in whatever proprietary place it wants.

Next, there is UDS (ISO 14229) which can run alongside over the same transport layer (ISO-TP / ISO15765-2), but it's a separate application protocol and there's no reason manufacturers need to support it; they already paid some of the cost by needing ISO-TP for OBD, but it's not the same application layer. This defines common actions like "read identifier" or "start procedure," but does not define in any way what these identifiers or procedures _are_.

And finally, due to regulation in some regions, control modules need to support specific diagnostic tasks and especially module reflashing using a hardware dongle whose drivers have a specific set of DLL exports called J1939 (designed to decouple manufacturer dongle hardware from diagnostics, but not effective), which effectively means those modules must be accessible over CAN for these specific actions.

Even if manufacturers choose to use UDS (to save themselves money on developing their own software, usually, to your point), everything on top of UDS is completely proprietary; besides a few common local identifiers like VIN and some part numbers, each diagnostic parameter set is specific to each individual control module. That is to say, something like "boost pressure" will not be the same local identifier or byte-to-value translation formula across even ECUs in a single product family. And, there is no standard manufacturers could choose to employ at this granularity even if they would like to, and it would be very difficult to make one; it would need to be a discovery-oriented protocol rather than a prescriptive one, since each control module will necessarily have different internal variables depending on its chosen control strategy.

In Europe, things are closer to standardized by accident. European vendors have broadly adopted AUTOSAR (a massively overcomplicated architecture specification for vehicle control modules). A side effect of building on this framework is that most control modules produce ASAP2 / D-ODX definition files for diagnostics. So for European cars, there could be a chance of making a standardized open diagnostic tool if manufacturers were required to provide the D-ODX files for their control modules... which, they're not; most of their dealer tools work off of some recompiled and obfuscated form of D-ODX like the MCD format used in ODIS.

Anyway, even in this ideal world, this doesn't work worldwide; AUTOSAR has mixed adoption in the US and China and virtually no adoption in Japan or Korean manufacturers. Outside of Europe, manufacturers almost always have manufacturer diagnosis protocols which range from UDS-esque to completely made up.

> If they elect to not do this in favor of creating their own protocol, I think we can agree that it costs more but does not have any benefit other than to the manufacturer and dealer network.

Again: most of these manufacturer protocols were made before _any_ standard existed whatsoever, and even today there _is no_ standard protocol beyond 15765-4/WW-OBD which would allow a "generic" / "open" diagnostic tool to exist. So, there is a definite benefit to manufacturers in maintaining "internal" protocols when they already existed which goes far deeper than trying to screw the little guy: they don't have to do anything! Which goes back to laziness.

Some examples:

* Modern Fords generally use UDS, but they have two CAN busses exposed on the diagnostic connector, one that they call HS-CAN which is also the standard OBD bus, and a second called MS-CAN which is proprietary and used for other control modules. This wasn't done to screw over independent shops but rather because they already had a 125kbit CANbus for body control modules and didn't want to spend the effort to integrate everything through a gateway.

* GM have a system called GMLAN, which is a single wire variant of CAN that's actually standardized as J2411, but they have their own diagnostic protocols on top of it. And again, it's not that they set out to screw over shops, it's that they built the system they wanted based on the design criteria they were given. Making a homogenous "open" system would again cost money here.

This is a hot take from me too - I am really annoyed by the recent trend where enshittification drives a weird second-order enshittification: because some corporations act in bad faith some of the time, there is an assumption that all decisions are made with the sole goal of screwing people over. In addition to being caustic from a cynicism standpoint, this trend has eroded curiosity. Rather than doing research and development, people would rather rage against a mysterious "opponent." To be clear, I actually think your comment was a very weak example of this, it's certainly no Apple thread - but since this is a place where I have a lot of knowledge, I figured I'd chime in :)