Digital Twins on AWS: Understanding “state” with L2 Informative Digital Twins

In our prior blog, we discussed a definition and framework for Digital Twins consistent with how our customers are using Digital Twins in their applications. We defined Digital Twin as “a living digital representation of an individual physical system that is dynamically updated with data to mimic the true structure, state, and behavior of the physical system, to drive business outcomes.” In addition, we described a four-level Digital Twin leveling index, shown in the figure below, to help customers understand their use cases and the technologies needed to achieve the business value they are seeking.

In this blog, we will illustrate how the L2 Informative level describes the state of a physical system by walking through an example of an electric vehicle (EV). You will learn, through the example use cases, about the data, models, technologies, AWS services, and business processes needed to create and support an L2 Informative Digital Twin solution. In our prior blog, we described the L1 Descriptive level, and in future blogs, we will continue with the same EV example to demonstrate L3 Predictive and L4 Living Digital Twins.

L2 Informative Digital Twin

An L2 Digital Twin focuses on describing the state of a physical system by connecting to data streams from the physical system (either directly or via intermediary data storage systems) so that a user can visualize what is presently happening with the system. The visualization can be in the form of well laid out dashboards, or experiential with a full 3D immersive environment. Dashboard monitoring is very common in the IoT world for complex facilities such as power plants and factories and can include simple analytics to trigger alarms. In the industrial world, this is the domain of IoT and Asset Management with integrations with enterprise asset management (EAM) or enterprise resource planning (ERP) systems to show configuration, maintenance history, and upcoming work orders on a single pane of glass. Although common in high-value facilities such as powerplants, we’re seeing customers wanting similar levels of monitoring on lower-value equipment in every day use such as their vehicles. The advancements in low-cost sensors and wireless connectivity is making this a cost-effective opportunity. To illustrate L2 Informative Digital Twins, we will continue our example of the electric vehicle (EV) from the L1 Descriptive Digital Twin blog by focusing on three use cases: 1/ real-time monitoring of a single vehicle with simple alarms, 2/ real-time monitoring of a fleet of vehicles, and 3/ battery degradation monitoring over an extended time period.

1. Single vehicle real time monitoring

For real-time monitoring of our EV, we’ve used the AWS IoT TwinMaker service to connect the 3D representation of the vehicle with data notionally streamed in real-time from the vehicle. This view could, for example, be used by a concerned parent waiting for their teenager to come home late at night to make sure they have sufficient battery charge to make it home safely. An alarm could be triggered and a notification raised if the vehicle battery charge falls below a preset threshold. For the purposes of this example, we generated a synthetic telemetry dataset using the Maplesoft EV model described in the L1 Descriptive blog, however, in the real implementation, it would be streamed data from a live operating vehicle.

In the example below, we see a screenshot of the dashboard created in Grafana using AWS IoT TwinMaker. The solution pulls together 2 different data sources: the synthetic telemetry data from AWS IoT SiteWise, and the maintenance history information and scheduled maintenance from Amazon Timestream.

Because our parent is concerned that their teenager might be stranded out at night, we’ve also set an alarm that is triggered when the battery state of charge (SoC) drops below 25%. SoC is the ratio of the amount of energy left in the battery (in Ampere-hours) compared to the amount of energy in a new fully charged battery (in Ampere-hours). The triggered alarm is shown in the image below. As a note, for real-life EVs, it is recommended to keep the battery charge between 20% and 90% to maintain long-term battery health, and most vehicle software prevents charging beyond 90% capacity (even when the indicator says battery is fully charged).

The solution implementation architecture is shown below. The synthetic data representing real electric vehicle data streams are read in using an AWS Lambda function. The vehicle data including vehicle speed, fluid levels, battery temperature, tire pressure, seatbelt and transmission status, battery charge, and additional parameters are collected and stored using AWS IoT SiteWise. Historical maintenance data and upcoming scheduled maintenance activities are generated in AWS IoT Core and stored in Amazon Timestream. AWS IoT TwinMaker is used to access data from multiple data sources. The time series data stored in AWS IoT SiteWise is accessed through the built-in AWS IoT SiteWise connector, and the maintenance data is accessed via a custom data connector for Timestream. Within AWS IoT TwinMaker, the EV is represented as an entity with subsystems such as the braking system represented by a hierarchy of entities corresponding to the physical assembly of the individual parts. AWS IoT TwinMaker components are used to associate data elements to each of the entities in the hierarchy. The AWS IoT TwinMaker built-in alarm capability is used to set the 25% threshold against the battery charge data component. The visualization is built using Amazon Managed Grafana and interfaces with AWS IoT TwinMaker via the built-in plug-in.

2. Fleet real time monitoring

Extending the EV example from monitoring a single vehicle to managing a fleet of vehicles is a common use case for commercial operations. We’ll examine a fleet of 5 vehicles, with each vehicle driving a different route. The use case here is for the fleet operator to understand the battery SoC and to estimate if the vehicle will be able to complete its route using a very crude calculation. For this example, it is assumed that the SoC of a vehicle battery should not fall below 20% and that each vehicle is discharging at an average rate of 0.23 %/km. The remaining range is then calculated by:

If the calculated Remaining Range is below the Distance Remaining, then an alarm is triggered and the vehicle is flagged with a red color as shown in the Grafana dashboard created below. Note that this example uses a very crude equation that can be incorporated into an L2 Informative Digital Twin IoT system. It has the benefit of simplicity, but greatly lacks accuracy. The next blog focusing on L3 Digital Twins will demonstrate the use of a much more accurate predictive model as a virtual sensor to calculate the remaining range.

