You only have to develop those interfaces once for high end cars and get your money there. Rest is then just one of the small modifications.

Not at all, a high end car will use an entirely different architecture to a mid/low end...

When you target a certain feature set it can make sense to use one big central processor, for lower end things it's more sensible to use limited smart sensors (from multiple vendors, for absolute cost minimums).

And it's generally not cost effective to move an old high trim platform down range due to changes in hardware and regulations.

What you mean by different architecture here? I've never seen a situation where manufacturers choose fundamentally different architectures between price points on the same platform. I feel like I'm misunderstanding what you mean though.

Someone like Ford for example will have several software platforms, some for low cost vehicles, some high, some that are adaptable between trim levels.

So as you go up in features on some model "the BigTruk" you might be going through variations of one sw platform, or jumping between platforms.

Some have several platforms for high and low cost based on centralised vs distributed, so for example an s class will not have much software or hardware shared with an a class.

Yes, different platforms have different architectures. Within a platform, the system level architecture will be relatively fixed. OEMs will part subsystems out to different tier 1s for different vehicles on that platform, but that's (ideally) just plugging different boxes together on the OEM side.

There's a lot of very expensive development tools (e.g. dSpace simulators) that rely on this model of automotive development.

Apple doesn't have different software platforms for low vs high cost phones. Why is a car different? It doesn't even have as much functionality.

Because a low and high cost phone do essentially the same thing, whereas a high trim car will do things like steering assistance in a way the low trim does not do at all.

And to support the differences high trim will have different sensors and differently distributed compute.

This means that the infotainment system will be running in different places on different cars.

I think it's fair to say that the software in a modern car contains lot more functionality than an average smartphone. Drivers just aren't aware of how much is happening in their car each second.

I mean there is just no way that that can be true.

To someone that knows nothing about car SW architecture, that is surprising to me, I would have expected a number of control loops for things like fuel injection, ABS brake control, drive-by-wire, EV battery charge and discharge, etc. each running on their own processor due real-time safety considerations. These I would expect to be different implementations and parameterizations of the same control theory maths.

On top of this comes some functionality to control windshield wipers, lighting, AC, seat heating, etc. Stuff which is probably not top-tier safety critical, but still important. I would expect that stuff to run on one, maybe two processors.

Then comes the infotainment system, running on its own processor.

Sensors are supplying data to all processors through some kind of modernized CAN bus and some sort of publisher/subscriber protocol. Maybe some safety critical sensors have dedicated wiring to the relevant processor.

A lot of variations on this seems possible with the same SW platform, tuned and parameterized properly. The real-time safety critical stuff would need care, but is doable.

Am I completely off the mark? Can you give some examples of where I am going wrong?

I am also not deeply into this stuff. But there is more going on in a car than what you list.

One probably surprising thing is that an LCD dashboard is usually driven by multiple rendering stacks. One is for the complex graphics and eye candy. The other one is responsible for brake and engine warning lights etc. and is considered safety critical. The second one is very basic and often partitioned off by a hypervisor.

A lot of these controllers are running more than just control loops. They are also actively monitoring their system for failures. The number of possible failure conditions and responses is quite large. I had instances where e.g. the engine warning light came on because the ECU detected that the brake light switch was faulty. In another instance, I had powered steering turn itself off during a drive because it had developed a fault. These kinds of behaviors are the results of dedicated algorithms that are watching just about every component of safety critical systems that can possibly be monitored.

All of these software systems are provided by different vendors who develop the aplication software based on either their own stack or operating systems and middleware provided by other upstream suppliers. It don't think it's uncommon for a car to contain multiple copies of 3 or 4 different RTOS stacks. Nobody at the car manufacturers is enforcing uniformity in the software stacks that the suppliers deliver. The manufacturers tend to want finished, self-contained hardware units that they can plug in, configure and turn on.

> customers simply don't believe good interfaces are worth the money

I guess I'm in the minority, then, but as a data point: I own a VW ID.4 and I'd pay significantly more to get software that isn't such a burning dumpster tire fire.

And no, the excuses provided in this thread don't cut it.

To be clear: it doesn't even annoy me anymore that the infotainment is slow and crappy, I've gotten used to it and I just never use it. But I when I want to close both windows and I press two buttons simultaneously, I would like both windows to go up, not one up and one down, as it sometimes happens.

The crappiness of the software in this car is mind-boggling and it cannot be excused: most of it is incompetent and sloppy programming.

I would pay more for a car where the software department is somewhat competent and knows what they're doing.

> I would pay more for a car where the software department is somewhat competent and knows what they're doing.

I have a Tesla Model Y and I was thinking of downsizing to an ID.4 and you just scared the shit out of me.

The ID 4 is coming off a recall and sales stop because the doors would open when in motion if the handles got wet.

