Why?

When I tell acquaintances that I work for a software company that produces its own operating system, I often get questioning looks. "Why an extra operating system?” they ask. “Can't you do that with Windows, Linux or Android?"
The answer is: yes, you can in theory. But it then becomes risky. I then always ask back the following: "Would you give your cell phone, laptop or Raspberry Pi maker kit control of your car - if you were speeding down the A31 highway at 220 km/h?" (For readers not living in Germany: Please replace 220 with 110-140).
In a car at 220 km/h, the vehicle covers a distance of 6 metres in one tenth of a second. So, I need reaction times for the braking function that are well below that - always, and in every moment!
And this is precisely where it gets tricky. Of course, operating systems like Windows, Linux and Android can be used to implement scalable cloud services, mobile apps and great games, but their response time is not really specified… it could be short sometimes; but sometimes not so short.
The same is true for special variants of Windows or Linux that have been slimmed down, especially for embedded applications. Those variants have quite acceptable response times. 
And then my software-savvy acquaintances ask me: "What about one of open-source OSes?" Sure, open-source OSes are also used in cars, and of course the gigantic open-source developer community has set standards in terms of functionality and software updates. But that only gets along with certain concessions and copy-left licenses are just one of them.

Functional Safety

No automotive developer will ever give such an operating system control over the brakes - the car radio and navigation system, yes, no problem - but neither the brakes nor engine control. Such safety-related functions are developed on the basis of a so-called ‘real-time operating system’ (RTOS). And real-time here does not mean super-fast, but super-deterministic whereby the manufacturer of the operating system guarantees a maximum response time. Furthermore, there's a very strong separation of kernel and user functions, which protects the kernel when user code crashes. This is quite different from the monolithic Linux architecture, which makes it easier to implement functions with high throughput (another OS performance parameter) - but which is therefore also not as stable as an RTOS.
And this is also checked by external testing institutions such as the SGS-TÜVｓ. Physical end tests along with the entire RTOS architecture, and the development process, are all checked thoroughly for all known and potential error sources. 
This is not possible with gigantic and "monolithic" OSes like Window, Linux and Android. Even for the slimmed down embedded versions, there is no certified development process that could be checked by a certified external institute. There have been attempts to certify embedded Linux variants in the past. But the development process restrictions would turn such a variant into exactly such a product as they are currently offered on the market as COTS.

New technologies

Back to our main topic. We are now entering the age of EVs. EVs are currently much more expensive to produce than cars with internal combustion engines due to the expensive battery (and because economies of scale have not been reached as yet). So, to get the overall costs back under control, outdated system approaches need to be changed to modern cost-optimized processes.

For example, braking systems are currently being developed that use small electric actuators to press the brake calipers onto the brake discs. This has several advantages:

• Less production and maintenance cost (no hydraulic liquids)
• More braking power
• Faster reaction
• Better brake blocking reduction
• Better synchronization with the EV energy recuperation system
• Simpler spin suppression because every wheel got a totally independent actuator

Interesting side story: there was a concept by former Siemens VDO company of an "electronic wedge-brake" in 2006. In those days nobody in the automotive industry thought about disruption by EVs (nobody but Elon Musk, that is). And that project was paused. It might be a good time to restart it again.

Real-time OS

To develop and manufacture such brake-by-wire systems safely, you need a safety-tested RTOS.  And such RTOSes are produced by our software company. Since different applications in the industry have different requirements (more performance or more safety, lower costs), eSOL offers different RTOSes based on the proven eT-Kernel and the new eMCOS platform.
With these RTOSes, today’s automotive applications like engine control units, ABS, EPS and ESP are successfully developed - up to a functional safety level ASIL-D (which is the highest safety level in the automotive industry).

End of the story

By large, this is what I answer when my acquaintances ask me: "Why an extra operating system, can't you do it with Windows, Linux or Android?" I could tell them a similar story about steer-by-wire with the same result: After my answer, they usually think differently about their cell phones, laptops and the difference between a coffee machine… and driving at a high speed on the highway.

References:
https://thebrakereport.com/smart-brake-by-hitachi-astemo-what-is-it-and-whos-it-for/
https://www.brembo.com/en/company/news/brembo-unveils-sensify

M.G.