As shown in the following architecture diagram, this solution was created using AWS IoT FleetWise, AWS Timestream, and AWS IoT TwinMaker. The synthetic data representing the fleet of electric vehicles including route information, distance remaining, battery charge is ingested in AWS IoT FleetWise using an Edge agent installed on an EC2 instance and stored in Amazon Timestream. The time series data stored in AWS Timestream is accessed through a custom connector in AWS IoT TwinMaker. The visualization is built using Amazon Managed Grafana and interfaces with AWS IoT TwinMaker via the built-in plug-in.

3. Battery degradation monitoring for a fleet

We extended the EV example to another common use case which is monitoring the battery degradation over time for a fleet of vehicles such as a fleet of vans used by a delivery service in a city. Over a several year period, each vehicle in the fleet will have experienced very different drive profiles, as well as battery charging and discharging cycles. As a result, the battery degradation for each vehicle will be different. The use case here is for the fleet operator to understand the battery health of a specific vehicle. In this case, the operator is not interested in watching the real-time battery discharge as the vehicle operates, but rather what is the health of the battery depending on its ability to charge fully (relative to a new battery). Knowing this information enables the operator to allocate the vehicles to the appropriate routes to make sure each vehicle will be able to meet its upcoming routing demands for the next day. This metric is typically called State of Health (SoH) and one way to calculate it is as a percentage of the maximum charge of a new battery. For example, a degraded battery that can only charge up to 94 kWhr (relative to a new battery which can charge to 100 kWhr) would have an SoH of 94%. In the industry today, an EV battery pack is generally considered end of life for EV applications when the SoH drops below 80%. In the dashboard below, we see that the SoH for Vehicle 3 has dropped below 80%, triggering an alarm showing that the vehicle battery has reached effective end-of-life. This dashboard was generated using the same prior solution architecture, this time adding the Battery SoH as one of the parameters shown.

For Vehicle 3, we see that the Battery State of Health has dropped below the 80% end-of-life threshold. Looking at historical data, we’ve plotted the battery discharge curve (e.g., SoC versus time) at different points in the battery life as the vehicle aged. The first line (dark blue) corresponds to a new battery with 100% SoH. The second line corresponds to when the battery was roughly half-way through its useful life at SoH of 89%, and the third line corresponds to the latest route driven with the battery at 78% SoH. The lines show the characteristic of battery degradation where the maximum charge attainable is lower as the vehicle ages. The area under each line represents the battery total capacity, and we also see that the battery total capacity is decreasing as the battery ages. Diving further, the right graph shows the voltage versus time discharge curve for the same routes shown in the middle graph. We see that as the vehicle degrades, the battery is able to maintain the voltage for a certain time, but as the battery degrades, the sudden drop in voltage (representing the battery being fully discharged) occurs sooner and sooner – potentially leaving the vehicle stranded in the middle of its route. Note that this example only shows monitoring of battery degradation as it occurs based on sensor data from the vehicle. In a future blog focusing on L4 Living Digital Twins, we will demonstrate how to predict battery degradation using an updatable model.

Summary

In this blog we described the L2 Descriptive level by walking through the use cases of real-time monitoring of a single vehicle, real-time monitoring of a fleet of vehicles, and monitoring battery degradation over a period of many months for an EV. In our prior blog, we described the L1 Descriptive level, and in future blogs, we will extend the EV example to demonstrate L3 Predictive and L4 Living Digital Twins. At AWS, we’re excited to work with customers as they embark on their Digital Twin journey across all four Digital Twin levels, and encourage you to learn more about our new AWS IoT TwinMaker service on our website.

About the authors

	Dr. Adam Rasheed is the Head of Autonomous Computing at AWS, where he is developing new markets for HPC-ML workflows for autonomous systems. He has 25+ years experience in mid-stage technology development spanning both industrial and digital domains, including 10+ years developing digital twins in the aviation, energy, oil & gas, and renewables industries. Dr. Rasheed obtained his Ph.D. from Caltech where he studied experimental hypervelocity aerothermodynamics (orbital reentry heating). Recognized by MIT Technology Review Magazine as one of the “World’s Top 35 Innovators”, he was also awarded the AIAA Lawrence Sperry Award, an industry award for early career contributions in aeronautics. He has 32+ issued patents and 125+ technical publications relating to industrial analytics, operations optimization, artificial lift, pulse detonation, hypersonics, shock-wave induced mixing, space medicine, and innovation.
	Seibou Gounteni is a Specialist Solutions Architect for IoT at Amazon Web Services (AWS). He helps customers architect, develop, operate scalable and highly innovative solutions using the depth and breadth of AWS platform capabilities to deliver measurable business outcomes. Seibou is an instrumentation engineer with over 10 years experience in digital platforms, smart manufacturing, energy management, industrial automation and IT/OT systems across a diverse range of industries.
	Dr. David Sauerwein is a Data Scientist at AWS Professional Services, where he enables customers on their AI/ML journey on the AWS cloud. David focuses on forecasting, digital twins and quantum computation. He has a PhD in quantum information theory.
	Aditi Gupta is a seasoned technology professional having more than 17 years of experience in management and R&D work developing high performing, scalable and available solutions on-premises and in cloud. She has Masters degrees in Computer Engineering, as well as Business Management. Aditi has been with Amazon Web Services for five years and currently working as IoT Specialist Solutions Architect. She is also an expert in Artificial Intelligence and Big Data. In her role, Aditi advises national governments and enterprises on architecture and cloud services. In the recent years, Aditi has provided architectural advice to large enterprises, government agencies, universities and research agencies in AMER and ASEAN regions.