Stellantis’ SDV transformation with the Virtual Engineering Workbench on AWS

Stellantis N.V., born from the merger of FCA and PSA Group, leads the change towards software defined vehicles (SDV). As part of this transformation, AWS and Stellantis created the “Virtual Engineering Workbench (VEW)”, a modular framework to develop, integrate, and test vehicle software in the cloud, ultimately connecting their vehicles to the cloud.

Today’s automakers face challenges such as:

• Advanced features like autonomous driving and personalized infotainment heighten software complexity. Concurrently, customer expectations rise, pressuring OEMs to accelerate feature deployment.
• Engineers and testers tackle very specialised toolchains, third-party component integration, safety, and quality standards which required in depth knowledge.
• Complicated & diverse software development environments bring integration challenges, requiring lots of coordination, as these specialised configurations impose the risk of incompatible environments.

In conclusion, automotive challenges demand adaptive solutions. Amid software complexities, shifting expectations, and innovations are required. To overcome these challenges, we collaborated with Stellantis on innovative solutions, such as the VEW.

In this blog, you will learn how AWS and Stellantis created the VEW, and how Stellantis is using the VEW Framework to enable use cases. We will also delve deep into a use case related to virtual validation.

Virtual Engineering Workbench

The Framework
This solution contains a framework that addresses the challenges of the automotive software development by integrating essential elements like tools, targets, environments, automation, and a user-friendly portal. Let’s delve into how these components work together.

Tools: Powering Productivity
The Tools pillar of the VEW acts as a launchpad for getting started. It provides predefined environments tailored to specific use cases. These environments come fully equipped with all the tools, integrated development environments (IDEs), and licensing necessary for developers to jump-start their projects. Whether working on advanced driver assistance systems or personalized infotainment applications, these specialised environments ensure developers have the right resources to begin their work effectively.

Targets: Bridging Software and Hardware
Within the VEW, the Targets pillar plays a crucial role in connecting software to the later target environment. By providing different layers of software/hardware stack abstractions, developers tailor their test target to specific use cases, ensuring that their software aligns with the intended functionality and architecture. This flexibility accommodates the diverse needs of vehicle software developers in Stellantis ranging from human-machine interface (HMI) developers all the way to base software developers.

Environments: The Foundation of Functionality
The Environments pillar contains inputs for the previously discussed targets. An input can be an user input simulation or for example bus data that will be replayed. These environments serve as the crucial input for the workload on target platforms like the user input simulation for HMI related validation. The interaction between these environments and the target platforms verifies the functionality of software parts. This validation ensures that software being developed performs as intended under a variety of conditions and makes validation  available to everyone.

Automation: Streamlining Processes
At the core of the Virtual Engineering Workbench lies automation. This automation orchestrates every aspect of the VEW. From provisioning environments to managing workflows, automation enhances efficiency. It ensures that tasks are executed based on automated triggers from previous steps, minimizing the manual effort required. By harnessing automation, developers focus on innovation and problem-solving rather than repetitive operational tasks.This help to reduced time to market and feature cycles.

Self-Service Portal: User Empowerment
The self-service portal is a user-facing interface that simplifies interaction with the VEW. By abstracting away specific knowledge around how the platform works, the portal empowers users to initiate tasks and manage environments with ease. This streamlined approach allows developers to focus on development. They orchestrate processes efficiently and contribute to their projects without being bogged down by technical intricacies.

Incorporating these key elements – Tools, Targets, Environments, Automation, and the Self-Service Portal – the VEW offers an integrated solution that streamlines software development for Stellantis. It provides developers with the tools they need, the flexibility to target different virtualisation levels, and the crucial environments for thorough validation. This platform, along with its user-friendly interface and automation capabilities, contributes to a more efficient and productive software development process.

The Architecture

After introducing the VEW Framework, we want to shed light on how this is actually being built on AWS. Before getting into the details of the architecture, its worth mentioning that VEW architecture is built following 4 Solution Tenets:

• First, self-service accessibility across the entire engineering chain
• Secondly, a design tailored for global scale and extensive usage lays the foundation for accommodating a diverse range of projects and users on a single platform
• Thirdly, by incorporating virtualization, we effectively reduce hardware dependency, enabling developers to work efficiently in virtual environments without being constrained by physical resources.
• Finally, the commitment to ensuring consistent and reproducible software artifacts throughout the entire development process ensures the compatibility and reuse of environments.

The VEW architecture is composed of 6 building blocks:

Web Application
Web Application is the building block which serves as the entry for self-service portal. It provides users to discover, provision and manage their Workbench Products based on their roles. In order to provide it, Web Application block facilitates authentication and includes Role-Based Access Control (RBAC). It means users are assigned specific roles, which will determine the types of Workbench Products they can access. For a more detailed overview of the Web Application architecture there will be a follow-up blog post.

Product Catalog
Product Catalog is responsible for the packaging, distributing and provisioning Workbench Products to a catalog which can be used by endusers to list. In this context, a product refers to an AWS Service Catalog product. We provide different kind of products for the different user groups, such as AUTOSAR Classic Workbench product for Electronic Control Unit (ECU) Developers, or XiL Tester Workbench product for System Integrators.

