AWS for Industries

Advancing connected vehicles through Automotive Edge and LEAF on AWS: Part 2

Automotive companies such as OEMs, Tier 1 suppliers, and fleet owners encounter unique challenges in their connected software development and distribution. These challenges include the time-consuming nature of hardware-dependent testing, the high complexity and cost associated with over-the-air (OTA) solutions, and difficulties in sourcing a skilled workforce due to the industry-specific niche of in-vehicle software technologies.

The DXC Luxoft Edge Acceleration Framework (LEAF) solution allows development of edge software and deployment in the form of containers to a selected set of devices using OTA capabilities. The portal has visibility of inventory edge devices to effectively manage them. This combination of a development platform with OTA capabilities and the edge container runtime environment provides for comprehensive functionality that encompasses in-vehicle/edge software development, testing, deployment, inventory and orchestration. The full solution design uses a range of AWS services catering to in-vehicle setups that stem from client choices.

Part 1 of this series describes the automotive edge concept and explains how the DXC Luxoft Edge Acceleration Framework (LEAF) is designed to manage edge workloads and overcome some of the common challenges of connected vehicles.

In this article, we’ll look at the LEAF solution in detail, including detailed architecture, solution functionality and customer benefits.

Minimal Value Product (MVP)

The LEAF solution is represented by its MVP version, which consists of the following components:

  1. Lightweight IoT Stack
  2. Edge Applications Management
  3. Development Platform
  4. Virtual Vehicles
  5. Telemetry Generator — edge application sample

The MVP of the solution serves as a vital tool for OEMs to explore the solution’s capabilities and test functionalities, allowing the OEMs to make informed decisions about potential production implementations of LEAF. By providing a glimpse into the features and benefits of the solution, the MVP enables OEMs to assess its suitability for their specific needs and requirements. During the solution exploration, users can interact with the solution, experiment with different settings, and simulate real-world scenarios to gauge its performance and effectiveness. This hands-on experience not only helps understand the solution’s capabilities, but also allows them to identify potential limitations or areas for improvement. Armed with this knowledge, OEMs can make well-informed decisions about whether to proceed with the production implementation of the solution, ensuring that it aligns with their business objectives and delivers the expected value. Ultimately, the MVP serves as a valuable steppingstone in the journey toward adopting new technologies and solutions, automakers to make confident and informed choices.

Solution architecture

The following diagram illustrates the high level design of the solution.

Figure 1: LEAF solution high level architecture design

Figure 1: LEAF solution high level architecture design

Let’s look at the individual components in more detail:

1. Lightweight IoT Stack
The IoT stack is a combination of a device operating system, a workload runtime, and IoT cloud services, which together provide unified mechanisms for communication between devices and the cloud, as well as for running applications hosted on the device. The stack consists of the following components:

  • Yocto Linux Image and EWAOL: The Edge Workload Abstraction and Orchestration Layer (EWAOL) provides a framework for deploying and orchestrating applications on edge platforms using the Yocto Linux project. This image includes a preinstalled Docker container runtime and an IoT agent. Alternatively, a plain Ubuntu image can be used
  • IoT agent: A Linux service that connects and authenticates with AWS IoT Core. It receives deployment and update instructions by subscribing to an IoT topic and executes update/deployment commands in the container environment
  • Container runtime: A standard Docker runtime environment for edge workloads
  • AWS IoT core: A managed cloud service that securely connects devices to the cloud, enabling communication with Amazon products/services and other cloud applications. AWS IoT Core supports the MQTT protocol, allowing connected devices to send, read, and process data in real-time based on OEM’s requirements
  • Amazon S3: A repository based on AWS S3, containing edge workload artifacts

2. Edge Application Management
The Edge Application Management (EAM) system facilitates the deployment and updating of edge applications across a group of devices through campaign management. It also provides the capability to retrieve software inventory for each connected edge device. The Edge Application Management system consists of the following components:

  • Applications Management Portal: A web application and interface that manages deployment and update campaigns, vehicle groups, and displays information about available components and versions. The following information can be obtained from the service APIs and reflected on the portal:
    • A list of campaigns, where each campaign definition includes the EDGE component (package) with its version and the group of vehicles where the component is to be deployed or updated
    • Campaign status
    • A list of packages and their versions available for deployment
    • A list of vehicles available for component deployment or update
    • Inventory: A list of components and versions installed on each vehicle or device
    • Inventory history: A record of the installation history of components and versions on each vehicle or device
  • Vehicle Groups Management: A service that exposes an API for managing vehicle groups and filters
  • Vehicle Management: A service that exposes an API for accessing vehicles registered in the system and available for component deployment or update
  • Campaign Management: A service that exposes an API for managing and executing deployment or update campaigns

