Building an Over-the-Air Software Updater for the Automotive Industry Using AWS

By Dhiraj Thakur, Sr. Solutions Architect – AWS
By Abhirup Bhowmik, Sr. Software Developer – Luxoft, a DXC Technology Company
By Amod Mulay, Solutions Director – Luxoft, a DXC Technology Company

DXC Technology

Luxoft, a DXC Technology Company, is a digital strategy and software engineering firm that helps clients harness the power of innovation.

Many car manufacturing companies, for example, are looking to install, update, and re-install software for their cars, trucks, and buses over-the-air (OTA) so that customers can have a hassle-free experience.

Luxoft created an OTA update solution reference on Amazon Web Services (AWS) using microservice architecture. This helps manufacturers deliver new features, fixes, and upgrades to in-vehicle software while providing customers the flexibility of choosing the time and features without going to a dealership or workshop in person.

In this post, we’ll discuss how Luxoft analyzed the automotive industry’s common problems, the challenges manufacturers face, and possible ways to address them through a cloud-based solution architecture to update vehicles in any part of the world. We shall also discuss several functional use cases and demonstrate the benefits of Luxoft’s design and implementation approach.

DXC Technology is an AWS Premier Tier Services Partner and Managed Service Provider (MSP) with over 4,000 AWS certified resources to help customers harness the power of innovation and drive their business transformations.

Challenges and Problem Statement

When it comes to software release cycles, most of the automotive world is still living in the past where a simple bugfix or feature update takes months rather than days.

The situation is made even worse when the software is outsourced to another company. Some original equipment manufacturers (OEMs) take six months to release a feature, as the embedded development practices have not changed for decades.

Because of this, the industry is bogged down and faces some hurdles:

Long release cycles prevent fast innovation.
Single, giant monolithic releases can be error-prone and time consuming.
Stale, outdated devices can be insecure and vulnerable to attack.
Inability to quickly add new features.

Solution Architecture

One of the easiest ways to modularize a system is with the use of containers. With containers, an application can be divided into self-contained components or firmware, allowing you to:

Manage the dependencies independently.
Deploy updates and new features in modules while retaining functions of a legacy application.
Avoid shut down of vehicle during software upgrades and bugfixes.

Container-based Electronic Car Unit (ECU) software can provide a standardized platform to facilitate software updates. The architecture below uses AWS to implement this solution.

Figure 1 – Solution architecture.

The following AWS services are used in the above diagram:

Amazon CloudFront: For deploying the frontend, built-in Angular, giving high performance, security, redirection, and developer maintenance.
Amazon API Gateway: For creating, publishing, maintaining, monitoring, and securing REST endpoints.
Application Load Balancer: To receive traffic and forward it to the backend container, which is in a private subnet.
Amazon ECS: For hosting or deploying backend application as a Docker container in a cluster.
Amazon RDS for PostgreSQL: To set up, operate, and scale a relational database in the cloud used by the backend.
Amazon S3: For storing packages to be installed in vehicles.
Amazon EC2: For creating virtual vehicles.
AWS IoT Core: For securely communicating with remote devices (virtual vehicles) which are hosted as EC2 instances in the cloud
AWS IoT Rules: To listen for specific MQTT messages from vehicles, format the data in the message payloads, and invoke a backend endpoint with the result.
Amazon VPC: For hosting the backend and virtual vehicles in two isolated virtual secured networks.
Amazon Cognito: For identity and access management.

Vehicle Lifecycle

The lifecycle of a vehicle starts from provisioning it with a name, unique Vehicle Identification Number (VIN), and type (car, bus, truck). Several vehicles can be grouped into a single or multiple vehicle group which can be used during execution of a campaign.

Campaigns are a logical representation of installing or updating new software or features to single or multiple vehicles. Multiple campaigns can be created involving multiple vehicle groups by the system admin, which can be executed in vehicles as intended.

Admin Dashboard

The solution’s admin dashboard includes various widgets and tools which allow the administrator to manage the OTA system. It provides information about the system’s performance and health, including information about the amount of software, campaigns, vehicles, and vehicle groups registered in the system.

Figure 2 – Admin dashboard.

Information Flow

The following use case diagram shows the flow of information using several AWS services.

Figure 3 – Application flow diagram.

The below REST API endpoints (Figure 4) are exposed by the central system for performing seamless flow of information as explained above (Figure 3).

Figure 4 – Central system REST API.

Vehicle

The updater service which is running inside every vehicle establishes a secure two-way communication between the central system with the help of AWS IoT Core.

When a campaign is executed, the central system sends a sample message to a dedicated MQTT topic for each vehicle (example: cmd/vehicle/WBAFR9C59BC270614/update/available/high).

