How to control distributed energy resources using AWS IoT

Controllable distributed energy resources (DERs) are key to the successful transition to a zero-carbon grid.

Industry context

Distributed energy resources (DERs) are controllable energy assets that can generate, store, or consume energy. Examples of DERs are thermostats, heat pumps, batteries, boilers, electric vehicles (EVs), smart inverters, and so on. The ability to control DERs plays an important role in grid stability and achieving zero-carbon goals in addition to offering end consumers benefits, such as rebates offered by utilities.

To provide a tangible example, let’s pick heat pumps. Heat pump sales increased by more than 13 percent globally in 2021 and by 11 percent in 2022 with markets like France, Italy, and Germany leading at 40 percent^[1]. Though electrification of heating helps reduce greenhouse gas (GHG) emissions, it also puts pressure on the grid by having to deal with surges in demand for power, which adds to a utility’s need to use carbon-emitting peaker plants to supply additional power. But what if the thermostats associated with heat pumps were controllable by the utility? Utilities could lower the dependence on peaker plants by controlling heat pumps to temporarily distribute or reduce their energy consumption.

Such control of DERs is often referred to as demand-response programs that are initiated when a peak load event is detected. In order to achieve this, manufacturers need to build thermostats that can be controlled remotely by them or third-party service providers using secure, reliable, and scalable APIs. The following sections will demonstrate how Amazon Web Services (AWS) solutions from AWS IoT, services and solutions to connect and manage billions of devices, can provide ready-to-use capabilities to help utilities control, manage, and secure thermostats at scale.

In this blog, we show how manufacturers of DERs can use Internet of Things (IoT) solutions from AWS to simplify and accelerate the development of controllable devices that are secure, reliable, and scalable. Even though we use thermostats as an example, the concepts are applicable for all DERs, such as EVs, inverters, batteries, and more.

Deliver DER integration using AWS IoT

Writing software to connect to a thermostat and control it can be complex, expensive, time-consuming, and error prone, but AWS IoT can help speed up the development and reduce the amount of code to maintain. Here’s how:

Edge logic: Our thermostat must be able to receive control requests using simple REST-based APIs and then initiate the logic at the edge using device protocols such as Modbus. With AWS IoT Greengrass—which helps developers to build intelligent IoT devices faster—customers can build, deploy, and update components at the edge directly from the AWS Cloud. Some components are publicly available, but custom components can also be built.

AWS IoT Greengrass provides other capabilities as well, such as a broker at the edge, reliable data streaming, and log propagation. All these functionalities are vetted and ready to use and can help us to create our solution faster while reducing operational overhead.

Device management: To control thermostats at scale, each asset should be registered and managed. AWS IoT Device Management—which helps you register, organize, monitor, and remotely manage IoT devices at scale—provides the capability to register, group, and search devices according to their properties. The data model is flexible, and devices can be registered with any number of properties, such as vendor, size, and model, but also custom ones, such as customer city, postal code, or state. Once populated, this inventory can then be used to search for single devices or groups of devices. This is particularly useful when addressing large numbers of thermostats—for example, to control all thermostats within a certain city, postal code, or geographic region.

Security: Each thermostat needs to securely connect to the cloud, send data, and receive commands.

Because of AWS IoT Core—which lets you connect millions of IoT devices and route their messages to AWS services—each IoT device or gateway is equipped with a X.509 security certificate that is used to authenticate and authorize each action performed by the device so that, after the device is identified, a set of permissions associated to that certificate is enforced. With AWS Identity and Access Management (IAM) you can set fine grained permissions on who or what system can access your devices. Using AWS IAM and the AWS IoT Core provided x.509 certificates you can establish a zero-trust environment for your devices.

Customers can also rely on AWS IoT Device Defender—which provides security management across your IoT devices and fleets—to improve their security posture. AWS IoT Device Defender is designed to take care of the monitoring and alerting of security risks around all AWS IoT Core devices. For a deep dive on IoT security, please read Security on AWS IoT.

DER control: One of the most critical capabilities is to reliably control all thermostats registered in the system. Controlling assets that are distributed and without a stable network connection is challenging and requires the implementation of a complex solution. Because of AWS IoT Shadow, AWS customers can rely on a vetted and ready-to-use service to cover this use case.

The AWS IoT Device Shadow service adds shadows to each AWS IoT “thing,” or in this case, each thermostat. A shadow is a device’s state availability to apps and other services, whether the device is connected to AWS IoT or not. Each shadow can be modified either by the device or by the application, and the changes are automatically propagated to the other end; if the change is not confirmed, updates will be retried. We will detail how this technology helps in controlling thermostats later in the blog.

Observability: Having the possibility to track the status of each thermostat and quickly troubleshoot availability problems is a key operational requirement to participate in demand-response programs. Because of AWS IoT, customers can ingest near-real-time performance and device status information directly into the cloud. AWS IoT also provides connectivity tracking events for every IoT device called lifecycle events (device connection, disconnection, command initiation, and more). Both device status and events can then be sent using AWS IoT Rules toward business control rooms, where operators can quickly react to any DER issue.

In case of complex logic and correlations with other data sources, AWS customers can also send data to AWS IoT Events, which delivers near-real-time event analysis against predefined if-then-else statements.

