I just found this presentation with technical details:
https://group.mercedes-benz.com/dokumente/investoren/praesen...I guess it is not a typical OS, but more like a collection of tools that build on already existing OSs. This is comparable to ROS (Robotic Operating System), which are just some programs, middleware, services and conventions to build software for robots on Linux.
It seems like this should integrate and abstract different "OS" (Linux, QNX, AUTOSAR) and run on very different platforms (high power application processor for infotaiment, microcontrollers) (Slide 13). These are widely different systems:
1. Linux needs a Memory Managing Unit (MMU), which only comes with high(ish) powered application processors, e.g. Arm Cortex-A9. These are obviously not hard-realtime because a page fault can occur non-deterministically (except when you can lock everything to RAM). This might be used for infotaiment.
2. (Classic) AUTOSAR is used without a operating system on a microcontroller like the ARM Cortex-M or a automotive MCU like the Infinion TriCore, which can run two cores in lockstep to verify each computation. AUTOSAR is kind of the operating system and you buy an "adaption"/HAL of AUTOSAR to the each MCU from a vendor. This is widely used in many ECUs for hard real-time control, e.g. to control something in the engine, and other stuff like the electric windows. AUTOSAR is a huge pain in the ass to develop for. You usually configure "it", which takes a lot of time. Then a software generates a huge amount of code. The software is from another vendor, e.g. Vector or Elektrobit. The developer fills out the function stubs implementing the actual function. Alternatively, you can generate the code from MATLAB/SIMULINK models with a code generator from yet another vendor (model-based-development). The upside of this, that the HAL and code generators are certified and everything is somehow standardized. The downside is that normal developers want to kill themself, you learn no transferable skills, and the huge amount of generated boilerplate code, that is hard to read.
3. There is also a newer Adaptive AUTOSAR, which can run on Linux or QNX.
I guess (page 8) they want to use it for infotaiment (point 1), interior control (lights, climate control; probably point 2), automated driving and "central driving" (point 1, point 2). I am not sure if this includes typical fast hard-real-time tasks like engine control or chassis control (=vehicle dynamics control).
I am not sure if really want to abstract it all or just extend the "OS" (Linux, QNX, AUTOSAR) with libraries and components, mostly in user space.
If you look at slide 13, you might guess that they will adapt Linux and QNX to run their UI MBUX (in QT). They extend it with services that communicate with ECUs in the car and their servies in the internet. Moreover, they allow to install sandboxed apps from Mercedes, Android Auto (e.g. Spotify) on top of it. They also come with an app store: https://faurecia-aptoide.com/
The real-time ECUs in the car running AUTOSAR will just get additional components to easily communicate with other MB.OS parts and support some newer features like OTA update.
I have not seen any details how this relates to ADAS functions. These are typically (partially) run on a compute node made by an automotive supplier with a hardware accelerator from NVIDIA, e.g. ZF ProAI (https://www.zf.com/products/en/cars/products_64166.html) or from Valeo (https://www.valeo.com/en/domain-controller/).