Did you miss the

> Making software that's usable by independent shops and consumers costs money

sentence before “calling BS”?

> The black market on stolen parts isn't affected by this.

Cars have more parts than a catalyst, and the used parts market is absolutely, 100% affected by software adaptation locks. You can watch the price of used engine control modules, instrument clusters, and infotainment modules rise as soon as aftermarket tools come out which bypass protections, and the tools to do so are worth a significant sum of money.

> Hellcat engines get swapped all the time

Yes, all protections are eventually bypassed, especially weak Stellantis ones, but that doesn’t mean that the goal wasn’t anti-theft, just that the goals were badly achieved.

Anyway, I think we broadly agree that vehicle diagnostics should be more open, but discounting crime and “security” as objectives doesn’t work, because they’re the main arguments used against regulatory efforts to improve the situation.

EDIT: I read again and I suppose you are arguing that diagnostic tools don’t or shouldn’t cost manufacturers money to make; I simply can’t agree with this argument, any software has a support and maintenance cost which scales with the type and number of users.

▲

tmerc 4 hours ago | parent [-]

Didn't miss that making software costs money. The point is making it protected costs more money and mainly hurts independent repair shops and consumers. Afaik, manufactures can set obd2 codes outside the mandatory codes, but still compatible with the protocol. 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.

I do agree that diagnostics need to be open. I discount security because at the end of the day, an engine is a bunch of metal. Put a haltec on it and all that security means nothing. Doesn't mean we shouldn't have immobilizers, strong encryption in our key fobs, etc. Security should be to keep the car and the contents from being stolen in the first place. But a flat bed bypasses all security as does a chop shop. So given that low value of bcm to ecu and similar "security" once a vehicle has been stolen, I'd rather be able to swap a good engine into a good body and keep a car on the road rather than in the junk yard.

Sorry for the hot take of bs. I own both of my cars outright and the industry trying to keep me from fixing what I own has me a bit upset. The security argument in the parent post sounds a lot like the "don't give our keys to China" propaganda.

	▲	bri3d 6 minutes ago \| parent [-]
		> 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_. So, 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 :)