Finally, to perform analytics and extract machine learning (ML)-driven insights, customers can use AWS IoT Analytics, which can filter, transform, and enrich IoT data.

AWS IoT in action

Let’s go ahead and put into practice what we’ve learned so far. As we said, our objective is to control heat pumps to influence the balancing of the grid or monetize their aggregated capacity on the market. This is possible by centrally aggregating and controlling a large number of thermostats associated with the heat pumps.

It is fair to make the assumption that building owners are empowered to change the temperature of their thermostats anytime they want and that our solution should be able to identify these manual changes, resulting in the removal of the thermostat from the specific demand-response event. This capability requires an application that handles the status of all thermostats and reliably controls them from the cloud while accounting for manual adjustments by individual users.

Let’s see how AWS IoT technology can help implement this use case. First of all, let’s review the high-level architecture for this example.

Figure 1. High-level solution

In this example, the thermostat uses AWS IoT Greengrass to connect to the AWS Cloud over transport layer security (TLS) and to the thermostat’s controller chip through Modbus. AWS IoT Greengrass implements a modular approach, encapsulating each functionality in an edge component. All the deployed edge components are then able to communicate between them through a local messaging broker.

AWS already provides a set of prebuilt and publicly available components as building blocks to implement IoT edge use cases. For this example, the main AWS-provided components are:

• Shadow Manager: This component is responsible for synchronizing AWS IoT Core shadow documents with AWS IoT Greengrass local shadows. Shadow manager maintains a persistent shadow at the edge, subscribes to the AWS IoT Shadow topics using MQTT, and synchronizes any change between edge and cloud shadows.
• Modbus TCP: This component is an adapter responsible for converting local AWS IoT Greengrass requests to Modbus TCP commands. It uses the internal broker to communicate with other components by receiving commands and delivering responses.

To complete the edge logic, we need to convert all shadow changes into local commands and handle eventual manual thermostat changes from the user. In this case, both responsibilities are assigned to a private (custom) component called Modbus Controller.

In this example, the thermostat is an instance on Amazon Elastic Compute Cloud (Amazon EC2), which offers secure and resizable compute capacity for virtually any workload , running AWS IoT Greengrass performing the actuation against a Modbus simulator (Modbus server). You can easily use a Raspberry Pi or similar device instead of an Amazon EC2 instance.

Figure 2. Sample code solution

Thermostat control

To reduce the amount of custom code to develop and maintain, we will use AWS IoT Shadow documents to track the status of the thermostat. The solution will interact with the shadow from the cloud or from the edge while AWS IoT takes care of the synchronization.

There are two main shadow documents managed by AWS IoT Core, Reported and Desired. The first one describes the actual state of the device; the second, the target state that we want to achieve. It’s possible to input a status change by modifying the Desired state through MQTT, REST APIs, or manually in the AWS console.

When an application or a user changes the desired state in the cloud, AWS IoT will automatically push a document to the gateway providing information about what has changed. If the device is not connected with the cloud or is not available, the change remains pending as Desired until the device is back online and can process the request.

As soon as the gateway receives the new desired state, it will operate the changes by sending a message to the Mobdus TCP, initiating the actual command. Finally, after the new parameters are accepted by the thermostat, the gateway will publish a new Reported state back to the AWS IoT Cloud; this final message functions as a confirmation of the success of the control operation, closing the transaction.

User manual control monitoring

Manual changes to the thermostat made by a user can be handled locally using an AWS IoT Greengrass custom component using ready-to-use features to speed up application development. This component will be responsible to monitor the thermostat status against its shadow in AWS IoT.

Let’s say that the thermostat can operate in manual or auto mode. When in auto mode, the demand-response program is managing the target temperature versus in manual mode, when the user has the full control. When the thermostat is in auto mode, the component will check whether the demand-response program target temperature is aligned with the actual target temperature. If the check fails and the customer has manually changed the set point, the component will propagate a status change from auto to manual using AWS IoT Shadows.

Because of AWS IoT Core, it’s then possible to capture this status transition using a simple SQL query. Every time the query matches, we can initiate an action, like sending a notification to an email or an application.

In figure 3, you can find a sequence diagram that recaps all interactions among the components that we described. The first section shows how a shadow change gets propagated across all the actors. It starts from the desired state change request up until the actual Modbus command and all the way back for the related shadow change confirmation. In the second section, you can note how the gateway is periodically reading the status of the thermostat, checking if the customer has changed their set point manually. As soon as a misalignment is detected, the status is modified and the notification is initiated.

Figure 3. Sample code demo sequence

If you want to build the example in your AWS account, follow the instructions reported in the README section of this GitHub repo.

Conclusions

DERs are pivotal to facilitate the energy transition because they provide the required flexibility to counterbalance the changes in the electricity markets because of the changing demand and energy mix.

Utilities are looking for solutions that can aggregate and control those assets reliably at scale. The challenge is to design and build such systems while keeping the up-front and operating costs as low as possible. AWS offers services that can greatly reduce the time to market and the operational burdens of a custom solution. In this blog, we have explored how the AWS IoT suite delivers capabilities to operate, monitor, and control DERs at scale using a practical example.

If you have ideas or feedback, please reach out to us or leave a comment. To learn more about how you can transform the core and build the future of your energy business, visit AWS for Energy.