I kinda wish, as it stands it feels like decades of different protocols and technologies awkwardly stitched together. In theory everything would be connected on a central bus to a centralized RTOS computer able to read every sensor and adjust everything that needs it 1000x a second (or more), so that anyone could easily hook up a new device or software and subscribe to an event bus, but alas.

Mostly every component on modern cars uses the CAN bus for communication https://en.wikipedia.org/wiki/CAN_bus

Many third party companies have made accessories to read information or control devices using it. Cars also have a standard diagnostic port called the OBD2 which you can purchase $10 readers that use bluetooth with your phone.

Cars may have much more electronics but with all the sensors it's very easy to know what part of the system is broken. For example on my mom's 2011 Honda Civic (about 100k miles) her check engine light came on. I read the codes and it was the transmission pressure switch. I purchased one for about $30, replaced it, and everything is running fine.

As to all these new electronic systems and their value:

A 1964 Pontiac Tempest GTI has a 6.4 liter v8 engine that makes 348hp[1]. It goes from 0 to 60 in 4.6 seconds and does the 1/4 mile in 13.1 seconds. It gets 11mpg~

A 2022 Volkswagen Golf R has a 2.0 liter i4 engine that makes 315hp. It goes from 0 to 60 in 3.9 seconds and does the 1/4 mile in 12.5 seconds. It gets 23mpg[2] (26city 30hwy). It also has all modern emissions requirements.

[1]HP numbers were overrated pre 1990s because manufactures would remove accessories during testing.

[2]They changed how cars were rated in the 2000s so the 23mpg would be higher if rated back in 1964

Saying "most cars use the CAN bus" is kind of like saying "the network uses Ethernet," though - the higher layer protocols are usually proprietary and one-off for a specific vehicle lineup.

Even the standard diagnostic protocols like UDS rapidly become non-standard once you get to the "what's what" level. For example, $22 readLocalIdentifier is standardized as "read local identifier," but what each identifier means is again 100% proprietary.

About the only thing that's completely standard is what's mandated by law: OBD-II required parameters and trouble codes. When it comes to trouble codes, even the set beyond the OBD-mandated basics are _also_ usually proprietary, requiring dealer tools or their clones to decode.

You are correct, I was only thinking of diagnostics.

It's important to note that just because a CEL is on for a sensor, it doesn't mean that sensor is bad and needs to be replaced. For example, it's possible for a camshaft position sensor to be on for a timing system that is out of sync. It would be a mistake to replace the cam sensor in that scenario. Shotgunning parts isn't always the answer...

Ooooh, I've got a great story about that. My neighbour's car was at the garage for about three weeks with a No-Crank No-Start fault. The diagnostics said that the crank position sensor was faulty, but the garage said they'd tried two new sensors and a new cam position sensor for good measure, and it still wouldn't work. Their next plan of attack - and bearing in mind they were already about a grand into it - was to spend even more of my neighbour's money speculatively on a new engine ECU.

Tell you what, not to be a smartarse guys, but let me take a look, just for a second opinion, okay? It's not cranking, that should be the first clue. No, I bet the sensor is a red herring.

Why? Well, we'll get to that.

First off, why isn't it cranking? I hear a relay in the fusebox clicking when I turn the key, let's swap this conveniently labelled starter motor relay with a spare - rob one from the heater blower in my car - plug it in, contacts look manky and burnt, never a good sign. Oh look, starts, runs, perfect, nice as you like.

No, don't worry about the relay, they're a couple of quid new and I have huge box of spares at home, just keep it.

Oh, but the sensor? Well, the ECU was commanding the relay on to pull in the starter motor solenoid, right? But then after a certain amount of time it wasn't seeing crank position sensor pulses, so it guessed (wrongly) that the sensor was faulty, because why would it guess that the starter motor wasn't spinning?

Step 1. Replace sensor

2. Replace ECU

3. ???

4. Sell car for scrap

Haha.

It was a 2007 Honda Civic, the 3rd clutch pressure switch measures fluid pressure. P0847 was the code. This means the sensor was sending a voltage value below the acceptable range.

The car shifted fine, the fluid was at the proper level, and there were no noticeable driving issues. This would also not continuously read a low voltage reading while changing gears. This led me to believe it's the sensor, which is very inexpensive and easy to fix. The car is working perfectly now.

I'm glad it was straightforward for you!

A lot of things in the interior uses LIN bus.

The Golf is a 2 liter turbo, i think

isn't that just the can bus?

It is interesting how it evolved that way. As individual components were computerized (ABS, TCS, TCM's, ECM's, etc.), there was no real point at which it made sense to centralized things.

Now, with the silicon shortages, and the ever increasing complexity of vehicle networks, I think things are going to hit a crossover point. Instead of a vehicle full of "microservices", we will probably see more vehicles with some centralized compute unit controlling dozens of sensors and "edge" processors.

It's impossible to fully centralize an automotive computer, but there is a lot of work that can be done to move away from "microservices" to something that is easier to define, develop, and validate

Electrical cars don't need gears and a lot of the other moving parts you find in an ICE car like this. They still need lots of silicon of course.

The Tesla (and several other EV manufacturers) approach to car software is highly centralized. Unlike traditional car manufacturers, there are no external component providers that get to run their own proprietary firmware on their own dedicated chips. Upgrading and testing/integrating all these proprietary firmware blobs is a nightmare and is mostly not a thing with legacy car manufacturers. Tesla and other modern EV manufacturers on the other hand provide over the air updates for essentially all software in the vehicle. Reason: all of that is developed in house and shares a lot of the hardware infrastructure.

One big reason car manufacturers struggle so much with chip shortages is that a lot of the shortages are for decades old chip designs still used by various suppliers for things like brakes, the automatic windows, the fuel injection system, etc. Chip manufacturers are reluctant to invest in new production capacity for obsolete chip designs.

The reason Tesla managed to break some delivery records in the middle of these shortages is that they use more modern chip designs and were able to actually switch to a different chip provider. They don't use a lot of different chips for most of these things. More centralized and integrated is the modern design for cars.

Legacy ICE vehicle design is essentially stuck at where they were ten years ago. Most manufacturers are in the process of ramping down R&D around this topic. They'll milk their production lines for a while but attention has already shifted to EVs for most of them. New models (if any) are essentially the same components they've been shipping for a while with minor changes.

Good summary! I think the core of what you talk about is a fundamental difference between a 21st and 20th century OEM. 20th century OEMs see software as a not only a hassle, but something that is isolated in discrete components and thus able to be “vendorized”. 21st century OEMs understand that the entire car is a software system, and they should be incredibly closely involved with every aspect of it.

There is room still for company’s that only can transition halfway though. It’s not like vendors cant make their discrete components OTA capable. Vendors will also be just as capable of pivoting to new silicon in the case of supply disruptions. Ford, Daimler, and the other usual suspects, are going to be more involved with their software, but they will still have vendors.

Tesla can get away with a lot of this creative homebrew craziness because they have such an insane software / hardware budget. I honestly don’t know what that company’s software practices would look like if they didn’t have such amazing access to cash