In a way, I agree. If you can verify the entire system throughout, you can remove certain runtime checks, such as the separation between the OS and tasks. If you have only one program to run, you can use a unikernel.

I suspect that specifically car / aircraft / spacecraft computers receive regular updates, and these updates change the smallest part they can. So they have separate programs / services running on top of a more general OS. The principles of defense in depth requires that each component should be hardened separately, to minimize the blast radius if a bug slips in.

> I suspect that specifically car / aircraft / spacecraft computers receive regular updates, and these updates change the smallest part they can.

In the space I am very familiar with, automotive, this is not true for code changes to most automotive control units; the "application software" code for each control unit is treated as a single entity and built, supplied, and modified at this level of granularity. Infotainment and digital cockpit is the only major exception, but even then, only for the "unsafe" part (Linux/QNX/Windows); the "safe" part is usually a single-image single-application running on a safety processor alongside.

Sometimes personalization/vehicle-specific "data sets" or calibration _data_ (ie ECU tunes) can be updated without updating the application software, but the application software for each unit is generally treated as a large unified firmware blob. For example in every ECU I am aware of, modifying the application software logic (which is usually modeled in something like like Simulink/ASCET, not code directly) triggers a full code regeneration, recompilation, and generates a complete new firmware image with an updated Application Software version. There isn't any notion of shipping a new "turbocharger control" code module, or a new "diagnostics" code module, or whatever, even if they are constructed at this granularity in the code generation suite or run at this task granularity in the RTOS.