There's no reason technology has to be user-hostile. You can still have an ECU and screens and everything. When it breaks the screen can be used to tell you exactly which sensor input is out of range. There's no reason parts need to be serialized and learning a new part can only be done once.
You can build a modern vehicle that's still repairable.
Modules need to be programmed for your vehicle specs and country because there are different laws and functions.
For example rear taillights are different in Europe vs the US.
Another is that higher trims of my car have a rear climate zone which has a different fan and actuators for air flow that the module needs to know exist.
> Modules need to be programmed for your vehicle specs and country because there are different laws and functions.
So are different intervalls of oil change between Australia and Europe - and yet, even in the 90s, people were able to keep that in mind.
We got taught to be helpless by the industry, so they can help us out. If that mindset would have existed in the 60s, 70s, then there would not be a "true to OEM" aftermarket available for car parts. We need to get back to that.
We got taught to be helpless by the industry, so they can help us out.
industry is pretty damn good at figuring out what customers actually want, instead of just what customer say they want and then don't actually buy.
cars are the way they are because that's what the overwhelming majority of car buyers actually want. The average driver doesn't want their car spitting out error codes, they want a check engine light to tell them to take it to a mechanic, and any information beyond that is confusing.
Are you sure that's what customers want, or maybe it's what dealers want?
The check engine light tells you nothing. It tells your local mechanic nothing. Do you can't get the problem fixed easily or cheaply.
What it does, is force you to take the car to a dealer, who has the specialist, proprietary equipment needed to interpret the fault. And these gatekeepers will charge you a fat premium for that.
So no. I don't think this design choices are driven by a desire to serve the customer.
the check engine light tells you there's an OBD code available to be read. you can buy a reader for $20 on amazon, or your local hardware store, or i've even seen them at gas stations. you don't need "specialist proprietary equipment" that "gatekeepers charge a fat premium" for. this isn't magic.
most people take it to a mechanic instead, because that's what they'd rather do.
Not entirely correct. OBD only mandates emissions information to be made available in a standardized way.
There are plenty of proprietary codes that might set a malfunction light and not show up on an OBD reader, or not be interpreted by it.
(there are tools that reverse-engineer the proprietary protocols that can show those codes, but they aren't $20 - more like $200 and up)
I really don't see why you're defending hiding information. Even for someone who doesn't want to mess around and would just take it to a dealer, making the information available without the need for a code reader will not hurt in any way.
Even if I get the DTC codes out of the OBD - and then? Without the manufacturers service manual, I'm lost at interpreting the codes. For older cars, these manuals are somehow "obtainable" through "sources", but do not expect the manufacturer to help you out if, in fact, you are interested in fixing your own car.
If the industry was actually good at figuring out what the customer wanted, gm wouldn't be cancelling carplay.
The industry makes cars more expense because it makes them more money. Some consumers want big and flashy. Some want cheap and reliable with enough space for cargo and passengers. Only one of those is being served currently. The rest of the industry is drifting to the up market with even the base trim being too expensive for many consumers.
Looking at current sales trends isn't adequate to gauge consumer demand for products that don't exist because they can't be purchased and something else has to take it's place.
Sure, but the reasons programming requires proprietary software accessible only to the dealer via some kind of online access are depressing: laziness, greed, and crime.
Making software that's usable by independent shops and consumers costs money, eliminates business lock-in to dealers, and boosts the gray/black market for broken or stolen parts, so the only reason manufacturers do it at all is when they are required to by regulation.
It takes more effort to implement proprietary protocols and codes in addition to the globally mandated obd2 protocol. You can extend obd2 with additional codes that could be read by a simple device. It costs money to run servers that check your license to read those proprietary codes. It's not laziness.
The black market on stolen parts isn't affected by this. Catalytic converter are stolen and resold all the time and swapping one doesn't require anything more complex than a socket set and a new gasket (assuming the thief didn't use a cutting tool, but then you just weld). Cats also get sold for scrap, so not sure what the software lock is gonna do for that.
Hellcat engines get swapped all the time. ECUs get flashed by the black market regardless of the software locks.
But what we see this proprietary software get used for is blocking the ability to swap brake pads and block heated seats.
> 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.
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.
> 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 :)
Thanks for taking the time to give a thorough explanation. I'm going to have to spend more time reading through, but on a first read, I think you know way more about this than I do. I can't find "edit" to call out my mistake in the parent, but I agree it's a mistake from my lack of knowledge here.
Sorry again for calling it bs. Your cynicism comment does hit home a bit, so I'll make some efforts to temper that in the future :)
So the screen can ask for the programming data to be entered or loaded from a USB stick given to you when you buy the vehicle. There’s no reason this can only be done with a proprietary tool you often can’t get legally at all and have to resort to piracy or reverse-engineered aftermarket options. There’s also no reason this can only be done once and then the module is junk.
Hardware differences can be autodetected in some cases.
That’s just a bunch of “if”s. And they are already programmed. But instead of coming directly built in on the vehicle you need to purchase a very expensive tool that hooks on the port and then tells you what the vehicle should tell you in the first place.
You can build a modern vehicle that's still repairable.