3. Development Platform
The LEAF serves as the development environment, providing tools for automotive software developers to code, build, deploy, test, and publish artifacts for edge applications. The platform consists of the following components:

  • Code Repository: This service stores the edge application code, including a sample for telemetry data generation
  • Static Code Analysis Step (AWS CodeBuild): This step runs unit tests and performs static code analysis using SonarQube
  • Build Step (AWS CodeBuild): As part of the CI pipeline, this step compiles the source code and produces container images and software packages. The build step pushes the container image into Amazon Elastic Container Registry (ECR) for later use
  • AWS ECR: Elastic Container Registry is a secure container image registry service that supports private repositories with resource-based permissions managed by AWS Identity and Access Management (IAM). Within the development platform, it holds container images. These images are pulled from Amazon ECR by the test step for deployment into a test environment and by the publish step for publishing an application package
  • Virtual Test Environment: An Amazon EC2 instance that represents the virtual testing device
  • Test Step (AWS CodeBuild): A step in AWS CodePipeline that provides test automation. It deploys the Amazon EC2 instance as a testing device, deploys the application to this testing device, and runs tests in the virtual test environment
  • Publish Step (AWS CodeBuild): A step in CodePipeline for the automated publishing of tested artifacts. It publishes components to the component repository
  • Pipeline (AWS CodePipeline): A continuous integration pipeline that builds, deploys, tests, and publishes EDGE components (applications). The pipeline automates all the steps required to continuously release software changes

4. Virtual vehicles

The LEAF MVP includes virtual vehicles deployed as Amazon EC2 instances, they can be used by automakers as a virtual fleet for edge application deployment, testing and verification. Secure Shell (SSH) connection can be established to the instances for troubleshooting and local logs or metrics investigation.

5. Telemetry generator (application sample)

The telemetry generator application is written in python and provided in the solution MVP as an example of the workload which can be deployed and updated on the devices. It simulates a telemetry collector application. For the sake of simplicity, the sample dumps telemetry into the local file instead of streaming it to the cloud. There are two versions of the application code: 1.0.0 and 1.0.1 stored in different branches of the code repository. The initial version generates speed and odometer values, while the updated version additionally generates fuel level values. The CI/CD pipeline provided with the MVP is tailored specifically for this application to demonstrate the capabilities of the solution.

Infrastructure components and data flows

In this section we provide the architecture diagram of the LEAF infrastructure and consider basic workflow and data flows.

The following diagram illustrates the architecture of the solution:

Figure 2 LEAF solution detailed architecture designFigure 2: LEAF solution detailed architecture design

Key AWS services used

Applications development workflow

In the application development process (blue arrows), automotive software developers begin by committing and pushing their code to the code repository, followed by the creation of a pull request to the main branch. The pull request “merge” action triggers AWS CodePipeline, which orchestrates the subsequent steps. Initially, the code is built using AWS CodeBuild, where it undergoes static code analysis and unit tests to ensure quality and functionality. Following these checks, the container image is built and pushed to the Amazon ECR, ready for deployment in the test environment. The tests are executed on virtual vehicles represented by Graviton-based Amazon EC2 instances to validate the application in a simulated environment. Once these tests are successfully completed, the container image is zipped, uploaded to an Amazon S3 bucket and ready for deployment to devices.

Application deployment flow
Below is the application deployment flow:

  • In the edge applications deployment process (green arrows), users initiate and execute deployment campaigns through the web portal. They access the portal via Amazon CloudFront, where Cognito manages user authentication to ensure secure access. Once authenticated, the Amazon API Gateway handles their API requests, directing them to the appropriate backend services
  • On the backend, the Application Load Balancer distributes incoming requests to Amazon Elastic Container Service (ECS) instances. The LEAF backend processes these API requests and interacts with the PostgreSQL database to manage the campaign data, ensuring that all operations are smoothly executed, and data is accurately maintained. Additionally, the backend sends messages to the vehicles via IoT Core topic, notifying them of the necessity to deploy the package. The backend also provides a pre-signed URL to the package that has been published to the Amazon S3 bucket during the development process
  • Upon receiving this message, the IoT agent downloads the package, unpacks the container image, and runs the deployment or update procedure, ensuring that all operations are smoothly executed, and data is accurately maintained
  • Once the deployment or update operation is complete, the IoT agehttps://d2908q01vomqb2.cloudfront.net/c5b76da3e608d34edb07244cd9b875ee86906328/2024/11/18/Figure-3-Applications-Management-Web-Portal-—-Packages.pngnt sends back the status via a dedicated IoT topic. This status is processed by an IoT rule and submitted to the backend database via the REST API, ensuring that the backend has the latest information on the deployment status

