Running CarMaker on AWS cloud

ADAS validation is reaching a scaling wall. Each new feature, sensor configuration or regulatory requirement multiplies the number of driving scenarios that must be tested, and every scenario may need to run across many parameter variations. On a local workstation these runs execute one after another, so turnaround time grows directly with the size of the test set. Engineers wait, hardware sits fully loaded for hours and the validation backlog builds up.

Crucially, the bottleneck is not only raw compute. It is also a workflow problem. Manual environment setup, version drift between machines, inconsistent tool installations and repeated hand-configuration all introduce delay and risk. Two engineers running the same test on differently configured PCs may not get comparable results. The real objective, therefore, is not merely to add more processing power, but to redesign the way simulation work is defined, launched, tracked and measured so that it becomes repeatable and scalable by design.

The example used in this article reframes CarMaker as more than a remotely accessible application. It presents a virtual engineering workbench composed of four cooperating layers, each of which is controlled and standardized. The user-access layer provides a single web front end for role-based interaction. The environment layer supplies standardized, pre-built machine images so that every engineer works from an identical CarMaker installation. The execution layer runs the actual simulations, either interactively or in parallel batches. Finally, the results layer captures outputs and key performance indicators for monitoring and analysis. Because these layers are separated cleanly, each can evolve independently while the overall workflow stays consistent.

The system is built on an Everything-as-Code (EaC) principle. Every resource – networks, servers, container images, permissions and compute fleets – is described in code and provisioned automatically when a workflow runs, then disposed of when the work is finished. Nothing is left running idle, which keeps cost low and avoids the drift that comes from long-lived, hand-tended servers. This design fits CarMaker naturally and mirrors the practices used in modern software engineering.

At the center of the architecture is a Streamlit web front end, packaged as a Docker container and hosted on an Amazon EC2 instance. This is the single point of interaction for users. Behind it sits a continuous integration and delivery (CI/CD) layer that combines a GitHub source repository, AWS CodePipeline for orchestration, AWS CodeBuild for building container images, Amazon ECR as the image registry and AWS CloudFormation for deploying infrastructure. When a user requests an action, the front end triggers the relevant pipeline, which builds whatever is needed and deploys it on demand.

Two compute environments perform the real simulation work. An interactive EC2 GUI instance, enabled with NICE DCV remote-desktop streaming, gives engineers a full CarMaker graphical session in the cloud. An AWS Batch fleet runs the CarMaker command-line interface across many instances at once for large-scale, parallel execution. Supporting these are the storage and configuration services, such as Amazon S3 buckets that hold pipeline artifacts and CarMaker assets or the Amazon DynamoDB table that tracks simulation runs for example. All of this lives inside a single virtual private cloud (VPC) with public subnets and an internet gateway, connecting the layers securely.

The workbench is delivered as four independent pipelines, each modeling a recognized software-engineering workflow, which build on this shared base:

1. Front-end pipeline: This pipeline builds and deploys the web interface itself through which users select and trigger every other workflow.
2. AMI pipeline: This pipeline produces the standardized environments. Using EC2 Image Builder, it starts from a base Amazon Linux image, installs CarMaker together with the required project files and license configuration pulled from S3, and captures the result as a reusable Amazon Machine Image (AMI). Environments therefore become versioned artifacts rather than hand-built snowflake machines: one image can be launched many times, identically, on demand.
3. EC2 GUI pipeline: This pipeline gives engineers an interactive CarMaker desktop in the cloud and decouples CarMaker from any single physical workstation: the same standardized session can be started, used and shut down whenever needed, replacing a fixed local install with a consistent, on-demand remote one.
4. Batch pipeline: This pipeline delivers scale-out execution, the heart of the performance story. Instead of running scenarios sequentially on one machine, the work is distributed across many instances in parallel, scaling with the number of available CarMaker licenses. Turnaround time falls from the length of the entire queue to roughly the length of a single run.

Two further ideas make the workbench a genuine engineering platform rather than a remote runner. The first is change-driven regression. Because the whole system is defined in code and orchestrated by pipelines, a change to a feature, model or scenario can automatically trigger the relevant simulations. Validation then behaves like a continuous-integration process – an integral, automated part of development – instead of a manual step performed on the side. Engineers gain fast, consistent feedback whenever something changes.

The second idea is observability. The principle is simple: what cannot be measured cannot be scaled. The front end integrates a native Amazon CloudWatch dashboard, organized into KPI sections for all simulations, braking, rollover, as well as handling and stability. For richer analysis it can export KPI datasets to Amazon QuickSight, scanning the results in S3, publishing run-level and summary CSV datasets and setting up the supporting Glue and Athena tables automatically. Metrics such as runs per week sit behind the simulation workflow, so teams can see throughput, spot bottlenecks and make informed decisions about where to scale.

A real engineering organization does not run a single, uniform toolchain, and the workbench does not require one. CarMaker remains the simulation core, while the surrounding layers – application and software code, models built in tools such as Simulink and model-based design, CI/CD automation and orchestration, and cloud operations on AWS – are free to vary between teams. This deliberate separation means adoption can happen one team at a time, avoiding a disruptive big-bang migration. Groups can move onto the cloud workflow at their own pace while continuing to use the specialized tools they already depend on.

The example is designed around two complementary roles and deliberately brings together a broad set of AWS services to demonstrate how each can work with CarMaker. The cloud developer is experienced in building cloud systems and is responsible for implementing the example, deploying the foundation and pipelines, and getting the workbench running on AWS. To adopt the example, this person must understand the AWS services involved and how they fit together.

The CarMaker user on the other hand is the day-to-day consumer of the workbench: an engineer who opens the web front end to launch a remote CarMaker session or to submit a large set of scenarios for parallel execution, without needing to manage any of the underlying infrastructure. Separating these roles keeps the experience simple for the simulation engineer while giving the platform team full control over how resources are built and governed.

All in all, this exemplary process presents how CarMaker operates as a cloud-native, on-demand engineering platform. A single web interface drives four automated pipelines that build the front end, produce versioned environments, launch interactive remote sessions and run massively parallel batch simulations, all defined as code and provisioned only when needed. Change-driven regression and built-in observability turn simulation into a measured, continuous part of the engineering process. The design demonstrates that intensive ADAS validation can scale elastically on AWS while remaining repeatable, measurable and maintainable, breaking through the scaling wall that limits the traditional workstation model.

Two practical notes apply. First, this is an illustrative example intended to prove the concepts and show the AWS services involved, not a finished product. Teams should design and harden their own implementation before production use. Second, the example depends on IPGLock for CarMaker electronic license management, which must be set up and running within the target VPC, with one license required for each running CarMaker instance, whether interactive or in a parallel batch.

If you are interested in cloud solutions, you might also want to discover VIRTO.