In this view, LLMs are no longer just code generators. They become participants in a discussion about how a system should behave. Spec-driven development is thus less of a new development methodology and more of a technological extension of existing human workflows.

Successful software systems are rarely created by someone immediately typing perfect code into an editor. They emerge from communication through specifications, user stories, and shared discussions at the whiteboard. The formal implementation in code is often just the last step of a long, creative process.

Marc Brooker rightly emphasizes that success comes from iteration, context accumulation, and collaboration. What is new is that we can now use technology to let computers participate in the very same conversations humans already have when describing how a software system should behave. We position LLMs here as active conversation partners and critical reviewers, not as autonomous authors who blindly take work off our hands.

But as soon as we make natural language the primary tool for specification, we encounter a central problem: Conversations in natural language are inherently ambiguous.

The Emergence of a Ubiquitous Language

When humans discuss a problem together, ambiguous terms must be clarified to enable effective communication within the current domain. We all know this from meetings: Someone says “customer” but means “account.” Another says “order” but refers only to the “shopping cart.”

In my experience, clarification happens in an iterative process: If a term is used for the first time and interpreted differently by different conversation partners, a need arises to explicitly define its meaning for the ongoing discussion. Through this step-by-step definition of terms for a concrete problem area, a common language emerges that is used by all participants.

In Domain-Driven Design (DDD), this common language is called Ubiquitous Language. It applies within a delimited area, the so-called Bounded Context. A bounded context in DDD is a boundary within which a specific domain model and ubiquitous language apply consistently. For example, in an e-commerce system, an Order Management bounded context defines what an Order means and enforces its lifecycle rules, while Payment and Shipping use different models and terminology for the same real-world concept.

Handling the ambiguity of natural language was long reserved exclusively for humans. With the advent of LLMs and spec-driven development, machines can now participate in this clarification process by making ambiguities explicit within a given Bounded Context, asking in the Order Management context whether the term “order” refers to a customer commitment at checkout or to a payment or shipping artifact used in downstream contexts.

Collaborative Clarification as Engineering Work

This leads to a new interaction loop in software development that I consider genuine engineering work rather than administrative overhead. With tools like Kiro, work on a new feature often starts with a simple prompt that captures the initial idea and intent in natural language, which Kiro then elaborates into a specification.

From there, ambiguities surface quickly. The LLM supports the team by highlighting terms that can be interpreted in more than one way in the current bounded context, such as whether an “order” refers to a customer commitment in Order Management or to a payment or shipping concept elsewhere. The human clarifies the intent, and once that clarification is made, the terminology becomes stable. These agreed-upon terms act as anchors in all subsequent artifacts, making inconsistencies visible as soon as they appear.

Practical Application with a Custom Kiro Power

To translate this theoretical approach into practice, I developed the Spec Ambiguity Resolver a Kiro Power that helps establish and maintain a ubiquitous language throughout the entire development lifecycle.

The power is active during all phases of spec-driven development: specification writing, design document creation, task breakdown, and implementation. It works by maintaining a living glossary file (domain-terms.md) that serves as the single source of truth for the project’s ubiquitous language.

Let’s return to our Order Management example to see how this works in practice. When the team starts writing their specification and uses the term “order,” the power immediately flags this as potentially ambiguous:

“I noticed the term ‘order’ appears in the specification. To establish our ubiquitous language, we should define what ‘order’ means in this project context so all participants, including me as the coding AI, share the same understanding.

Based on the context, I propose this definition:

Order: A customer commitment created at checkout in the Order Management bounded context, including items, quantities, pricing, and delivery address. This represents the customer’s intent to purchase.

Does this definition accurately capture what ‘order’ means in your project? Would you like to adjust it before I add it to our ubiquitous language?”

This interaction is crucial: the power never autonomously creates definitions. It proposes them based on context and waits for explicit human approval. This ensures the ubiquitous language represents genuine semantic agreement, not just AI-generated documentation.

Once approved, the definition is added to domain-terms.md. From that point forward, the power ensures consistency: if someone later uses “order” to mean something different (like a payment record or shipping manifest), it flags the inconsistency and prompts clarification. Should the team discover they need separate concepts, they can establish distinct terms like “Customer Order” and “Fulfillment Order,” each with its own precise definition within its bounded context.

The power doesn’t impose a rigid formal language. Instead, it helps the team build their own shared vocabulary organically as they work, making ambiguities visible before they propagate into code. The result is that humans and AI collaborate on clarification, while domain semantics remain stable and traceable from requirements through implementation.

