🚗 Exciting Update: Automotive OS Comparison Now Interactive and Packed with Q3/2025 Insights! 🚀
Fellow automotive innovators, we’ve leveled up our overview of vehicle operating systems! The new version transforms it into a dynamic, customizable comparison tool tailored for your automotive projects.
🔍 What’s New in This Update?
✅ Interactive Comparison Table: Dive deep into top OS like BlackBerry QNX, Google Android Automotive, Toyota Arene OS, and more – now with easy show/hide columns for a personalized view.
✅ Expanded Details: New columns covering scope (e.g., infotainment, ADAS), supported chip cores (ARM, x86, RISC-V), key features (hypervisor support, ASIL D safety), middleware (SOME/IP, DDS, MQTT), connectivity (Bluetooth, Ethernet, CAN), and fresh 2025 release info.
✅ Enhanced Usability: Tooltips for vendor details, “Show All/Hide All” buttons, and hover effects to streamline your evaluation.
✅ Updated Data: Sourced from official vendor docs and industry reports as of September 17, 2025 – ensuring reliable Q3/2025 insights!
This upgrade empowers engineers, developers, and OEM teams to make informed choices for software-defined vehicles faster than ever. Spot any gaps or updates? Email info@viable.works – your input keeps it cutting-edge!
Explore the revamped guide: https://viable.works/content/automotive_os_comparison/index.html
#AutomotiveTech #OperatingSystems #EmbeddedSystems #ADAS #AutonomousDriving #SoftwareDefinedVehicles #AutoInnovation
Tag: Functional Safety
-

Update: Automotive OS Comparison
-

Understanding Zonal Architecture in Modern Vehicles
Zonal architecture is revolutionizing how modern cars are built, replacing messy wiring with smart, organized systems. But ask ten engineers what it means, and you’ll get ten different answers. Let’s clear up the confusion and explore why this design is the future of vehicles!
How it began?

Vehicle wheel with integrated Electric Motor, Brake and ECU The first ideas of the zone concept were pitched by Siemens, when they worked on their project e-Corner – A modular vehicle dynamics concept that integrated a separate motor, brake and ECU into each wheel.
This project highlights the massive advantages of the zonal concept:
- The vehicle body is freed up from technology and components.
- Less material usage due to the application of torque, where it is needed.
- Better maneuverability due to the mechanical decoupling of the car.
Why did it fail?
But if this concept is so beneficial, why don’t we see it now in all modern vehicles?
The simple answer to that: It is difficult to make it safe. A mechanical form-fitting connection of the wheels cannot be hacked and doesn’t change its behavior due the loss of electric power. But with this concept, all of that can happen.
When each ECU acts individually, the vehicle motion can get out of sync and endanger the vehicle. Therefore, domain ECUs for the engine, the braking- and steering-systems will survive even in the most modern vehicle architectures.
Why is that important for Zonal Architectures?
The Siemens e-Corner case exploits the limitations of a zonal architecture. A full zonal-architecture doesn’t have a good price-value-ratio. Therefore, it is not done and we will even in the midterm future have dedicated domain controllers that are not integrated into the zones.
Another decisive factor is the cost for bandwidth. While the body, chassis and powertrain domain only slowly demand more bandwidth, ADAS and Automated Driving on the one hand and In-Vehicle-Infotainment including all connected services on the other hand continuously demand more bandwidth.
Putting those domain functions together in a zonal concept with the other domains would make these domains more expensive, because they have to switch from LIN, CAN and CAN-FD to 10BASE-T1S Automotive Ethernet or even higher Automotive Ethernet speeds.
How will the E/E-Architecture finally look like?

E/E-Architectural schema for a hybrid Zone- and Domain-Concept The picture above shows a schema of a hybrid zonal-domain-architecture that mainly decomposes the body functions into a left a right and a rear zone.
It makes sense to bundle these functions regionally instead of domain related for the subsequent reasons:
- The body functions have homogeneous low bandwidth demands. Edge wiring can be done via LIN, CAN or analog.
- The safety compliance level (Functional Safety) is low (ASIL A or B).
- The synchronization requirements are relatively low, too. If e.g. one door locks 100 ms later than the other, it is no problem.
Using this architectural approach will keep ADAS and IVI in their original domains including all wiring harness for sensors, redundancy and power supply.
Scalability is given by the removal of the rear zone for class A(++) cars. If the Software-Defined-Vehicle (SDV) approach is implemented well, some of the rear-zone-functions like rear-seat-heating can be made accessible via the side zones. Others, like the electric trunk lid lift will not be available at all.
This approach we already see implemented by some US and Chinese OEMs. From our point of view, this architecture will get the industry standard for the next 5 to 10 years.
For more information about how to implement zonal architectures, contact us here.
-

Is “code first” a viable approach for safety critical automotive software?
VW, Mercedes, BMW and some important European top suppliers form a new software alliance to create automotive software.
They announced that they will work with the “code first” principle to create quick results and overcome the slow old economy innovation pace. But of course, they also want to certify the software according to ISO 26262 (Functional Safety).
Writing code first means to create the requirements and the architectural design later. Doing this later leads to reverse engineering of requirements and architectural designs with assumptions about the context. Usually this way of software creation finally leads to a comprehensive code enhancement after the requirements are created. It’s like building a house first and later thinking about a sustainable foundation.
But anyway the approach has some added value. Huge software projects with multiple partners intend to do endless requirements discussions without finally creating anything else than paper. That’s no solution either.
Surprisingly ISO 26262, the functional safety standard for automotive provides a viable solution to solve this dilemma: Out of context development.
Therefore, ISO 26262 provides the approach of Safety Elements out of Context (SEooC). With the help of this approach a small design team can independently work on specific capabilities that can be later used in multiple contexts, not completely out of context.
The ISO requires so-called assumptions of use to mark the boundaries of the intended usage and not intended misuse.
This requirement can be fulfilled with Bertrand Meyer’s Design by Contract approach.
Here are my 5 cents to make rapid software development for safety and security critical software viable based on Bertrand Meyer’s software development principles.
- Use Design by Contract: Embed preconditions, postconditions, and invariants to ensure correctness and catch errors early.
- Formal Specs First: Define formal specifications for critical components before coding to align with safety standards like ISO 26262.
- Seamless Verification: Integrate design, coding, and verification with static analysis and automated testing for continuous error detection.
- Modular Design: Build reusable, object-oriented components with clear interfaces for maintainability and scalability.
- Strict Open-Source Governance: Enforce coding standards, contract compliance, and peer reviews to maintain quality in collaborative development.
