AWS for Industries

Accelerating SDV development with KPIT Cloud-Native Engineering Workbench on AWS

OEMs (Original Equipment Manufacturer) or automakers are looking to accelerate high performance computing (HPC) for software-defined vehicle (SDV) platform development to deliver mobility and personalized features faster to end vehicle users. Faster delivery of features with globally distributed teams requires the same automated pipelines for development, testing and validation with hardware parity framework at scale available globally. The cumbersome technical and non-technical steps involved to initialize, and configure a basic framework such as Adaptive AUTOSAR on a target hardware delay the ability to deliver faster features. Furthermore, OEMs struggle to scale the development globally due to the cost and availability constraints of hardware. It is possible to have hardware parity for development workbenches in AWS with 40% better price performance on AWS Graviton instances in many AWS regions. KPIT Cloud Native Engineering Workbench on AWS provide a solution to start development and testing instantly with Adaptive AUTOSAR in an AWS region without need of physical hardware or installation hustle and utilizes AWS infrastructure for scaling. It has automated pipelines for workbench creation and update. This solution is designed to do undifferentiated heavy lifting for OEMs to deliver features faster with global teams.

This blog post will elaborate how use of AWS Graviton-based hardware bit parity environment and continuous integration/continuous deployment (CI/CD) pipelines in KPIT’s Cloud-Native Engineering Workbench solution is accelerating SDV development globally. We will walk you through a diagnostic use case.

Overview of KPIT Cloud Native Engineering Workbench solution

A Software-Defined Vehicle is any vehicle that manages its operations, adds functionality, and enables new features primarily or entirely through software. Big teams are distributed across the globe doing SDV development and testing work. These DevOps team developers and testers need SDV development and testing environments. Chip shortages are a challenge. OEMs need a scalable environment in the cloud, where developers can more easily deploy their code and test functionalities just like they do on physical embedded hardware in vehicle. If customers create this software stack on Arm-based AWS Graviton instance then they can achieve edge-to-cloud parity for development and testing and remove dependency on target hardware for bit-parity. Bit-parity of software built on AWS Graviton ARM based instances and target deployment platform eliminates intermediate cross platform builds. This way development teams can quickly scale globally with a consistent environments for each developer and tester. AWS Graviton is designed to provide hardware bit parity environments, which enables global virtual demonstration of development and testing with CI/CD pipelines without the need of cross platform compilation. AWS is enabling partners and users to do cloud-based virtual validation resulting in end-to-end faster development of features.

KPIT’s Cloud Native Engineering Workbench on AWS for SDVs is designed to provide out-of-the-box Adaptive AUTOSAR cloud instances that will help jumpstart HPC platform and feature development on AWS. AUTOSAR configuration editor and reference applications, allow customers to rapidly develop Adaptive AUTOSAR services on AWS. This solution combines AWS CI/CD capabilities and AWS Graviton together with out-of-the-box Adaptive AUTOSAR readiness. After deploying this solution in an AWS customer account, the Adaptive AUTOSAR development environment and tools are available to developers just like having hardware available to each developer so that OEMs can focus on feature development and not worry about spending resources on setting up the basic environment. Detailed steps are explained in the following sections. KPIT’s Cloud Native Engineering Workbench is the first solution of its kind available on AWS Graviton for virtual engineering and virtual testing.

KPIT tools help automotive developers to provide a ready, real time environment for development, software lifecycle management, software packages generation and build capabilities with sample applications for getting started on AWS. This environment is also known as KPIT’s AUTOSAR Adaptive solution (KSAR Adaptive), it is composed of Adaptive AUTOSAR SDK (Software Development Kit) and vECU (Virtual Vehicle Electronic Control Unit) AMIs (Amazon Machine Image). Figure 1 is a minimalistic reference solution with Day-0 readiness for Cloud-native Adaptive AUTOSAR Application development which provides a sophisticated Service Oriented Architecture based AUTOSAR solution for HPC and SDV. KSAR Adaptive solution includes configuration and code generation tools required for development of AUTOSAR Adaptive applications. KSAR images are Amazon EC2 AMIs for launching development and testing environment in AWS with bit parity to hardware.

Cloud-native Adaptive AUTOSAR Application development using Adaptive AUTOSAR SDK and vECU AMIs

