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.
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.