From Ubiquitous Language to Implementation

Why invest this effort in establishing a ubiquitous language before writing the first line of code? Because precise semantic agreement fundamentally constrains implementation decisions in a positive sense.

When the entire team, including AI coding agents, shares an explicit understanding of what “order” means in the Order Management context, entire classes of architectural mistakes become impossible. The AI agent implementing the checkout flow knows exactly what data structure to create, what lifecycle states are valid, and which operations belong to this concept versus others like payment processing or shipping.

This semantic precision enables several critical capabilities:

Refactoring with Confidence: When “order” has a precise definition in domain-terms.md, we know exactly which code belongs together. Refactoring becomes safer because the boundaries between concepts are explicit. We can confidently move order validation logic into the Order class, knowing it won’t accidentally include payment processing concerns.

AI-Generated Code Quality: When an AI coding agent reads the ubiquitous language before implementation, it generates code that accurately reflects the domain model. Instead of generic class names like DataProcessor or RequestHandler, it creates CustomerOrder with methods like confirmPurchaseIntent() that mirror the team’s shared vocabulary.

Long-term Maintainability: Code that speaks the domain language remains comprehensible as the team evolves. A developer joining the project six months later can read domain-terms.md, understand the ubiquitous language, and immediately recognize those same terms throughout the codebase. The semantic agreement established during specification persists into the implementation.

Conclusion: Precision Before Code

The greatest leverage in modern software development with AI lies not in accelerating typing, but in establishing semantic agreement before implementation begins. Kiro has already taken a giant leap in this direction with its spec-driven development workflow, which structures the development process around creating clear specifications, design documents, and task lists before any code is written. This blog post explored how we can extend this foundation by establishing a ubiquitous language, a shared vocabulary that ensures all project participants, including AI coding agents, share the same understanding of domain terms throughout the entire development lifecycle. Reducing ambiguity through a ubiquitous language is genuine design work, the mandatory prerequisite for safe automation.

LLMs are amplifiers. When we give an AI agent ambiguous instructions where “order” could mean a dozen different things, it amplifies the chaos by generating code that reflects our confusion. But when we first establish that “order” means precisely “a customer commitment in the Order Management context,” the AI amplifies our clarity by generating code that accurately implements this shared understanding.

Spec-driven development with tools like the Spec Ambiguity Resolver ultimately means using the machine as a partner in thinking more precisely. The AI doesn’t just execute our specifications, it participates in refining them by making ambiguities visible, proposing definitions for our review, and maintaining consistency across the entire project lifecycle.

The result is software where the code speaks the same language as the specifications, where AI agents and human developers share the same semantic foundation, and where the ubiquitous language established in early conversations persists all the way through to implementation. This is how we move from natural language programming to truly collaborative software development.

The need for an automotive coding assistant is driven by several converging trends. The automotive sector is transitioning from traditional mechanical engineering to a software-defined vehicle (SDV) model, where a car’s value is increasingly defined by its software features. This shift demands scalable development practices to manage the complexity of autonomous driving, electric powertrains, and advanced connectivity. Recent advances in AI and machine learning now enable assistants to deeply understand automotive software, helping developers focus on innovation rather than repetitive tasks or extensive documentation searches.

What Is an Automotive Coding Assistant?

An automotive coding assistant is an intelligent companion for developers in the automotive industry, designed to streamline coding processes, boost productivity, and ensure high-quality code. It leverages advances in generative AI, natural language processing, and machine learning to help developers solve the many challenges of automotive software development. Imagine a virtual collaborator that can provide suggestions and write code for AUTOSAR components or walk you through regulatory compliance standards and their implications for the respective code.

Potential Challenges and Considerations

While the promise of an automotive coding assistant is enormous, there are challenges to address. The assistant must be designed with a deep understanding of safety and security requirements, which are non-negotiable in the automotive space. Developers may have concerns about the reliability of AI recommendations. Trust can be built by providing clear references to the sources of each suggestion, such as code repositories or official documentation.

Sketch of an Automotive Software Development Assistant

The assistant can generate code snippets based on developer goals, whether it’s a simple vehicle sensor readout or a complex algorithm for battery management. It helps refactor legacy code to improve compliance, readability, and maintainability. Moreover, the assistant identifies existing code implementations that fulfill certain functions while meeting regulatory requirements, enabling developers to reuse proven solutions.

