How BMW Group and Qualcomm built an automated driving platform on AWS

In September 2023, Amazon Web Services (AWS) announced that the BMW Group has chosen AWS as the preferred cloud provider for BMW’s next-generation automated driving platform (ADAS platform). The BMW Group will develop its next-generation advanced driver assistance system (ADAS) using AWS to help innovate new features for its next generation of vehicles, the “Neue Klasse,” set to launch in 2025. BMW Group is co-developing the next generation of the Automated Driving Stack with Qualcomm which is based on the Snapdragon Ride system-on-chip (SoC) and computer vision stack from Qualcomm.

There are several challenges that BMW Group and Qualcomm need to solve in the Autonomous Driving/Advanced Driver Assistance Systems (AD/ADAS) space to bring various automated driving functions to maturity. This includes collecting test data over thousands of kilometers with an extensive range of different traffic scenarios and environmental conditions using test vehicles equipped with the latest sensors. This also involves testing the data quality with which a car perceives the totality of its surroundings. Additionally, the examples are subject to validation and verification of both safety and driving functions in a range of real-world, on-road scenarios and situations.

To address these challenges, BMW Group, Qualcomm and AWS Professional Services collaborated on the development of a multi-tenant AD/ADAS solution on AWS; the so-called next generation ADAS platform. It was built on top of AWS according to the following design principles:

Cloud first approach: Use the flexible and scalable AWS cloud to dynamically adjust resources according to need with AWS’s flexible pay-as-you-go billing model;
Reusability with IaC (Infrastructure as Code) blueprints and modules: Reduce development-cycle times by utilizing the AWS open-source projects Autonomous Driving Data Framework (ADDF) and AWS Deployment Framework (ADF);
Self-service: Use an UI-based portal to enable easy access and user administration for software engineers and other end users;
Collaboration: Designed for both multi-tenancy and shared-tenancy to foster cooperation among hundreds of teams across multiple companies and partners;
Global ADAS platform scope: The code base is capable of being deployed in the AWS China and AWS commercial partition.

This blog describes the architecture of a secure, flexible, scalable, and highly integrated next generation ADAS platform. The blog first discusses the next generation ADAS platform on a high-level from the perspective of the different personas which interact with the ADAS platform. Then, we describe the UI-based ADAS workload environment creation process from the perspective of an end-user. To dive one level deeper, the underlying ADAS platform deployment mechanism and architecture details are explained. At the end, insights are provided on how the ADAS platform is helping speed up the development time of ADAS-related workloads in an event-driven architecture.

Overview of the solution – The ADAS workload’s life cycle on the next generation ADAS platform

The BMW Group uses the ADAS platform to manage the validation and verification of Advanced Driver Assistance Systems (ADAS) workloads for the Neue Klasse. In this blog post, an ADAS workload is defined as any task related to real-world data ingestion, data quality control, automatic data labeling, annotation, and referencing. It also includes data analysis and visualization, simulations, reprocessing, and Key Performance Indicator (KPI) computation.

The diagram below outlines the end-to-end life cycle of a typical ADAS workload environment. It also shows the core personas supported by the next generation ADAS platform.

Figure 1. An ADAS workload environment’s life cycle on the ADAS platform—from provisioning to decommissioning

A BMW Group ADAS application owner requests the creation of an ADAS workload environment via the UI. These ADAS workload environments are called “Realms”. A Realm is a logical grouping of application logic, people, costs, and security settings that consists of four AWS accounts (for development (Dev), integration testing (Int), production (Prod) and CICD). A Realm is created only after an administrator explicitly approves it. Once a request is approved, AWS accounts are created automatically. These accounts are then provisioned with resources and controls for security, identity access management, networking, and preconfigured Git repositories. They also include CI/CD pipelines for ADAS workload development.
After successful creation and provisioning, an ADAS Application Owner manages access to the Realm and the application development team can be onboarded based on a well-defined role concept with granular permission assignments on a per-user basis.
The BMW Group ADAS application developers now have access to their provisioned development environment and, at this point, the ADAS validation development work can start. Users can access pre-deployed Git repositories and CI/CD pipelines. Common ADAS workloads include data ingesting, re-simulation, and data quality assessment, among others.
In the next step, the ADAS application developers integrate their ADAS validation application into a data mesh-like application structure similar to the BMW Cloud Data Hub (CDH). In this mesh, an event-driven approach allows ADAS workloads to communicate and exchange data with each other using well-defined patterns. An example ADAS workload is a Reprocessing-as-a-Service Realm (RaaS) that gets integrated into the event-driven data mesh ADAS application space.
The BMW Group ADAS application developers can monitor the infrastructure of their ADAS validation and verification workloads and if any issue comes up, various logging mechanisms are at hand to help provide a fast and consistent analysis.
A BMW Group financial operations manager and the ADAS application owners monitor the costs of Realms over time. Alerting is in place to avoid inadvertent cost incurrence as soon as predefined cost thresholds are passed. An extensive dashboard allows the swift and easy identification of key cost drivers and cost trends. The dashboard aggregates costs by custom-defined tags, AWS account and per Realm.
If a Realm is no longer required, a Realm Owner can trigger its decommissioning. The invoked decommissioning process performs several checks to help verify that stored data and artifacts are backed up before the automated decommissioning takes place.