I can't recall any car that didn't have any 'teething problems'. Some cars I've owned had multiple recalls. Of course it doesn't look good, but often it's to fix the probability of a problem occurring: it's not that the doors instantly swing open when touched by a drop of water.

Go for a Hyundai.

There are other competitors for that segment, even the Q4e on the same platform has better UI. People still buy the ID4 because it's not enough of a deciding factor.

Hyundai/Kia make very good EVs. I am extremely happy with my new Kona. I would not say the software is amazing, but it is responsive, nice to use and has pretty much everything you need.

Amazing claim to read considering I have experience with modern Audi software on the daily and it is an utter dumpster fire.

Well, consider, you could have paid more for a different car that has better software, like a Tesla, Lucid, Rivian ... but you didn't.

I'm not blaming you, I initially thought a VW ID.4 was a cool option. It just wasn't clear to the marketplace how bad the software was, and it's easy to assume "it's fine, I don't need fancy stuff" until you live with it and see how fundamentally bad the software is. How is the market to know? If it takes a couple years to figure it out, it makes sense for the hardware company managers to just make the hardware specs at the competitive price, and software is ... just whatever needed to get it out the door.

I worked for a few years at a sub-division of Samsung, and I've thought for a while about why "hardware" companies can be so bad at "software" ... in many cases, it's just that the leadership chain doesn't know what good software is and who is good at it. Managers don't really know what a good programmer is or does. Division heads don't know what managers are good at managing software teams and projects. And so on.

So at some point 2 years after the car is released, the CTO drives it and realizes that the software systems are fundamentally crap and can't be fixed, and it was not close or in-progress or anything, but he should have realized it 3+ years ago if he had good software sense, long before the car was released. And that's what happened with the VW ID.4

This is, incidentally, why it's so important to have a free market in software separate from hardware, despite what Apple may think. You can't have a free market competing on every possible feature; some features are going to be dominant. So people will choose cars based on size, aesthetics, price and brand .. but not on the quality of the software, which is very hard for them to evaluate even on a test drive.

> you could have paid more for a different car that has better software, like a Tesla, Lucid, Rivian ... but you didn't

At the time, I did not pay much attention to the software, because I never expected it could be so bad. Now I know better, and my next choice will consider software as one of the main factors (I don't be buying a swasticar anytime soon, though).

I have a VAG ICE vehicle and had a problem with the navigation system not working. When I brought it in to get it fixed, they apparently put a completely new version of the software on the hardware.

Suddenly everything was fast. No slow lags anymore. System is ready even before I start the engine. Navigation now zooms smoothly. Voice recognition is finally working 95% of the time and only tripping up on hard words.

I don't know how many different software versions are out there but apparently they are working on system speed without changing the hardware. Maybe I got an early access version and they are waiting for data before they push it to all vehicles.

If VW and all other product manufacturers of products containing universal machines as components were forced to charge customers a 100% sales tax on all such end-of-chain products, UNLESS all (and I do mean all, down to the controller on the SSD or the battery controller or whatever) universal machines in the product complied with the following:

A) If there is stored code for a specific universal machine in question and the storage is re-writeable, and

B) there is a control mechanism in place to integrity check the stored code before execution, and

C) the integrity check mechanism relies on a cryptographic secret, or any mechanism which prevents the owner from changing the code but permits the OEM to, then

D) the specific universal machine's key store MUST permit full wiping of all keys in a way where no keys are stored anywhere (no permanent manufacturer keys), and the key store MUST permit the owner to store his own root keys; additionally, in the interest of national security and the average citizen's digital sovereignty,

E) replacement software/firmware for universal machines should be encouraged rather than stifled, so additionally there must also be technical specifications detailing enough of the hardware's architecture and the overall design of the part or product (the logic in making design decisions to accomplish product functions), to permit a skilled owner to write his own firmware and achieve similar functionality as shipped.

Basically, think Louis Rossmann gets together with Richard Stallman, and they form a beautiful baby governmental regulatory body to come up with "Apple Laws" (sic: Lemon Laws) to answer and address the Apple Question.

Abandoned proprietary code on abandoned proprietary hardware is a national security concern much greater than the minute problems caused by the occasional tinkering script kiddie. It will mean the end of the easy money of putting everyone on subscription, and would encourage more evergreen platform/API design to reduce developer-driven code churn. If companies want to make cheap proprietary throw away product which will house malware in a decade when the company has long abandoned patching holes in it, and design it so no owner has a practical chance or hope of fixing the vulnerability, then companies can suffer a price-doubling tax that'll go to pay for their open source competitors to more easily compete!

Sorry, not sorry. Get expertise producing material things people need, if what I outlined above would mean the high paid software gravy train ends lol.