Current automotive coding assistants and Large Language Models (LLMs) can generate C/C++ code but aren’t specifically trained for embedded automotive systems. Enhancements can be made by fine-tuning existing models to align with automotive standards or by using prompt engineering to guide the model’s responses. An agent can act as an intermediary, enhancing developer prompts with relevant requirements to ensure the generated code meets industry standards. This mechanism can also be used to make existing code compliant with regulatory standards.

Another important feature is finding existing compliant code implementations in private code repositories. This is done using a process called retrieval-augmented generation (RAG). Essentially, the codebase is analyzed and broken down into searchable components, which are stored in a specialized database. The assistant can then search this database to quickly find and recommend the most relevant code snippets, making it easier for developers to reuse proven, compliant solutions in their projects.

Conclusion: Driving Into the Future

The automotive coding assistant is more than just a tool—it’s a partner for every developer navigating the complexities of the automotive software landscape. As the industry continues its shift toward software-defined vehicles, the need for such intelligent assistants will only grow. They promise to reduce development time, enhance safety, and ultimately accelerate the journey toward a future of connected, autonomous, and intelligent vehicles.

Following a strategy of delivering high-quality software faster, traditional companies in any industry struggle to catch up and accelerate. Many traditional companies improve yearly in delivering high-quality software. However, digital-native companies still have the ability to accelerate faster, making it nearly impossible for traditional companies to overtake them.

Giving software developers the option to choose between cloud providers involves investing in setting up and maintaining multiple cloud environments. These environments must meet the company’s security, compliance rules, regulations, and best practices. For example, a microservice runtime like Kubernetes might need to be maintained multiple times, or a VPN connection to a company-owned data center might need to be set up and maintained multiple times. All of this comes at a cost of time and money.

Considering the bigger picture, many companies are better off going all-in with one cloud provider as their initial (multi)-cloud strategy. Reducing complexity allows developers to focus on the core business, driving innovation and speeding up software development. Companies that worry too much about future vendor lock-in may miss out on new market opportunities their competitors are pursuing. Being prepared to switch easily between cloud providers does not prevent a company from becoming irrelevant.

Some companies focus on providing what they believe are the right tools for their developers to thrive and create business value. However, I propose turning the focus to the developers themselves. Developers typically know best how to achieve their tasks when they have clear and measurable goals. Companies should listen to their developers, remove roadblocks, and provide them with the freedom, time, commitment, and learning opportunities they need.

A concise multi-cloud strategy could be:

ACME Corp (Multi)-Cloud Strategy

We don’t invest time and resources in preparing for a vendor lock-in scenario with a fully integrated multi-cloud setup. Instead, we focus on enhancing our teams’ software delivery performance. Besides mitigating the risk of optimizing for a problem that might never occur, we can react to market changes much faster. Adopting a new cloud provider is one option we have in our portfolio.

We measure our software delivery performance using the four key metrics described in the book Accelerate. We improve step by step, working on mastering the 24 capabilities outlined in the book.

To emphasize the importance of focusing on developers and their productivity, consider this example: Suppose a company needs to switch cloud providers due to a price increase. A company that previously focused on creating an integrated cloud platform across multiple vendors might feel that their upfront investment is paying off. However, if this company did not invest in the continuous training and learning of its development teams, their skills may not be suited to seamlessly transition from one cloud provider to another. Additionally, these teams might struggle to adapt and learn how the new cloud provider operates.

In conclusion, let’s compare the approaches of two companies: The first company went all-in with one cloud provider, focusing on developing its developers’ hard and soft skills. As a result, its developers can more easily learn the new cloud platform, plan, and make decisions on how to migrate applications from one cloud provider to another. The second company focused on creating a platform that integrates multiple cloud providers but did not invest in its developers’ continuous learning and skill improvement. Now, this company faces the challenge of having a tool that can speed up the transition from one cloud provider to another, but its developers lack the necessary skills to operate on the new cloud platform and struggle to learn and adapt to the new environment.

Running Example