The next section describes the structure of a Realm in detail and how to request it via the UI.

Solution – Creating ADAS workloads in Realms on the next generation ADAS platform

This section provides a deep dive into the Realm concept and how a Realm can be easily requested through the UI.

In the context of the next generation ADAS platform the following picture shows an overview of the Realm concept and the facilitated communication across Realms via overarching orchestration integrating each Realm into an event-driven, data mesh-like structure:

Figure 2. Definition of a Realm in the next generation ADAS platform

Each Realm has the following characteristics:

1. A Realm consists of four AWS accounts:

- A Dev AWS account to provide an isolated development stage.
- An Int AWS account to provide an isolated integration and test stage.
- A Prod AWS account to provide an isolated production stage.
- A toolchain (CI/CD) AWS account for managing code propagation between the other 3 AWS accounts (Dev, Int and Prod).

2. A Realm has an Owner (an ADAS application owner) who can do the following:

a. View costs and define budgets.

b. Manage access by granting and revoking user assignments to preconfigured roles via the UI.

3. A Realm is of a specific Realm class:

a. A Realm class defines the additional AWS resources that are deployed in the four AWS accounts. Based on the selected Realm class, specific predefined network resources, ADAS-related Git repositories and CI/CD pipelines will be deployed in the Dev, Int and Prod AWS accounts.

b. A Realm Owner can select the Realm class during Realm creation. An example for a Realm class is “Data Ingest”.

4. A Realm is fully integrated into the next generation ADAS platform:

a. Realms use AWS Systems Manager (SSM) parameters that describe the context of the Realm within the next generation ADAS platform (tenant, network setup and other metadata).

b. Tailored VPC configuration and network connectivity is available depending on the individual requirements of a specific Realm.

c. A Realm is automatically integrated into the ADAS platform’s centralized cost and billing management.

d. It offers full integration into the ADAS platform’s identity access management system.

e. For each Realm, automatic setup and enrollment with AWS security services is available.

f. Realms are set up to be easily integrated into Overarching Orchestration for event-handling as well as into centrally provided Logging and Monitoring capabilities.

5. A Realm belongs only to one tenant:

a. As the next generation ADAS platform is multi-tenant, a Realm can only belong to one tenant at a time.

The system allows intra-tenant Realm communication but prohibits cross-tenant exchange.

Figure 3. End-to-end Realm creation workflow on the ADAS platform’s self-service UI

Now that we explained the concept and creation of Realms let us show you in the next chapter the deployment mechanisms which are used to provide all the infrastructure to make this workflow possible.

Solution Details – Deploying the next generation ADAS platform

To be able to create Realms and run the workflows outlined in the previous sections the next generation ADAS platform first needs to be deployed by the ADAS platform DevOps team in an empty organization by using the AWS Organizations service:.

In this section we outline the initial ADAS platform deployment and the subsequent update process.

Setting up the AWS Organizations

The starting point for the next generation ADAS platform is three empty AWS Organizations:

Development AWS Organization (Dev Org)
Integration and Testing AWS Organization (Int Org)
Production AWS Organization (Prod Org)

Each AWS organization contains a full instance of the next generation ADAS platform. The Dev and Int AWS organization are used exclusively for ADAS platform development and testing by the next generation ADAS platform DevOps team, whereas the Prod AWS organization is used for deploying the ADAS workload environments for the ADAS application developers. This setup enables the development of new ADAS platform features without risking the stability of the Prod Org instance of the next generation ADAS platform. The following diagram shows the multi-AWS organization approach:

Figure 4. next generation ADAS platform multi-AWS organization approach

Setting up the Amazon Deployment Framework (ADF)

The ADAS platform uses AWS Control Tower to set up the initial AWS Organization, baseline security features and initial AWS accounts. To provide all ADAS platform functions, the ADAS platform DevOps team needs to deploy AWS accounts for networking, IAM access management, billing, cost control, AWS account vending, CI/CD, security, UI and logging and monitoring. In total, the system deploys 94 unique CDK- and CloudFormation-based ADAS platform-level applications (platform-level applications) across 14 AWS accounts on platform-level in multiple AWS Regions.

To do this in an easier way Amazon Deployment Framework (ADF) is used.

ADF enables and helps ensure the following for the next generation ADAS platform:

