Cant agree to the points. It all depends on use case. In some cases it is even beneficial to remove the OS itself. I am not talking about high lveel OS like Linux, QNX or VXWorks, even MicroC OS II is a big overhead for some systems.
Consider how your car decides to deploy the airbags. Do you want a message queue? No, as soon as hardware inputs meets the condition the airbags needs to be deployed. On the other hand on the same car will have a infotainment system that has VxWorks/QNX/WinCE with multi process architecture. Most of them even have separate processor to interface vehicle CAN bus and power management. Inside the application processor, graphics and HIM will be distributed in some processes. The low level drivers codecs in another set of processes. The whole thing will just give the user a mediaplayer, a map and a phone interface.
Some OEMs (e.g. Daimler, Ford) even distribute this whole functionality across different H/W modules.
Dividing gives you maintainability, re-usability, drop-in replacement alternatives. Most of the cases it shortens the engineering time, improves quality and reduces product recall.
The above automotive embedded example is just one use case. There are many areas where you want to distribute your application in many ways.
Finally, I want to ask one small question, when you turn off the reading light in a passenger aircraft, how many processes do you want it (Switch OFF signal) to go through before the light turns off? and why so?
Consider how your car decides to deploy the airbags. Do you want a message queue? No, as soon as hardware inputs meets the condition the airbags needs to be deployed. On the other hand on the same car will have a infotainment system that has VxWorks/QNX/WinCE with multi process architecture. Most of them even have separate processor to interface vehicle CAN bus and power management. Inside the application processor, graphics and HIM will be distributed in some processes. The low level drivers codecs in another set of processes. The whole thing will just give the user a mediaplayer, a map and a phone interface. Some OEMs (e.g. Daimler, Ford) even distribute this whole functionality across different H/W modules.
Dividing gives you maintainability, re-usability, drop-in replacement alternatives. Most of the cases it shortens the engineering time, improves quality and reduces product recall.
The above automotive embedded example is just one use case. There are many areas where you want to distribute your application in many ways.
Finally, I want to ask one small question, when you turn off the reading light in a passenger aircraft, how many processes do you want it (Switch OFF signal) to go through before the light turns off? and why so?