Inventory data flow
In the inventory management process (yellow arrows), IoT agents play a crucial role by collecting data from vehicles and sending the inventory data to the IoT Core topic. This incoming data is then processed by the Inventory Processor, an AWS Lambda function, which updates the relevant Amazon DynamoDB table. As changes occur, the Inventory Update Stream activates the Inventory History Processor, another AWS Lambda function, which updates the historical data in Amazon DynamoDB, ensuring that all records are current and accurately maintained.

End-to-end solution walkthrough

The end-to-end solution walkthrough showcases the essential capabilities of the solution, demonstrating the comprehensive workflow of edge application development, testing, deployment and updating.

Walking through the steps provided below, we will demonstrate how the telemetry generator application sample can be updated from version 1.0.0. to version 1.0.1 on a fleet of virtual vehicles. This creates a new version with the added functionality of fuel level generation — in addition to the odometer and speed values which existed in the initial version.

  • Deployment

First, we will access the solution web portal, log in with the user account created during deployment, and ensure the telemetry package version 1.0.0 is available in the Packages menu.

Figure 3 Applications Management Web Portal — Packages

Figure 3: Applications Management Web Portal — Packages

Next, we need to create a vehicle group of virtual vehicles in the Vehicle Groups menu, using, for example, the VIN filter. VINs of the virtual vehicles are pre-defined in the configuration.

On the Campaigns page, we can now create a campaign specifying the vehicle group, the telemetry package and a priority, and execute the campaign. The status of the campaign can be tracked on the campaign page.

Figure 4 Applications Management Web Portal — New Campaign

Figure 4: Applications Management Web Portal — New Campaign

  • Verification

To make sure that the deployment is completed successfully, and the telemetry application is running, we can connect to the virtual vehicles via SSH using the SSH keys, usernames and IP addresses available in the output of the solution deployment operation. Using the command watch -n 1 tail -1 /telemetry/telem.txt allows us to monitor changes in the telemetry application output. After the deployment of version 1.0.0 we will see generated odometer and speed values.

Figure 5 Virtual device console — Telemetry v 1.0.0 output

Figure 5: Virtual device console — Telemetry v 1.0.0 output

  • Development

Next, we create and merge a pull request from the “feature-fuel-level” branch to the main branch, then track the pipeline execution in the AWS CodePipeline console. After that, we log in to the SonarQube web portal to monitor static code analysis results and check functional test results in the AWS CloudWatch console.

  • Update

Finally, we repeat the deployment step for package version 1.0.1, ensuring the “fuel” field appears in the telemetry output and is reflected in the inventory tab for any vehicle in the Vehicles List menu.

Figure 6 Virtual device console — Telemetry v 1.0.1 output

Figure 6: Virtual device console — Telemetry v 1.0.1 output

Figure 7 Applications Management Web Portal — Inventory

Figure 7: Applications Management Web Portal — Inventory

Conclusion

The DXC Luxoft Edge Acceleration Framework (LEAF) is an innovative cloud-based solution that streamlines the entire lifecycle of edge application development for automotive companies, from coding and testing to deployment and management. It simplifies hardware-dependent testing, OTA updates, and enhances operational efficiency, reducing time to market. The LEAF MVP allows OEMs to explore LEAF’s capabilities and test functionalities, and to simulate real-world scenarios, enabling well-informed decisions about production implementation. LEAF’s comprehensive approach, integrating various AWS services, containerization technologies, and DevOps practices, empowers automotive companies to innovate rapidly, reduce costs, and stay competitive in the connected vehicle landscape. It provides a clear roadmap for overcoming industry-specific challenges and driving the future of software-defined vehicles.

Please contact the DXC Connected Mobility team via the DXC website contact form to discuss solution deployment, customization and support.

Leonid Zelentsov

Leonid Zelentsov

Leonid Zelentsov is a global technical lead in the connected mobility practice of the Luxoft Automotive line of business. His expertise and experience lie in the cloud area and cover all major public cloud providers. His role includes automotive business development and support in the area of connected platforms and services. Leonid joined Luxoft in 2007 as a system administrator and made a long journey through various Luxoft divisions and locations to the current position of technical director in Luxoft Automotive USA.

Dhiraj Thakur

Dhiraj Thakur

Dhiraj Thakur is a partner solutions architect at AWS. He works with our partners and customers to provide technical guidance for the best outcome of workloads on AWS. He is passionate about technology.

Thomas Kraus

Thomas Kraus

Thomas Kraus is solutions director on the Connected Vehicle Platforms team at Luxoft. He brings a robust 15-year track record in the automotive industry, where he has honed his expertise in connected vehicle technologies. At the helm of the Center of Competence for Connected Vehicle Platforms, he is instrumental in defining the direction for Luxoft's connected mobility cloud solutions.