Unified deployment process for all platform-level applications within an AWS organization.
Common build instructions (deployment maps) for all platform-level applications across regions and accounts.
Well-defined code propagation process for all platform-level applications from one stage to the next stage. The deployment order is defined as: Dev Org to Int Org to Prod Org.
Definition of dynamic deployment targets using tags and labels.
Usage of a common unit and integrations testing approach across platform-level applications.
Standardized parameter-sharing pattern across regions and accounts.
Provisioning of monitoring and alerting capability to catch and react on deployment issues.

ADF auto-generates pipelines with AWS CodePipeline — a fully managed continuous delivery service that helps to automate release pipelines — based on YAML definitions known as deployment maps. This approach relieves the ADAS platform DevOps team of all the undifferentiated heavy lifting when it comes to CI/CD pipeline generation. Instead, the ADAS platform DevOps team can focus on writing high-quality code and tests. The following diagram shows how ADF works on a high level.

Figure 5. ADF workflow—from code repositories to fully deployed platform-level applications via pipelines automatically generated with AWS CodePipeline

Example deployment of a platform-level application through ADF

An example of a cross-account, multi-stack platform-level-application is the CDK app “Account Vending AppSync API” shown below. This specific platform-level application deploys the API to facilitate the parametrized creation of AWS accounts using an event-based, serverless approach. Once deployed this CDK application provides an API for AWS account provisioning, updating, and decommissioning. The starting point of the deployment of this API is the ADF deployment map shown below:

Figure 6. ADF deployment map for the CDK platform-level application “Account Vending AppSync API” with a breakdown of the different sections.

This deployment map contains all the information required for ADF to autogenerate the AWS CodePipeline. In this specific example the YAML file defines the pipeline metadata, the source provider, the build step with unit tests and the deployment target with and additional integration test. Based on this information, ADF generates the following AWS CodePipeline:

Figure 7. Pipeline autogenerated with AWS CodePipeline for the platform-level application “AppSync API Management” including build and test stages

The AWS CodePipeline comes with the following stages:

1. Source:
The source stage provides the code from the referenced AWS CodeCommit Git repository. In this example the content of the dev branch of the repository “platform-appsync-api-management” is used.

2. Build:

The build stage runs unit tests as defined in the repositories’ buildspec.yaml and it creates the build artifacts. In our example here the build artifacts consist of AWS CloudFormation templates generated by the “cdk synth” command.

3. DeployToDeploymentAccount-0:
The deployment stage executes the deployment of the platform-level application in scope to the target AWS account.

4. IntegrationTesting-0:
The integration testing performs different calls towards the just deployed account vending API to verify it works as expected across all endpoints.

Deploying platform-level applications at scale through ADF

Once all the ADF-autogenerated pipelines have been created, triggered, and successfully executed all the platform-level applications are deployed and the next generation ADAS platform is fully functional including the UI. The following screenshot shows a subset of the application deployment pipelines with a total of 120 deployment pipelines generated by ADF.

Figure 8. Subset of all the pipelines autogenerated with AWS CodePipeline that are the base for the next generation ADAS platform.

At this point, the next generation ADAS platform is fully deployed and is ready to be used by different users.

What’s next for ADAS application developers – Using the provisioned ADAS platform and Realms to help speed up ADAS verification and validation workload development

After deploying the next generation ADAS platform and creating all needed Realms the ADAS application developers have access to AWS services and necessary tools to support functional validation and approval. Each Realm provides key accelerators that empower BMW Group ADAS application developers to move faster. By default, each Realm has preconfigured CI/CD services that are ready to be used to develop, build and deploy IaC applications in the Realm with minimum effort. Another key accelerator is a centralized IaC repository that contains a collection of reusable IaC code modules based on the open-source projects Autonomous Driving Data Framework (ADDF) and Industry Data Framework (IDF). ADDF and IDF provide ready-to-run examples that implement common service patterns like an EKS-cluster. Every Realm on the ADAS platform has the ability to easily integrate into the custom-built overarching orchestration which facilitates standardized pub–sub communication across Realms.

Conclusion

This blog post outlined the life cycle of an ADAS workload environment on the next generation ADAS platform, which was built by BMW in collaboration with Qualcomm and AWS. It showed the ADAS Realm provisioning process through the platform’s bespoke UI. The blog then described the end-to-end process of deploying the scalable, secure, flexible and highly integrated next generation ADAS platform via ADF. It concludes by explaining how using the pre-provisioned components of a Realm significantly speeds up the development process for ADAS verification and validation. In this data-mesh environment this is achieved through a standardized deployment process that uses modules from IDF and an event-driven approach for cross-Realm communication.

Learn more about AWS offerings at the AWS for automotive page, or contact your AWS team today.

AWS for Industries