[typewithrhythm]

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.

[AlotOfReading]

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.

[typewithrhythm]

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.

[Sevii]

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.

[gmueckl]

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.

[KSteffensen]

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?

[gmueckl]

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.

[omcnoe]

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

[typewithrhythm]

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.

[AlotOfReading]

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.