Category: Engineering

  • 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.