AWS Service Catalog makes the product management easier. For example, in order to add a new product, product contributors need to create a new version of the Service Catalog product template and stack. Then, they need to update the Amazon Machine Images (AMI) identifier with related image in product template. After registering the new product into the catalog, new product is ready to be deployed into target project accounts.

AMI Factory
AMI Factory, leveraging the AWS EC2 Image Builder, is dedicated to create, test and distribute Amazon Machine Images (AMIs) for all products in an automated way. AMIs are the basis for Workbench Instances. In detail, after creation of a product in the product catalog block, an Amazon EventBridge triggers AWS Step Functions workflow in AMI Factory building block. Then, workflow starts EC2 Image Builder pipeline which finally creates Workbench AMI for the created product automatically. At the end of the process, an AMI for the specific product is created with all necessary toolsets and their configurations.

Multi-tenant use case environment
We leverage multi-tenant use case environment for different use cases such as AUTOSAR Classic, XiL Development, Smart Cockpit etc. After creating use case specific AMIs with AMI Factory, we deploy them automatically into the target use case accounts like AUTOSAR Classic, and we create Amazon EC2 Instances as use case Workbenches by using the product AMI. This multi-tenant architecture allows for a clear separation of concerns and provides additional benefits, such as cost monitoring. Through this, it is possible to separate different projects and their respective data/artifacts into protected environments.

Landing Zone
VEW integrates with an existing landing zone in Stellantis. This landing zone provides automated account onboarding and account vending capabilities to VEW. It is responsible for creating and preparing the networking & account setup. Additionally, it allows users global and secure access to workbenches from and to corporate networks using AWS IAM Identity Center with the Stellantis Identity provider and AWS Control Tower.

Operations
In the operation system architecture, centralized monitoring capability is provided for all the platform. The Monitoring solution area serves as the central hub for aggregating all metrics. The logs and metrics are stored in respective account and encrypted by AWS Key Management Service. Operations part also implements collection and calculation of DevOps Research and Assessment (DORA) metrics and provides dashboards.

Virtual Validation on the Virtual Engineering Workbench

Automotive software development follows design, implementation, and validation phases, with different teams executing those phases separately. As mentioned earlier, consistency and feature cycle time are the challenges during the phases. To address these challenges, we introduced the SDV use case template on VEW, which comprises runtime environments and a pipeline that reuses the runtime environment to create artifacts. Runtime environments and pipelines are stored in Product Catalog. Build artifacts are stored in central repository, where one or more build artifacts can be used as input for downstream use cases.

Virtual Validation with AUTOSAR
Let‘s take Autosar Classic Development use case as an example. An ECU Developer can provision an AUTOSAR Classic Workbench which has all necessary toolset to implement new function and create binaries for the new function. When code is ready, they push their code and artifacts in a code repository like AWS CodeCommit or Github. With that, a verification and validation pipeline is triggered automatically to build, test and validate the developed code with the exactly same runtime environment from ECU Developer. After successful validation, the created binaries are uploaded to the STLA Stellantis Artifactory, which can be used in integration pipelines. Having these products readily available allows developers in the earlier stages of the software development lifecycle to reuse downstream artifacts, such as a testing pipeline, to directly verify their changes.

Benefits

Now that you’ve gained an understanding of the VEW, let’s summarize how it addresses the challenges we discussed earlier: accelerating feature development and deployment, handling specialized toolchains that demand deep knowledge, and dealing with complex and varied software environments that present integration challenges.

By offering environments with pre-installed industry-standard tools like Vector AUTOSAR and dSPACE Simulation tools in a supported environment, we significantly reduce developers’ onboarding time to minutes. These stable and shareable environments across the different development groups effectively tackle integration and compatibility issues.

Utilizing the self-service portal, the AMI Factory, alongside targets and environments, makes specialized toolchains readily accessible to developers through a user-friendly interface that requires no advanced knowledge. This accessibility enhances quality and promotes independence in managing artifact’s flow, thus reducing the time needed to verify changes and through this the cycle time.

By linking various organizations along the regulated development flow via platform automation and enforcing reusable artifacts, establishes a transparent, consistent software flow, enabling a manual-interaction-free Software development lifecycle.

Next Steps
Moving forward, the joint goal of AWS & Stellantis is to onboard all teams involved in the software development cycle and enable all steps, including final vehicle deployment, through the VEW.

Additionally, we aim to enhance the workbench’s capabilities for Autonomous Mobility / Advanced Driver Assistance System (ADAS) related workloads. Stellantis is able to integrate more traditional engineering domains like Powertrains, and revolutionize other parts of the organization’s Software development process.

On top more advanced capabilities like e.g., Co-Simulating Hardware-in-the-loop and Software-in-the-loop will be added to the VEW.

Conclusion

This blog post describes how the implementation of Stellantis’ VEW on AWS has proven to be a game-changer for the realization of the company’s software-defined vehicle vision. To learn more about AWS Automotive and other solutions, visit AWS Automotive.