Recent developments in the semiconductor sector highlight how quickly regulatory and geopolitical factors can reshape global supply chains — even for leading-edge technologies.
According to a Financial Times report (via Yahoo Finance, March 5, 2026), NVIDIA has ceased production of H200 AI chips specifically allocated for the Chinese market. The company has redirected manufacturing capacity at TSMC toward its next-generation Vera Rubin platform. This follows months of uncertainty: U.S. export licenses were granted earlier this year (with conditions including a 25% fee), yet no meaningful shipments have occurred, and Beijing has not approved large-scale imports.
As a result, NVIDIA has generated zero data center revenue from China in recent quarters and has excluded any such contribution from its forward guidance.
While this concerns AI accelerators rather than automotive components, the parallel is clear for the automotive industry:
Advanced semiconductors (for ADAS, autonomous systems, infotainment, or electrification), software platforms, and even standard electronic modules increasingly depend on global, geopolitically exposed supply networks.Export controls, import approvals, local content rules, or sudden policy shifts can delay, restrict, or eliminate access to critical technologies — regardless of whether they are high-end or commodity-level.
Please take a look at our Automotive HPC Comparison. You can see there that in the case of HPCs the market is quite narrow and the solutions are all proprietary and cannot be replaced against each other.
For OEMs and suppliers, this underscores the value of integrating realistic supply chain scenario planning early in concept and business case development. Assumptions about:
availability
lead times
market access
need to be tested against a range of regulatory and geopolitical outcomes to build more resilient technology roadmaps.
Curious to hear perspectives from the automotive community: How are you factoring multi-jurisdictional risks into your long-term tech sourcing strategies?
How suppliers can win without picking the wrong horse.
Volkswagen Group will use XPENG’s technology for its next-generation China vehicles.
That’s not just a sourcing decision. It means VW is now running three parallel architectures for its future models: MEB+, Rivian’s RVTech, and XPeng’s CEA platform.
For suppliers, this creates a familiar but uncomfortable situation. If you align your product development with the wrong architecture, you risk losing access to high-volume programs. If you try to serve all three separately, your R&D costs multiply.
The winning approach is different. 👉 ZF Group demonstrated it when they sold their #ADAS division and doubled down on what they do best: brake-by-wire, steer-by-wire, integrated chassis control. Those components work identically whether they’re bolted into a NIO, a VW on MEB+, or a future Rivian-powered Audi.
We explored this strategy in a new analysis. It covers: 👉 Which deep-tech components travel across all architectures 👉 How to validate your product against multiple platforms simultaneously 👉 Why “platform-agnostic” is not a compromise but a competitive advantage
The full piece is here for anyone navigating VW’s multi-platform reality: https://viable works/sdv/vws_three_architecture_gamble
🚀 Automotive Operating System Comparison updated to version Q1/2026 🚀
Key enhancements from version Q3/2025:
✅ Detailed #OTA comparison ✅ Breakdown of Base OS in #FuSa, #HPC and #UI ✅ More conservative rating, if or if not a feature is fulfilled ✅ Change from Grok to DeepSeek AI as main #LLM for better accessibility of 🇨🇳 pages ✅ Added #Eclipse S-Core, Veecle-OS, #SafeRTOS and #RedHat #IVOS.
Ten years after unveiling the groundbreaking CHAD prototype at CES 2016, the dream of fully autonomous driving feels closer than ever – yet a fundamental conflict persists: systems must still choose between natural, human-like driving behavior and verifiable safety without self-caused accidents. In this new article, Benedikt Schonlau reflects on a decade of progress and reveals the three foundational enablers that will finally cut this Gordian knot:
Functionally safe by-wire chassis
Targeted V2X infrastructure at critical points
Reliable connectivity with selective remote support
Discover why these elements are essential to deliver comfortable, confident autonomy that earns real-world trust – without compromise. Read the full article: Towards Truly Viable Autonomy
🚗 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
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.
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.
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
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.
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.
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.
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.
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.
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:
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.
