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