{
    "campaignId": "bfa35914-b1a2-4df1-8bd2-35fc2ad16fbb",
    "campaignName": "Extra Boost",
    "executionId": "5168706c-6e7f-490d-a77e-625907e5738f",
    "priority": "HIGH",
    "updatePackageURI": "https://bucket.amazonaws.com/update_package_extra_boost.zip",
    "releaseNotesURI": "https://bucket.amazonaws.com/release_notes_extra_boost.json"
}

Once the vehicle receives the message, the Updater Service will download the package stored in the Amazon S3 bucket, unpack, install, and run the Docker containers inside the vehicles based on an Update Instruction file present inside the package (example: extra_boost.zip).

{
    "componentUpdates": [
        {
            "componentId": "acTemperature",
            "updateType": "docker_container_install",
            "resource": "/acTemperature/temperature_component_1.0.0.tar",
            "swVersion": "v1"
        },
        {
            "componentId": "velocity",
            "updateType": "docker_container_install",
            "resource": "/velocity/velocity_component_1.0.0.tar",
            "swVersion": "v1"
        }
    ]
}

Figure 5 – Sample update instruction file.

The vehicle undergoes the below states and installs the update received or rolls back to its previous state in the case of failure.

Figure 6 – Vehicle states.

Based on the installation result, the Updater Application reports back status to another dedicated MQTT topic (example: dt/vehicle/WBAFR9C59BC270614/update/report/success).

{
    "vin": "WBAFR9C59BC270614",
    "campaignId": "bfa35914-b1a2-4df1-8bd2-35fc2ad16fbb",
    "executionId": "5168706c-6e7f-490d-a77e-625907e5738f",
    "startTime": "2022-09-08T15:59:46.920790900",
    "endTime": "2022-09-08T15:59:47.549840600",
    "report": "Campaign extra boost was executed successfully"
}

An AWS IoT Rule is configured, which listens for MQTT messages from vehicles, formats the data in the message payloads, and invokes an HTTP endpoint with the result.

Automotive Industry Use Cases

When it comes to software release cycles in the automotive industry, there can be a lot of use cases or scenarios for bug fixes and feature updates.

Initial Setup

When a vehicle is in a factory and is clean, software or packages can be installed as a part of the initial setup. When the campaign is successfully installed in a vehicle, the velocity and temperature sensors start emitting data with their current versions.

Figure 7 – Initial setup.

Harbour

When a vehicle has left the factory, it’s shipped to a country. OEMs need to adhere to the country’s data security policies and language specifications for running business.

To adhere to the rules and regulations, a specific version of the Updater Service can be installed in the vehicle which ensures the vehicle (although produced some time ago) is up to date with the latest software when it is delivered to a customer

Dealership

When a vehicle is sold to a customer, the flexible update mechanism gives the dealer the option of subsequently activating functions (such as massage seat functionality) that was not activated initially.

Customer Maintenance

Every vehicle goes through maintenance in its lifecycle. During maintenance, bugs are fixed, software is updated, and new features are added. The version of the temperature sensor can be updated to 2.0 from 1.0 in this case.

Customer Function on Demand

Functions or features can be installed or removed in any specific vehicle as demanded by a customer. If a customer wants to have an extra boost functionality for a day (like if it’s a track day), it can be installed on the vehicle as requested by the customer. Once the track day is over, the extra boost functionality will be removed from the vehicle.

Benefits

Containerization and modularization provide a standardized environment that can facilitate automotive embedded software updates. Once validated, new container images can be checked within a sandbox area of the vehicle’s automotive electrical/electronic architecture before deploying them to vehicles.

This ensures the updated system is safe and there is continuity of service to promote efficiency. A layered design boosts image download speed and minimizes the overall image footprint and storage requirements.

Listed below are the outcomes of using containerization and modularization:

Flexibility to use any programming language.
Opens the embedded world to fast-paced release cycles, resulting in lower costs.
Helps in market competitiveness, and has possibilities to integrate multiple service ecosystems during post production.
Customers will benefit from quick bug fixes.
Customers can add features after purchase of vehicle.
Customers can get the latest version of software without visiting a workshop.

Conclusion

In this post, we showed how to install software, fix issues, and roll out important updates that can be tailored for a single or multiple number of vehicles in any part of the world using Luxoft’s cloud solution.

Through AWS managed services, Luxoft, a DXC Technology company, was able to utilize an approach that changed all layers of the solution in a controlled, planned, and tested way. The solution is based on AWS best practices and companies will be positioned to use it as a blueprint to undertake software upgrades with increased agility.

.

.

DXC Technology – AWS Partner Spotlight

DXC Technology is an AWS Premier Tier Services Partner that understands the complexities of migrating workloads to AWS in large-scale environments, and the skills needed for success.

Contact DXC Technology | Partner Overview | AWS Marketplace | Case Studies

AWS Partner Network (APN) Blog