Figure 1 Cloud-native Adaptive AUTOSAR Application development using Adaptive AUTOSAR SDK and vECU AMIs

Steps to demonstrate Day-0 readiness for Cloud-native Adaptive AUTOSAR application development

KPIT Adaptive AUTOSAR based SDV middleware AMIs are shared with specific AWS Account IDs. AWS Account ID must be provided with AMI access requests to KPIT. SDV middleware stack, SDK and developer toolchain is locked to customer AWS Account ID(s). Reach out to KPIT for learning more about this solution.

Step 1: Environment pre-requisite setup using AWS CloudFormation

Customers deploy AWS CloudFormation scripts provided by KPIT in their AWS accounts to setup environments. CloudFormation creates developer group, developer group policy and security groups namely AdaptiveAppDevGroup, AdaptiveAppDevPolicy, AdaptiveAppDevPublic and AdaptiveAppDevPrivate, respectively.

Step 2: Create an AMI for AWS Graviton processors using the Yocto Project

First, we need the AMIs for the workbench. AMIs are used to launch instances with software packages pre-installed and pre-configured in AWS. KPIT’s Cloud-native Engineering Workbench is built using Yocto Project. It is expected that you will already have access to an Adaptive AUTOSAR stack source and an AWS account with appropriate permissions to create the resources required. In the following diagram, we describe the steps involved in creating a custom AMI.

Adaptive AUTOSAR AMI Build Process

Figure 2 Adaptive AUTOSAR AMI Build Process

The Yocto Project builds a customized workbench distribution in the form of an AMI.

  1. Adaptive AUTOSAR Virtual ECU AMI is an Adaptive AUTOSAR AMI containing an automaker’s operating systems and middleware enables instant Adaptive AUTOSAR machines as level 4 virtual Adaptive ECUs in the cloud. AWS Graviton ready AMIs provide the ability to launch 64-bit ARM based Adaptive AUTOSAR Graviton EC2 instances and deploy application on 64-bit ARM binaries compiled for production hardware. Adaptive AUTOSAR Graviton EC2 instances serve virtual ECUs in isolation as well as virtual ECUs as part of test bench for integration testing and system validation.​
  2. Adaptive AUTOSAR SDK AMI is an Adaptive AUTOSAR AMI containing an automaker’s operating systems, middleware, SDK, and sample applications that enables instant Adaptive AUTOSAR engineering workstations in cloud. It is designed to provide developers with secure, ready-to-code and AWS Cloud9 integrated developer workstations for teams of any size. New developers can avoid spending days/weeks on workstation setup before their first commit or code check in. It empowers developers to focus only on code, making it easy for them to access tools and resources they need without worrying about workstation configuration and maintenance. Pre-configured AMIs for specific Adaptive AUTOSAR projects enables engineers to get started with environment that’s geared and ready for building, deploying, running, and debugging their applications rapidly.

Step 3: Launch Adaptive AUTOSAR Virtual ECU on AWS Graviton instance.

  1. Go to the AWS Console and then to EC2 Dashboard & click “AMIs” in the menu on the left.

KPIT Adaptive AUTOSAR vECU AMI

Figure 3 KPIT Adaptive AUTOSAR vECU AMI
  1. Select “KPIT Adaptive AUTOSAR vECU”.
  2. Click “Launch instance from AMI”.
  3. Select the instance type as appropriate, “t4g.small” is sufficient for running lightweight adaptive applications.
  4. Select key-pair from the drop-down menu or create a new key-pair.
  5. Select “AdaptiveAppDevPrivate” security group for the VPC (Allows all traffic to/from within the VPC).
  6. You can either proceed with defaults for remainder of the settings or adopt as needed.
  7. Click “Launch Instance” to launch an Adaptive AUTOSAR Virtual ECU in cloud.
  8. Locate the instance, name it appropriate “KPIT Adaptive AUTOSAR vECU”. Ensure state of the Instance is “Running”.

** Take note of the Adaptive Virtual Machine’s private IP address **

Private IP Address of the Adaptive AUTOSAR vECU

Figure 4 Private IP Address of the Adaptive AUTOSAR vECU

Step 4: Launch Adaptive AUTOSAR Workbench EC2 Instance

  1. Go to the AWS Console – EC2 Management Console & AMI in the menu on the left.

KPIT Adaptive AUTOSAR SDK AMI

