Building an EV Battery Monitoring solution with AWS IoT FleetWise (Part 2)
Automakers, fleet operators, and automotive suppliers are recognizing the potential of vehicle data to transform their business models and optimize their operations. However, implementing data-driven use cases is often challenging. Proprietary vehicle data formats, high costs of data ingestion and implementation complexity can slow down innovation.
AWS IoT FleetWise is a service that makes it easier for automakers to collect, transform, and transfer vehicle data to the cloud. Once transferred, customers can use breadth and depth of AWS analytics and machine learning services to extract value from the vehicle data. If you have no previous experience with AWS IoT FleetWise, please consider starting with the blog Generating insights from vehicle data with AWS IoT FleetWise. You will learn about use cases, technical capabilities, and a logical architecture for AWS IoT FleetWise. In the same blog, we also introduced an Electric Vehicle (EV) battery monitoring solution.
This post will walk you through building that EV battery monitoring solution with AWS IoT FleetWise. First, you will deploy an EV simulation on an Amazon Elastic Compute Cloud (Amazon EC2) instance in your AWS account. Then, you will configure AWS IoT FleetWise to collect, transform, transfer, and store the CAN bus signals from the vehicle. Finally, you will query the collected data using the Amazon Timestream service.
Lithium-ion batteries (LiBs) are widely used as energy storage systems for EVs. When operating EV fleets, continuous monitoring and protection of battery cells is an important consideration.
For EV manufacturers and fleet operators, the ability to detect and predict battery issues such as overcurrent, overcharge or overheating is crucial. For example, it can improve efficiency and safety of fleet operations by enabling timely planning for battery replacement. Another example is that it allows EV manufacturers to collaborate with battery suppliers on battery improvement initiatives, by evaluating the conditions of the battery in different scenarios.
The purpose of this blog is to demonstrate how you can use AWS IoT FleetWise to collect and transfer BMS parameters to the cloud. For that purpose, we will use an example of overcurrent detection use-case. After the data is transferred, it will be stored in a database, ready to be used for monitoring, alarming and ML model traning.
The following diagram shows the architecture of the solution. We also indicate the scope of this blog post, that we will implement following the step-by-step walkthrough. The remaining part of the architecture will be covered in part 2 of this blog series.
Please refer to the previous part of this blog series for a detailed description of the solution architecture.
The following sample implementation utilizes two vehicles and two data collection campaigns.
The vehicles will be simulated by one Amazon EC2 instance each. The EC2 instance will run a script generating CAN bus messages to simulate BMS. Both vehicles will intentionally use slightly different CAN signal encodings to demonstrate the ability of AWS IoT FleetWise to provide unified access to heterogeneous vehicle fleets.
Side remark: the vehicle simulation can be easily adopted to reproduce any previously recorded CAN or OBD-II signals on a simulated environment. This can be useful in a prototyping phase of solutions based on AWS IoT FleetWise. For example, you could record CAN data from your vehicles using the tool of your choice. Once recorded, you could replay the vehicle data on a simulated environment for AWS IoT FleetWise testing. You can learn more about simulating your own vehicle data in the GitHub repository.
Data collection campaigns
To learn how to configure the data collection features of AWS IoT FleetWise, you will set up two data collection campaigns:
- A data collection campaign for continuous, low frequency (1 second sampling rate) monitoring of EV battery pack current and battery cell temperature. For the sake of simplicity, we will include only one single battery cell in our example.
- A conditional data collection campaign to collect a high-resolution (50 ms sampling rate) snapshot of multiple Battery Management System (BMS) signals. This campaign will only collect data under condition that the shunt current (represented by the signal
EVBatterySample.BMS.BatteryPack01.ShuntPlusCurrent_a) is above 450 amperes, i.e. in overcurrent scenario.
Introducing the AWS IoT FleetWise logical data model
To deploy a solution based on AWS IoT FleetWise, you will configure data collection, transformation, and transfer from your vehicle fleet. AWS IoT FleetWise provides APIs to achieve that. You can invoke these APIs by using the AWS Management Console, AWS SDKs, or AWS CLI.
Most of the APIs you will use in this blog follow the CRUD (Create, Read Update, Delete) paradigm. For example, you can use the API action CreateCampaign to configure a new data collection campaign, or UpdateCampaign to change the status of the campaign.
The CRUD operations refer to the following key elements of the logical data model of AWS IoT FleetWise: Signal Catalog, Vehicle Model, Campaign, Vehicle, Fleet and DecoderManifest. The following diagram introduces these elements and explains their relationships:
Please follow the guidelines in this blog to learn how to create each of these data model elements using the AWS IoT FleetWise APIs.
In this blog you will use AWS CLI to interact with AWS IoT FleetWise APIs. You can also use the AWS IoT FleetWise Management console to manage AWS IoT FleetWise.
Deploying the solution
Open AWS CloudShell
Please click on this link to open AWS CloudShell (a browser-based shell). Please ensure to change your AWS region to one of the regions supported by AWS IoT FleetWise (e.g. Europe Frankfurt or US East Virginia).
Clone the repository
Please clone the GitHub repository with the resources for this blog by running the following commands:
git clone https://github.com/aws-samples/aws-iot-fleetwise-evbatterymonitoring
Create Amazon EC2 keypair
Please run the following command to create and store a new Amazon EC2 keypair. You will use it to establish an SSH connection to an Amazon EC2 instance with vehicle simulation in a later step.
aws ec2 create-key-pair --key-name fleetwiseblogec2key | \ jq -r .KeyMaterial > fleetwiseblogec2key.pem chmod 0600 fleetwiseblogec2key.pem
Deploy a solution for vehicle simulation
In this step, you will deploy an AWS CloudFormation stack to set up the simulation for two vehicles. This stack will provision the required resources in your AWS account.
Deploying this solution may incur costs on your AWS bill, e.g., for Amazon EC2, AWS IoT and Amazon Timestream services. Please remember to remove these resources by deleting the AWS CloudFormation stack to avoid unintended costs. You will find instructions for deleting the stack at the end of this blog.
Please change the directory:
Please deploy the stack.
aws cloudformation deploy \ --template-file simulatedvehicle/ec2simulation/template.yaml \ --stack-name vehiclesimulation --disable-rollback \ --parameter-overrides Ec2KeyPair=fleetwiseblogec2key IoTCoreRegion=$AWS_REGION \ --capabilities "CAPABILITY_NAMED_IAM"
Please continue with the guidelines of this blog while the deployment of AWS CloudFormation stack runs (approx. 20 minutes). If you experience problems with the stack deployment, please consider the troubleshooting guidelines.
You can use “New tab” function in AWS CloudShell “Actions” menu to create a new tab for next steps .
Create AWS CLI input files
To improve the readability of this blog, we will provide input to AWS CLI commands in JSON format. To create these JSON files specialised for your account and region, run the following commands which will do that task for you:
cd ~/aws-iot-fleetwise-evbatterymonitoring/cloud ./prepare_templates.sh cd cli-inputs
Create an AWS IAM role
First, we will create an AWS Identity and Access Management (IAM) role for the AWS IoT FleetWise service with the right permissions to write to the Amazon Timestream database:
aws iam create-role --role-name AWSIoTFleetWiseServiceRole\ --assume-role-policy-document file://1_setup/trustpol.json aws iam create-policy --policy-name AWSIoTFleetwiseIAMUserPolicy \ --policy-document file://1_setup/policy.json aws iam attach-role-policy --cli-input-json file://1_setup/policy_attach.json
Please review the AWS IAM role policy to learn more about the necessary permissions.
Initial AWS IoT FleetWise configuration
In this step, you configure AWS IoT FleetWise with the IAM role you created earlier and the Amazon Timestream database and table names. You need to perform this configuration once for the respective AWS region before you can use AWS IoT FleetWise.
aws iotfleetwise register-account \ --cli-input-json file://1_setup/account_registration.json # Check if registration is successfull aws iotfleetwise get-register-account-status
Create signal catalog
The signal catalog is a definition of standardized vehicle signals. To create a new signal catalog, please run the following command:
aws iotfleetwise create-signal-catalog\ --cli-input-json file://2_signal_catalog/create-signal-catalog.json
Create vehicle model manifest
Let’s review the concept of a vehicle model in AWS IoT FleetWise. The purpose of vehicle model is to enforce consistent data structure across multiple vehicles of the same type, so that you can process data from fleets of vehicles. With AWS IoT FleetWise, we use the term “signal” referring to the vehicle data.
For example, a fleet operator may have a fleet of two vehicles types – EVs and electric scooters. Both EVs and scooters may generate some common data (also called “vehicle signals”). An example for that is “current vehicle speed”. However, the EVs may generate signals which are not applicable for the scooters, for example tire pressure. To differentiate between data schemas for EVs and electric scooter, the fleet operator can create two vehicle models in AWS IoT FleetWise.
The model manifest formally describes the schema of the data to be collected from a specific type of vehicle. Please review the model manifest examples in files vehicle-model1.json and vehicle-model2.json .
Please note that a newly created model manifest must be activated before further use. Once activated, no further changes of the model manifest are possible. To create and activate model manifests for two vehicle models, please run the following commands.
# Model 1 aws iotfleetwise create-model-manifest\ --cli-input-json file://3_model_manifest/vehicle-model1.json aws iotfleetwise update-model-manifest --status ACTIVE --name blog-modelmanifest-01 # Model 2 aws iotfleetwise create-model-manifest\ --cli-input-json file://3_model_manifest/vehicle-model2.json aws iotfleetwise update-model-manifest --status ACTIVE --name blog-modelmanifest-02
Please refer to the CreateModelManifest documentation for details.
Please note that while there is overlap between the signals for both models, some signals are only available for the specific model. For example, “EVBatterySample.BMS.Relay01.Status” is only available for the first model, not the second model. This is to demonstrate how you can model heterogeneous vehicle fleets while providing consistent access to the common signals.
Create decoder manifest
The decoder manifest describes the decoding rules for signals of a particular vehicle. To create and activate decoder manifests, please run the following commands:
# Decoder manifest 1 aws iotfleetwise create-decoder-manifest\ --cli-input-json file://4_decoder_manifest/decoder-manifest1.json aws iotfleetwise update-decoder-manifest --status ACTIVE --name blog-decodermanifest-01 # Decoder manifest 2 aws iotfleetwise create-decoder-manifest\ --cli-input-json file://4_decoder_manifest/decoder-manifest2.json aws iotfleetwise update-decoder-manifest --status ACTIVE --name blog-decodermanifest-02
Please note that encoding for the signal “EVBatterySample.BMS.BatteryPack01.ShuntPlusCurrent_a” is different between the first and the second decoder manifest. This is to demonstrate how AWS IoT FleetWise creates an abstraction of decoding from the vehicle model. This allows you to handle different encodings while providing consistent access to vehicle signals.
Create a vehicle
The vehicle is an instance of a vehicle model, representing a physical vehicle. To create vehicles, please run the following commands:
aws iotfleetwise create-vehicle --cli-input-json file://5_vehicle/vehicle01.json aws iotfleetwise create-vehicle --cli-input-json file://5_vehicle/vehicle02.json
Create a fleet and associate vehicles with the fleet
With AWS IoT FleetWise, you can target a campaign either towards a specific vehicle or a fleet, i.e. a set of vehicles. To create an example fleet and associate both vehicles with the fleet, please run the following commands:
aws iotfleetwise create-fleet --cli-input-json file://6_fleet/fleet.json aws iotfleetwise associate-vehicle-fleet --fleet-id blog-fleet\ --vehicle-name blog-vehicle-01 aws iotfleetwise associate-vehicle-fleet --fleet-id blog-fleet\ --vehicle-name blog-vehicle-02
Initiate data collection campaigns
In this section, you will implement two typical use cases for vehicle data collection. For this purpose, you will create two data collection campaigns.
To initiate a data collection campaign with AWS IoT FleetWise, create a new campaign by calling CreateCampaign API and then approve the campaign calling UpdateCampaign API . By approving the campaign, you instruct AWS IoT FleetWise to send the configuration for data collection campaigns and decoders to the vehicles. Based on this configuration, the AWS IoT FleetWise Edge Agent starts collecting, transforming, and transferring data to the AWS.
Let us take a look at the individual campaigns.
Campaign 1: continuously collect battery pack current and cell temperature
This campaign will use a time-based collection scheme, i.e. the Edge Agent will continuously collect vehicle data and transfer it to the cloud in the specified time period. To create this campaign, please run the following commands:
aws iotfleetwise create-campaign \ --cli-input-json file://7_campaign/continious-monitoring-campaign.json # Please wait 15 seconds before running the next command to allow for campaign creation to complete aws iotfleetwise update-campaign --action APPROVE\ --name continious-monitoring-campaign
You can learn more about this campaign by reviewing continious-monitoring-campaign.
Campaign 2: conditionally collect a high-resolution (50 ms sampling rate) snapshot of multiple Battery Management System (BMS) signals.
An example of a use case for this campaign is the analysis of potential problems with the battery packs of a pre-production vehicle fleet. To perform an analysis, vehicle quality engineers may need a high-resolution snapshot for multiple signals (e.g., temperature development of specific battery cells). However, let us assume that the vehicle engineers are only interested in the data if overcurrent event occurs.
To implement this use case, you will create a campaign with a condition-based collection scheme. The Edge Agent will evaluate an expression that you can define (for example,
$variable.`EVBatterySample.BMS.BatteryPack01.ShuntPlusCurrent_a` > 450.0). Only if this expression evaluates to true does the Edge Agent collect vehicle data and transfer it to the cloud.
To create this campaign, please run the following commands:
aws iotfleetwise create-campaign\ --cli-input-json file://7_campaign/conditional-snapshot-campaign.json # Please wait 15 seconds before running the next command to allow for campaign creation to complete aws iotfleetwise update-campaign --action APPROVE\ --name conditional-snapshot-campaign
You can learn more about this campaign by reviewing conditional-snapshot-campaign.json.
Testing the solution
You have successfully deployed a simulation and configured the AWS IoT FleetWise service. Now it’s time to see the overall solution in action. Please follow the instructions below.
Step 1: Connect to the simulated vehicle
In this step, you will connect to the Amazon EC2 instance that simulates the vehicle. You will then review the output of two software components: Edge Agent and the CAN bus simulation script. Please complete the following steps:
1. Get the output of the stack
aws cloudformation describe-stacks \ --stack-name vehiclesimulation \ --query "Stacks.Outputs[?OutputKey=='Ec2Instance1SSH'].OutputValue" \ --output text
If you see “None” as output, it means that stack deployment has not completed yet. Please retry in few minutes. If you experience problems with the stack deployment, please consider the troubleshooting guidelines.
2. SSH into the Amazon EC2 instance
Please copy and paste the SSH command from the stack output above and run it. When asked if you want to connect to the instance, please confirm with “yes”:
ssh -i ~/fleetwiseblogec2key.pem ubuntu@<Value of Vehicle1EC2PublicIP>
3. View CAN messages
You can exit the output mode using Ctrl-C command.
4. You can view Edge Agent output
sudo journalctl -fu fwe@0
You can safely ignore error message “Failed to receive VIN from Engine ECU”.
Step 2: Review collected vehicle data in Amazon Timestream
In this step, you will review the results of the data collection campaigns stored in the Amazon Timestream table.
1. Open the Amazon Timestream Console
Please navigate to “Amazon Timestream” service in AWS management console or click on this link. Next, select the Query editor menu item.
2. Review vehicle data collected by campaign 1 “Continuously collect battery pack current and cell temperature”
In the text field for the query, enter the following sample query and choose Run :
SELECT time, vehicleName, measure_name, measure_value::double, VehicleVIN FROM "FleetWiseDatabase"."FleetWiseTable" WHERE campaignName = 'continious-monitoring-campaign' AND time between ago(15m) and now() ORDER BY time DESC LIMIT 10
You can now view the collected vehicle data as you see in example below:
In spite of the fact that both vehicles encode the CAN message for the signal
EVBatterySample.BMS.BatteryPack01.ShuntPlusCurrent_a in different ways (see DBC files for vehicle 1 and vehicle 2), you can access and analyze the vehicle data under a uniform name!
3. Review vehicle data collected by campaign 2
Let’s query the statistics of a specific cell temperature. Enter the following query and select Run :
SELECT vehicleName, measure_name, hour(time) as hour, minute(time) as minute, max(measure_value::double) as MaxTemperature, min(measure_value::double) as MinTemperature FROM "FleetWiseDatabase"."FleetWiseTable" WHERE campaignName = 'conditional-snapshot-campaign' AND measure_name = 'EVBatterySample.BMS.BatteryPack01.Cell001.CellTemperature' AND (time between ago(10m) and now()) GROUP by vehicleName, measure_name, hour(time), minute(time) ORDER by vehicleName,hour(time), minute(time)
You can now view the aggregated vehicle data as you see in example below. According to the campaign configuration , the data was transferred only when battery pack shunt current was over 450 amperes. For 19:42 and 19:43, shunt current was below 450 amperes, so no data was transferred.
We suggest to run your own experiments with the vehicle data by following Amazon Timestream Query Language reference guidelines or by creating Amazon Managed Grafana dashboards like below using provided examples:
Please ensure to exit the SSH session to the Amazon EC2 instance before you continue. Please run the following commands in AWS CloudShell to remove the created resources from your AWS account:
aws cloudformation delete-stack --stack-name vehiclesimulation sh ~/aws-iot-fleetwise-evbatterymonitoring/cloud/automation/fleetwise-cleanup.sh
Summary and next steps
You have learned how to use AWS IoT FleetWise to implement the collection, conversion, transmission, and storage of CAN bus signals and how to query these signals using Amazon Timestream. In the next part of this blog series, we will introduce you to how you can use AWS services to analyze stored data.
Visit the AWS IoT FleetWise webpage to learn more.
Geoffrey Phillips (Senior Software Development Engineer) contributed major parts of the AWS CloudFormation template and the CAN Interactive Generator library.
About the authors
Andrei Svirida is Senior Specialist Solutions Architect at Amazon Web Services. He is passionate about enabling companies of all sizes and industries to become data-driven businesses. To that end, he helps AWS customers to architect and build secure and scalable solutions on AWS, focusing on IoT, Analytics and Data Engineering. Prior to joining AWS, Andrei worked at KUKA AG as Head for IoT Delivery and as VP in in-house consulting at Deutsche Telekom AG. Andrei has a computer science background and more then 18 years of industry experience.
Suvendu Rath is Senior Engagement Manager at Amazon Web Services. He is passionate about robust innovation strategies for Automotive customers. He helps AWS customers to run innovation projects from initial brief through to final deliverable, focusing on IoT, AI/ML and Data Engineering. Prior to joining AWS, Suvendu worked as Software Project Lead at BMW AG and as Software Engineer in Automotive/Avionics industry . Suvendu has an Electrical Engineering background and more than 15 years of industry experience in Automotive and Avionics domain.
Katja-Maja Kroedel is IoT Specialist Solution Architect at Amazon Web Services. She works with AWS customers to provide guidance on cloud adoption, migration, and strategy in the area of IoT. She is passionate about technology and enjoys building and experimenting in the cloud with innovative services, such as AWS IoT FleetWise. Katja has a Computer Engineering background and already worked at different roles within AWS, starting with her Masterthesis as well as her role as Generalist Solutions Architect in Germany, helping small- and middle-sized customers grow and learn about the cloud.