[chadlavi]

Cars already have an operating system. It's a dash with dials you can look at to get info, a wheel you can use to steer, a set of pedals to control motion, a set of switches and buttons to control lights and such, and a center console with physical buttons that control extras like radio and heat/cooling. Not everything needs to be a computer!

[analog31]

I do some embedded systems work, albeit using it as a research tool and not directly involved in product development. Whether or not to have an OS is a perennial debate for projects that fall in between Little and Big. I turn to an OS when I expect to benefit from pre-written tools, such as file systems and higher level networking functions. I also expect portability of software from one hardware configuration to another.

For things that need to run in real time, or with super high reliability, but are relatively simplistic, goodbye OS. There's also a method where a computer with an OS is connected to multiple satellite computers that run simpler code. Turning a car into a network of tiny computers could reduce the sheer amount of wiring needed.

As mentioned elsewhere, using a mainstream OS taps into the skill set of people who know how and want to program against it. Also, the OS serving as a "layer" between applications and hardware lets you change hardware without having to rewrite all of your software.

There's a trend in every industry right now to turn everything into a computer. I can imagine the marketing meeting: "We need to get people to stop thinking about a car as a car. A car is software."

[AlotOfReading]

A modern car is a network of tiny computers, at least dozens, sometimes up to 100+. You can stretch that number significantly if you want to count every IC with an embedded microprocessor in it.

All of that diversity will be managed by a relatively small number of people at any OEM. Standardization to a minimal set of OSes and hardware platforms is the only way to make the workload manageable and keep the dozens of application teams unblocked.

[the__alchemist]

For embedded C, RTOS by default is common. Not because applications need non-cooperative scheduling by default, but to manage memory-safe concurrency, and other abstractions. With rust, you can get away with simpler scheduling/locking mechanism and skip the RTOS until complexity reaches a threshold, or you have non-cooperative tasks.

[RamblingCTO]

Cars already are quite heavy computers and have been for ages. It's not like a new development. They have control units, component control units, the radio, bla bla bla. Lot's of integrated stuff.

[chadlavi]

Of course. But driving a car doesn't need a user-facing OS. It shouldn't feel like using a computer to drive a car. Am I misunderstanding the car operating system they were working on? I thought it was to facilitate UI on touchscreen controls not just low-level systems.

[b112]

The only user facing OS, should be a touch screen you can use with your phone, and use with steering wheel buttons.

Everything else is sensless. Just get out of the way, let us use our phones or tablets.

[konschubert]

Exactly. There is a user-facing “infotainment” system including comfort functions and there is the safety-critical real-time embedded stuff.

Volkswagen made the mistake of coupling these two.

[jeffrallen]

Cars are networks of small, light, robust, old computers made by lots of different suppliers who are not "car companies".

[Zigurd]

Cars have a number of processors, mostly running RTOSs, mostly controlling subsystems, like window motors, seats, etc. It's this way because these subsystems come from different suppliers. A lot of them do not need high stakes security hardening or hard real time capability. These will increasingly get integrated into software modules that can run in an evolved main "infotainment" system.

[slt2021]

small car components are just MCUs, bigger units like ECU are large SoCs with full fledged RTOS like Integrity RTOS (which can be found on everything from cars to F-22 Raptor jet)