Figure 5 KPIT Adaptive AUTOSAR SDK AMI
  1. Select “KPIT Adaptive AUTOSAR SDK”.
  2. Click “Launch instance from AMI” (Orange button in right top corner).
  3. Select the CPU as appropriate, “t2.medium” is sufficient for lightweight adaptive applications development.
  4. Select key-pair from the drop-down menu or create a new key-pair.
  5. Select “AdaptiveAppDevPublic” security group for the VPC.
  6. You can either proceed with defaults for remainder of the settings or change as needed.
  7. Use Elastic IP Addresses for Adaptive AUTOSAR SDK EC2 instances to avoid dynamic IPv4 allocation.
  8. Click “Launch Instance” to launch an Adaptive AUTOSAR Engineering workbench.
  9. Locate the instance, name it appropriately as “KPIT Adaptive AUTOSAR SDK”, ensure instance state is “Running” and take note of the public IP.

Public IP Address of the Adaptive AUTOSAR SDK EC2 Instance

Figure 6 Public IP Address of the Adaptive AUTOSAR SDK EC2 Instance
  1. Connect to Adaptive AUTOSAR ECU instance using SSH. Find the SSH command by selecting the instance in the list and clicking on the “Connect” button.
    ssh -i “keypair.pem” ubuntu@ec2-[ip-address].compute-1.amazonaws.com

** You are now successfully connected to Adaptive AUTOSAR engineering workbench in AWS Cloud **

  1. Connect to the Adaptive AUTOSAR Virtual ECU using SSH.
    ssh -I “keypair.pem” ec2-user@<Adaptive AUTOSAR Virtual ECU IP Address>

** You are now successfully connected to Adaptive AUTOSAR Virtual ECU in AWS Cloud **

Step 5: Create the Cloud9 IDE environment

A cloud IDE is used for writing, running, and debugging code. AWS Cloud9 serves as a browser-based IDE for lightweight Adaptive AUTOSAR-based Cloud-Native Engineering workbench. Refer to AWS Cloud9 to learn more about Cloud9.

  1. Go to the AWS Cloud9 Console and click on ‘Create environment’
  2. Click “Create environment” and name appropriately
  3. Click “Next” to move to Step 2 and select SSH environment

Cloud9 SSH Environment Setup

Figure 7 Cloud9 SSH Environment Setup
  1. Click “Copy key to clipboard” and add it to Adaptive AUTOSAR SDK EC2 instance. It enables Cloud9 IDE based access to the Adaptive AUTOSAR SDK EC2 instance.
    ssh -I “keypair.pem” ubuntu@ec2-[ip-address].compute-1.amazonaws.com
    ubuntu@ip-xx.xx.xx.xx:~$ echo $'\n<Paste Cloud9 Public Key>\n' >> ~/.ssh/authorized_keys
  2. Click “Next” to move to Step 3 for Review and Click “Create environment” to proceed.

Cloud9 SSH Environment

Figure 8 Cloud9 SSH Environment

** You have successfully created a Cloud9 environment

and paired with SSH environment **

Step 6: Build and package an included Diagnostic Data Identifier (DID) Adaptive AUTOSAR application

KPIT Cloud-Native Engineering Workbench includes several application samples and a build + packaging tool. Packaging tool readily builds all the bundled applications and packages into installable software cluster packages. The tool builds only the packages listed in the configuration file. To execute this script, run following command.

cd $KPIT_PKGS ./package-builder.py -c linux-config.json

CI/CD pipeline typically builds all applications. Developers for their local builds can create a local configuration with fewer applications as shown in below “diag-did-app”.

Build and package an included DID Adaptive AUTOSAR application

Figure 9 Build and package an included DID Adaptive AUTOSAR application

This tool creates a “build” and “packages” directory in the $KPIT_PKGS folder for all the built binaries and the deployable packages respectively. As shown below, each package builds results in two packages to support install and removal over DoIP/UDS.

Diagnostic Data Identifier App Packages

Step 7: Deploy Adaptive AUTOSAR application on AWS Graviton EC2 based Virtual ECU

KPIT’s Cloud Native Engineering Workbench includes a deployer tool for easy deployment of Adaptive Applications. Tool is a special version/subset of diagnostics client that supports Unified Diagnostics Services (UDS) over DoIP for remote installation and removal of software cluster(s) on an AWS Graviton based Virtual Adaptive AUTOSAR ECU as well as a remote physical ECU hardware running Adaptive AUTOSAR stack w/ UCM.

