Category: Engineering

  • Update: Automotive OS Comparison

    Update: Automotive OS Comparison

    🚗 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

  • Understanding Zonal Architecture in Modern Vehicles

    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.

  • Automotive Operating System Comparison

    Since the hype to Software-Defined-Vehicles started, there’s also a lot of movement in the Automotive OS market. Many OEMs see an in-house OS as a key for further innovation.

    Automotive Operating Systems Comparison

    Please have a look at the first version of our Vehicle OS map.

    Unfortunately, some information parts are still guessed. As soon as more accurate information is available, the page will be updated.

    Anything wrong or missing? Please comment here: viable.works Automotive OS Comparison @ LinkedIn.

    Update: An up-to-date version of the Vehicle OS Comparison with interactive elements can be found here: Automotive OS Comparison.

  • Lessons from the Tesla Key Largo Verdict: What Non-US Vehicle OEMs Need to Know About Product Liability

    Lessons from the Tesla Key Largo Verdict: What Non-US Vehicle OEMs Need to Know About Product Liability

    In a landmark ruling on August 1, 2025, a federal jury in Miami held Tesla 33% liable for a fatal 2019 crash in Key Largo, Florida, involving its Autopilot system.

    The crash occurred when driver George McGee, distracted while using Autopilot, collided with a parked SUV, killing 22-year-old Naibel Benavides Leon and injuring her boyfriend, Dillon Angulo.

    The jury awarded $329 million in damages, including $200 million in punitive damages, citing flaws in Autopilot’s design and inadequate warnings for foreseeable misuse.

    Tesla plans to appeal, but the verdict underscores the risks of autonomous driving technology and sets a precedent for liability in the U.S. market.

    Five Key Learnings and Takeaways for Non-US Vehicle OEMs

    1. Understand U.S. Strict Liability Standards: The U.S. applies strict liability for defective products, meaning manufacturers can be held accountable for injuries caused by design flaws or inadequate warnings, even without negligence. Non-US OEMs must ensure autonomous systems are robustly designed to handle normal and foreseeable misuse scenarios, like driver distraction, to avoid liability.
    2. Anticipate Foreseeable Misuse: The Tesla case highlighted that driver distraction is considered foreseeable misuse in the U.S. OEMs must design systems with safeguards—such as enhanced driver monitoring or fail-safes for unexpected road conditions—and provide clear warnings to mitigate risks from predictable human errors.
    3. Prepare for High Punitive Damages: Unlike many jurisdictions where punitive damages are rare, U.S. courts can impose substantial penalties to deter unsafe practices, as seen with Tesla’s $200 million punitive award. Non-US OEMs should prioritize safety in design and marketing to avoid costly penalties in the U.S. market.
    4. Navigate State-by-State Variations: U.S. product liability laws vary by state, leading to inconsistent outcomes. The Tesla verdict in Florida may influence other jurisdictions, but OEMs must tailor compliance strategies to account for regional differences, consulting local legal experts to ensure robust defense strategies.
    5. Strengthen Post-Sale Monitoring and Communication: U.S. courts expect manufacturers to monitor products post-sale and issue warnings or recalls if defects emerge. Non-US OEMs should establish proactive monitoring systems and clear communication channels to address potential issues with autonomous technologies swiftly.

    Conclusion

    The Tesla Key Largo verdict serves as a wake-up call for non-US vehicle OEMs entering or operating in the U.S. market. By prioritizing robust system design, anticipating driver misuse, and understanding the U.S.’s unique liability landscape, manufacturers can mitigate risks and avoid costly litigation. As autonomous driving technology evolves, proactive safety measures and clear user guidance will be critical to navigating the complex U.S. legal environment successfully.

  • Making of the viable.works webpage with Grok and Copilot

    We recently launched our new webpage only consisting of plain HTML, CSS and images. The creation was mainly done by Grok and Copilot.

    Screenshot of the new viable.works webpage

    Plain HTML & CSS

    We decided to create the page with plain HTML and CSS and waived the usage of a Content Management System (CMS).

    While a CMS still has many advantages for dynamic content like a blog (this one uses WordPress) a static company web page is much simpler and an ideal candidate to test the capabilities of Conversational AIs.

    Step #1: Corporate Identity (CI)

    CI is a must have to be perceived as a professional company. The main CI topics to get started are corporate colors.

    We asked Grok to provide a color schema for an automotive, mobility and tech related consulting company with a black background, a blueish main color and signaling traffic light 🚦 colors.

    The proposals needed some adjustments regarding the contrast ratio, but finally we got a result.

    viable.works color schema

    To simplify our design work, we also used the color schema for the logo. But unfortunately, Grok did not perform in the logo generation no matter what we prompted. So we finally decided to craft it manually.

    Step #2: HTML structure and CSS

    Creating basic structures that are fully operational is the parade discipline of Grok. Asking him to provide a basic HTML and CSS structure for a one page company web presence, he provided the structure that you can see in the final page consisting of the following elements:

    • The basic HTML page structure
    • The linked CSS file considering the CI including
    • A JavaScript for the animation site navigation with a mouse over drop down

    Using the created structure, we created the first version of the page content on our own.

    Step #3: Images

    We asked Grok to provide images that underline the key areas of competence. Grok also prepared some placeholder links to add the images. Here’s the requesting prompt:

    Can you create the icons for me you proposed to insert. Here's the color schema of the company:
    Dark: #333333
    Grey: #CCCCCC
    Lila: #6600CC
    Red: #FF0033
    Green: #00CC33
    Yellow: #FFCC00

    The result was really disappointing. Grok said that he’s not capable of creating images (that’s not true) and provided SVG source code instead that we could potentially embed. Here’s one example:

    <!-- Save as automated_driving_icon.svg -->
    <svg width="50" height="50" viewBox="0 0 50 50" fill="none" xmlns="http://www.w3.org/2000/svg" aria-hidden="true">
        <!-- Car body -->
        <rect x="10" y="20" width="30" height="15" rx="3" fill="#CCCCCC" stroke="#333333" stroke-width="2"/>
        <!-- Wheels -->
        <circle cx="15" cy="35" r="3" fill="#333333"/>
        <circle cx="35" cy="35" r="3" fill="#333333"/>
        <!-- Radar arc -->
        <path d="M40 15 C45 15 45 10 40 10" stroke="#6600CC" stroke-width="3" stroke-linecap="round"/>
        <path d="M40 18 C48 18 48 10 40 10" stroke="#6600CC" stroke-width="3" stroke-linecap="round" opacity="0.5"/>
    </svg>

    The picture shows a car body as a simple rectangle and wheels with only one circle without any decorations.

    We stopped using Grok at this point for image generation and switched to CoPilot.

    Here’s the first prompt:

    Can you create an icon for me that represents automated driving.

    Here's the color Schema to be used:
    Dark: #333333
    Grey: #CCCCCC
    Lila: #6600CC
    Red: #FF0033
    Green: #00CC33
    Yellow: #FFCC00

    The background color shall be black.

    After a few seconds of waiting, we got this result:

    Automated Driving Icon generated by CoPilot

    This result was overwhelming for us. It worked the same way for all other images. The only requests we could not tech CoPilot:

    • To use the right colors. The shown colors are close but do not fit to the provided CI
    • To change the form factor of image. He acknowledges to change it but finally does not.

    Step #4: Search Engine Optimization (SEO)

    Especially for small companies, more than 99% of all potential customers get lost at the search engine because they don’t even reach the website. SEO tries to get the best fit for the search engines to get found .

    We switched to Grok again, because Grok performs much better with code than CoPilot does. Here’s the final SEO prompt:

    Please have a look at the latest version of my html page.
    Please do the following enhancements:

    Check the whole text for typographic errors and fix them

    Check all texts, if the wording is appropriate and attractive. Fix all major issues.

    Check the complete metadata and make it consistent with the page.

    Additionally, we provided the updated webpage, so that the finish could be directly done in this version.

    The following updates were done by Grok:

    • Fixing of typos and grammar mistakes
    • Wording appropriateness and attractiveness
    • Metadata Consistency

    The metadata consistency is the most impressive topic because it saves a lot of time: The keyword list was automatically updated, the page title was adjusted and social media enhancements were done.

    Also some JSON scripts were added to list the company and the services directly in the search engine.

    The following image shows some details.

    Metadata excerpt of viable.works Webpage

    Step #5: GDPR

    Every webpage must be compliant to GDPR. If the page uses cookies (what we do with Google GA4), it must ask the reader to consent and otherwise don’t store cookies. Additionally a privacy page is needed.

    We asked Grok to create the JavaScript for the customer question and the privacy HTML file

    After a few seconds, we got both. The script was successfully tested and worked well after only one shot.

    Conclusion

    The capabilities of Conversational AIs for webpage generation work with high quality and reliably support content creators with formal work.

    The results are amazing and saved a lot of time and money for the creation.

    Of course, the picture will look different for bigger projects and a webpage design house is still needed.

    But these design houses must disrupt themselves and go for massive usage of Conversational AIs, even if the revenues per project will massively drop down with this approach.

  • Is “code first” a viable approach for safety critical automotive software?

    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.
WordPress Cookie Plugin by Real Cookie Banner