Let’s begin with a running example that I will use throughout this article. The image below illustrates an artificial architecture of an online shop on the left, including systems responsible for payment (Payment Service) and delivery (Delivery Service). We assume initially that one instance of each service is running in the cloud. All services are cloud-native apps, as defined by the 12-factor app methodology (https://12factor.net), running in a single Amazon AWS region. All communication is REST-based.

Image 1: Running example

With this setup, customers can select products, place them into the shopping cart managed by the Shopping Cart Service, and initiate a workflow to purchase the products in the cart. This process involves the Payment Service to handle payment and the Delivery Service to manage delivery.

Murphy’s law states, “Anything that can go wrong will go wrong.” With only one instance of each service running, several potential failures can occur. Below, I describe each failure scenario and propose possible countermeasures, focusing primarily on the Delivery Service.

Instance Failures

Failure of the Delivery Service software can cause all invocations to fail immediately. A possible solution is to run multiple instances to enhance resilience. To distribute requests from the Shopping Cart Service evenly, a Load Balancer is necessary (see Image 2). There are two types of load balancers: middleware components such as Application Load Balancer (ALB) and client-side load balancers. With this setup, every Delivery Service instance must be capable of processing all incoming requests, affecting its internal architecture. For example, it’s not feasible for a Delivery Service instance to maintain sessions with the Shopping Cart Service since each request might be routed to different Delivery Service instances. The goal is to design the Delivery Service so that shutting down one or more instances won’t significantly impact its ability to process requests.

Image 2: Load balancers distribute requests evenly to all instances of the Delivery Service

Besides running additional instances for resilience, the Shopping Cart Service can implement the circuit breaker pattern. This pattern involves temporarily reducing requests to the Delivery Service upon detecting slower response times and resuming normal operation after a predefined interval, assessing whether the Delivery Service has recovered (https://martinfowler.com/bliki/CircuitBreaker.html).

Another potential failure is the loss of an entire cloud availability zone hosting the Delivery Service. Cloud vendors offer availability zones to enhance application availability. Distributing application instances across multiple zones can mitigate the impact of a zone failure, with load balancers in place to detect and reroute traffic in the event of a regional outage (see Image 3).

Image 3: Addition of Availability Zones

Network Failures

To address network failures, the Shopping Cart Service must maintain communication with the Delivery Service, achievable through message-oriented middleware (MOM) (see Image 4). MOM systems, such as queuing and publish-subscribe systems, facilitate reliable messaging between services, with queues serving as buffers to manage message flow. Amazon SQS (Simple Queue Service) and Amazon SNS (Simple Notification Service) are prime examples of MOM systems, facilitating reliable messaging between services, with queues serving as buffers to manage message flow.

Image 4 shows a message queue being set in place between the Shopping Cart Service and the Delivery Service. We don’t need the load balancer in between because the instances of the Delivery Service can process messages when they are able to.

Image 4: Introduction of queuing system

Thus, they are not overwhelmed by incoming messages because the message queue acts as a buffer for them. With the addition of the message queue the Shopping Cart Service can send messages to the Delivery Service even in the rare case the Delivery Service is not available due to a network outage.

Working with Service Level Agreements (SLAs)

Managing microservices in the cloud involves planning for unplanned downtimes. Although downtimes are inevitable, they can be managed within the downtime budget defined in each microservice’s SLA. For instance, the Shopping Cart Service could have a companion microservice to store and retry pending requests to the Delivery Service, ensuring minimal customer impact. Teams should strive to meet their SLAs precisely, avoiding reliance on better-than-expected uptime.

Compensating Actions

For extended downtimes that threaten SLA compliance, the Delivery Service team could implement compensating actions, such as offering vouchers to affected customers, to maintain customer satisfaction.

Conclusion

Implementing the measures outlined above can significantly improve system uptime, challenging the notion that service downtimes must be cumulatively calculated. The introduction of a message queue between services and the resilience of the companion service ensure that the system remains functional and responsive, even during service disruptions.

Do you have further ideas on making a cloud application more reliable? We would love to read it in the comments!

The image below shows a mental model of a traditional data center. The blue boxes resemble physical servers, each running four virtual machines (VMs). As a means of logically separating different servers running different kinds of applications, these servers run in different network zones. Customers can rent a physical host or single VMs residing in a specific network zone. Within one network zone, it is possible to access any VM from any other VM. Thus, customers need to implement intrusion prevention measures. There might be cases where VMs of different customers run on the same physical host.

The only way to communicate between network zones is via the firewalls between them. The firewalls refuse any messages that have not been explicitly allowed before. In order to allow a message to pass through a firewall, a firewall rule needs to be created. A firewall rule can, for example, state that all VMs on a specific physical host can pass. Firewalls can be deployed as virtual appliances or in the form of a hardware firewall.

In contrast to that, a cloud data center does not have network zones with firewalls between them. Networking is fully virtualized. Each customer can create multiple virtual network zones called Virtual Private Clouds or VPCs. An arbitrary number of resources like VMs can be put into these VPCs. In the image below, the VMs marked with a dot of the same color are assigned to the same VPC. It is possible that different VMs running on the same physical host are assigned to different VPCs.

Each customer is able to design what traffic can enter and leave a VPC. At AWS, Security Groups are the means to restrict and allow traffic to and from the resources assigned to a VPC, for example.

Additional Resources: A white paper with details of how virtual networking is implemented at AWS using the AWS Nitro System: https://docs.aws.amazon.com/pdfs/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.pdf

A paper showing how AWS used formal verification methods to prove the correctness of the boot code for the AWS Nitro System:

https://link.springer.com/chapter/10.1007/978-3-319-96142-2_28

When considering Kubernetes for application development, it’s essential to assess how its setup time impacts the project’s time-to-market. In addition subsequent maintenance of the respective infrastructure needs to be considered. Kubernetes, known for its robust container orchestration capabilities, involves a detailed and time-consuming setup process. This article focuses on analyzing this aspect and its implications on reaching the market efficiently.

Understanding Kubernetes Setup Duration: The setup process for Kubernetes is comprehensive. It starts with an initial learning and planning phase that can take up to 30-40 hours, attributed to the extensive documentation and complex nature of Kubernetes. Following this, installation, configuration, security setups, testing, and integration with CI/CD pipelines collectively contribute to a setup time that can reach 150 hours.

In addition the effort needed to maintain a Kubernetes cluster should not be neglected. A new Kubernetes version is released every 4 months.

Time-to-Market Considerations for Small-Scale Applications: For smaller applications with a development timeline shorter than the Kubernetes setup time, the additional delay in market entry might not be favorable. The extended period needed to deploy Kubernetes could outweigh the benefits for projects where speed to market is a critical factor. However, if these applications are expected to scale significantly or require specific operational capabilities, the long-term advantages of Kubernetes, such as scalability and robust infrastructure management, could justify the initial time investment.

Large, Complex Applications: In the case of larger applications, especially those built on microservices architecture, Kubernetes presents clear benefits. The platform’s ability to manage complex deployments efficiently can be a game-changer, facilitating faster updates and deployments in the long run. Here, the initial setup time is offset by the operational efficiencies and scalability that Kubernetes brings to the project, ultimately aiding in a more streamlined and effective market entry over the project’s lifecycle.

Conclusion: Choosing Kubernetes requires balancing the technical requirements of the application with strategic business goals, particularly time-to-market. While the initial setup phase is time-intensive and may pose challenges for rapid deployment, Kubernetes offers substantial long-term benefits for applications that require scalability and complex operational management. The decision to implement Kubernetes should be aligned with both the immediate market entry goals and the anticipated future needs of the project.

Selenium is a framework to automate browser based UI tests. UI Developers use it to create regression tests for their designs. OpenCV is a library that can be used to detect and classify objects in images.

Using both tools we are able to create a test that can react to the content of a WebRTC stream. The test can for example check if a video stream is showing a certain object.

This is a minimal example showing the interaction between selenium and OpenCV. It opens a browser, takes a screenshot, detects faces in the screenshot and draws rectangles around them. To make it work you need to download the haarcascade_frontalface_default.xml file and place it in the same directory as the script and install the selenium and openCV modules.

pip install selenium opencv-python


```python:
from selenium import webdriver
import cv2

# Initialize Selenium and open a webpage
driver = webdriver.Chrome()
driver.get('https://en.wikipedia.org/wiki/Jean-Luc_Picard')

# Take a screenshot and save it as 'screenshot.png'
screenshot = driver.get_screenshot_as_png()
screenshot_path = "screenshot.png"
with open(screenshot_path, "wb") as file:
    file.write(screenshot)

# Process the image using OpenCV
image = cv2.imread(screenshot_path)

# Initialize Haar cascade for face detection
face_cascade = cv2.CascadeClassifier('haarcascade_frontalface_default.xml')
gray_image = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)

# Detect faces
faces = face_cascade.detectMultiScale(gray_image, 1.1, 4)

# Draw rectangles around detected faces
for (x, y, w, h) in faces:
    cv2.rectangle(image, (x, y), (x+w, y+h), (255, 0, 0), 2)

# Save the processed image
cv2.imwrite("faces_detected.png", image)

# Close the browser
driver.quit()

In CDK there is a concept of a Construct. Constructs are collected in the CDK Construct Library. There are three types of CDK Constructs, L1, L2, and L3. The letter L stands for level.

I am going to explain these Construct layers in a minute. There is one other important concept of CDK that needs to be understood in order to be able to grasp and understand the Construct concept. At compile time a CDK program is translated to an AWS CloudFormation script in the background. This AWS Cloudformation script is then executed and resources are deployed on AWS.

With that in mind we can have deeper look at the Constructs concept. Using an L1 construct a CDK developer can directly create and work with an AWS Cloudformation resource. The developer can recognize classes that are L1 Constructs by the prefix “Cfn”.

Please see the example below from the AWS documentation:

const bucket = new s3.CfnBucket(this, "MyBucket", {
  bucketName: "MyBucket",
  corsConfiguration: {
    corsRules: [{
          allowedOrigins: ["*"],
          allowedMethods: ["GET"]
    }]
  }
});

A L2 Construct is much more convenient, because some variable needed to initialize the respective AWS CloudFormation resource are already prefilled in the background with default values. See this example from the respective documentation using an L2 Construct:

import * as s3 from 'aws-cdk-lib/aws-s3';

// "this" is HelloCdkStack
new s3.Bucket(this, 'MyFirstBucket', {
  versioned: true
});

The most interesting type of Constructs are L3 Constructs. These Constructs represent patterns. Patterns are implementing solutions to more complex reccurring problems. The documentation gives an example for an AWS Fargate container cluster with a load balancer in front of it. Developers can also create their own patterns and use this tool to for example create a base line infrastructure for an development team to use and build-upon.

In practice, Virtio devices can be addressed and utilized just like actual hardware devices. Virtio serves as the standard Input/Output (IO) virtualization framework for the Linux KVM (Kernel-based Virtual Machine) hypervisor. A hypervisor offers a management layer that enables the operation of multiple virtual machines on a single hardware unit. Virtio provides specifications for various device types, such as block storage and network devices, thereby eliminating the need to use different frameworks for different device types.

Moreover, Virtio is recognized for delivering superior performance as it belongs to a class of virtualization frameworks that employ paravirtualization techniques, presenting an edge over fully virtualized device abstractions.

Accelerating ECU Development with Virtualization

Striving to reduce development times for Electronic Control Units (ECUs), AWS Automotive customers are contemplating providing a virtualized version of a new hardware platform to software developers well ahead of the real hardware’s availability. This approach enables software development teams in two ways:

1. They can begin creating software right from the start of a new ECU development project
2. They have a means of providing each developer with multiple development environments to experiment with.

ARM is one of the leading suppliers in the automotive industry, licensing its CPU architecture for use in vehicle microcontrollers as well as In-Vehicle Infotainment systems.

An Overview of ARM CPU Families

ARM boasts a number of CPU families. One such family is the Cortex-family. Targeting microcontrollers, ARM provides the Cortex-M group of 32-bit RISC processor cores, which are used as main microcontroller cores but can also act in an SoC as a hidden CPU for a dedicated purpose, like a power management controller.

Another member of the Cortex-family is the Cortex-A group of 32-bit and 64-bit RISC ARM processor cores. These processor cores are designed to be multi-purpose CPUs. AWS employs 64-bit cores from this family for the Graviton EC2 instance family. The 64-bit Cortex-A cores implement the ARMv8 architecture, which encompasses a number of features important for modern, multi-purpose operating systems like Linux to function.

Deploying to AWS and Handling CPU Architecture Differences

Since AWS utilizes CPUs implementing the ARMv8 architecture, software targeted for vehicle ECUs equipped with Cortex-A CPUs can be directly deployed to AWS without recompilation. In contrast, software targeting vehicle ECUs equipped with Cortex-M CPUs cannot directly run on AWS ARM CPUs, like the Graviton CPU, due to the fundamental differences in the CPU instruction set design.

Emulating ARM Architecture

To navigate this issue, one can use an emulator like QEMU or ARM Virtual Hardware. Unlike QEMU, AVH supports many more ARM CPU architectures as well as so-called AVH Fixed Virtual Platforms (AVH FVPs). Beyond the respective ARM CPU architecture and instruction set, AVH FVPs provide a simulation of an ARM-Based SoC (System on Chip). SoCs complement the CPU with peripherals useful for the intended use case for which the SoC is designed. For ARM Virtual Hardware, there is an Amazon Machine Image available on the AWS Marketplace. Please follow the instructions here to run an example speech recognition model on a virtualized