./SwCLUDSDeployer <<target ip address>> <<Package Path>>

Install DIAG DID Application

$KPIT_TOOLS/package-tools/swcl_package_deployer/linux/SwClUDSDeployer 172.X.X.97 $KPIT_PKGS/packages/SWPKG_DIAG-DID-APP_1.0.0.0_install.tar.gz

Adaptive AUTOSAR Application Install

Figure 11 Adaptive AUTOSAR Application Install

As shown below, applications deployed on Adaptive AUTOSAR ECU are started immediately upon installation by the ARA::EXEC Execution Manager.

Adaptive AUTOSAR App is installed and starts running on vECU

Figure 12 Adaptive AUTOSAR App is installed and starts running on vECU

Uninstall DIAG DID Application

$KPIT_TOOLS/package-tools/swcl_package_deployer/linux/SwClUDSDeployer 172.X.X.97 $KPIT_PKGS/packages/SWPKG_DIAG-DID-APP_1.0.0.0_remove.tar.gz

Figure 13 Adaptive AUTOSAR Application Uninstall

Figure 13 Adaptive AUTOSAR Application Uninstall

Application process disappears upon uninstallation.

Figure 14 Adaptive AUTOSAR App stops running on vECU when uninstalled

Figure 14 Adaptive AUTOSAR App stops running on vECU when uninstalled

Step 8: Interact with the newly installed Adaptive AUTOSAR application

KPIT’s Cloud Native Engineering Workbench solution includes a configurable diagnostic tester tool for exercising of functionality/interfaces of an Adaptive Application(s). The tool is a special version/subset of diagnostics client that supports Unified Diagnostics Services (UDS) over DoIP for diagnostics interaction with an AWS Graviton based Virtual Adaptive AUTOSAR ECU as well as a remote physical ECU hardware running Adaptive AUTOSAR stack.

The following image illustrates diagnostics tester interacting (right bottom) with AWS Graviton EC2 based Adaptive AUTOSAR ECU. The tester is configured (top right) to read and write signals offered by the sample DID Adaptive AUTOSAR application.

autosar

The following is a minimalistic deployment view. Adaptive Application developers use readily available AMIs for launching EC2 instances that serve as a developer workbench and virtual adaptive ECUs in AWS. Virtual Adaptive ECUs can be launched in any region with AWS Graviton.

Figure 15 Deployment View

Figure 15 Deployment View

Conclusion

The KPIT Cloud-Native Engineering Workbench is designed to help jumpstart HPC platform and feature development, while providing better parity with target platform and enabling global scale and speed of software development.

It is also the first solution of its kind to be available on AWS Graviton for Virtual Engineering and Virtual Testing. AWS and KPIT are working together to make Adaptive Virtual Engineering for SDVs possible on AWS Graviton.

To learn more about this solution and get a LIVE demo, please visit the KPIT Technology Showcase at CES 2023 at Las Vegas Convention Center West Hall, 3rd Floor – W318.

TAGS:
Sushant Dhamnekar

Sushant Dhamnekar

Sushant Dhamnekar is a Senior Solutions Architect at AWS. As a trusted advisor, Sushant helps automotive customers to build highly scalable, flexible, and resilient cloud architectures in connected mobility and software defined vehicle areas. Outside of work, Sushant enjoys hiking, food, travel, and HIT workouts.

Stefano Marzani

Stefano Marzani

Stefano is focused on helping to solve the biggest challenges in the automotive industry. His current focus is helping the automotive industry transition to software-defined vehicles, enabling autonomous functionalities, mobility fleet solutions, and delightful user experiences. Stefano’s technical expertise lies in IoT, Machine Learning, Vehicle Architecture, HMI, and Automotive Software Development & Tooling.

Vijay Balani

Vijay Balani

Vijay Balani is a Principal Architect at KPIT. Vijay is focused on the Software-Defined Vehicle Middleware platform, In-vehicle Software Democratization, Connected Vehicle Cloud/Edge platform and CASE (Connected, Autonomous, Shared, Electric) driven mobility/automotive ecosystem and architecture transformation. Outside of work, Vijay enjoys spending time with family, reading books, cooking/eating healthy food, travel, trekking and paragliding.