Smart grid and IOTA — Self balancing grid with smart transformers and smart devices
TL;DR: We built a proof of concept of how a smart grid could autonomously balance itself, by sharing data in a secure way via IOTA and letting devices decide if they want to help balance or not, but if they do they’ll get a small fee in return. This is all done by the system itself, there is no human interaction needed to run the system.
First of all I would like to thank Ton Smets (software development), Klaas van Zuuren (hardware development), ElaadNL and Enexis for making this great proof of concept possible.
Introduction to our vision
In 2017 when we started to develop the Electric Vehicle charger that was solely using IOTA as a payment solution and communication solution, and in beginning 2018 when we created the world’s first IOTA Smart Charging station we already had in mind that this charger was only one part of the vision we had in mind.
A charge station is the first device in our grid that consumes a lot of energy, is connected, and is probably used on a massive scale in the future. For the last decade we tried to use less energy in our homes, but we have to admit that we’ve be using more and more electric energy. Heat pumps, electric cars and other electricity powered devices will only add more to that.
This means that we’ll start using the grid more, and probably reach the limits of our grids. Back in the days when the cables were put in the ground, we weren’t thinking about heat pumps, electric cars and other high power devices that we are going to use today. The challenge is not that we can’t deliver the energy required, but the challenge is that we use that energy all at the same time of the day; usually in the morning around 8 and in the evening around 7. Our grid is not capable of handling that peak demand, and it’s pretty useless to invest lots of money to deal with the peak for let’s say 30 to 60 minutes a day, while we have the technology to spread the energy usage over time.
How could this work in the grid
That’s where the IOTA Charge Station comes in. Since the IOTA Charge Station is a machine, and allows for machine to machine communication with the car, it could also communicate with ‘the grid’. The grid in our case will be all connecting devices to a certain part of the grid, and the transformer supplying energy to that part of the grid. Usually a transformer has 1 feeding cable and multiple outgoing cables, to each outgoing cable multiple homes and other devices (like public charging stations) are connected.
When we were building the IOTA Charge Station we thought of a way that this charger becomes an intrinsic part of the grid. What if chargers can receive messages (requests) to behave in a certain way (energy wise), and can communicate with the transformer. The transformer in return can monitor all outgoing cables, and the load on those cables. If one of these cables might reach its limits, or the sum of the cables would be higher than the transformer can deliver, the transformer could request the connected devices to lower their energy demand.
The connected devices could listen to that request and decide if it wants to follow up that request, or not. The device is totally free to not follow the request. However, the transformer incentives the devices to lower their energy demand by giving a small fee. If one or more devices listen to the request and (for example) lowers its energy usage it’d get a few IOTA in return. In this way, we develop a self balancing grid with smart devices that communicate with each other and are incentivized to follow a certain behavior.
Sounds easy right? Well it’s not. Distributed Ledger Technologies however, with cryptocurrencies, have enabled these possibilities more easily. Want to learn more about that? Read the blog post about: What are the possibilities for DLTs like Blockchain, Tangle and other related technologies in the electric mobility infrastructure?
The question is, could such a system work autonomously? How can DLTs help achieve such a system? To which problems do we run into when developing such a system?
Food for thought: Jan-Peter Doomernik once told me a very interesting, even disruptive use case in grid balancing. A radical transition of the purpose of our energy System: What if the energy system is not about making money for some parties, but enabling (abundant) energy for all.
The energy system of today is highly complex and competitive. A lot of parties are battling to maximize their profits. Enabled by the payments of the energy users. Besides competitive games, we also know cooperative games? What would that mean to our engineering and design of our energy system?
- We choose a different starting point for our engineering: The sun lays a layer of raw, abundant and free energy, everywhere. Also on your roof. 1500 times the amount of energy you need. And You need the energy 1,5 m below in you socket.
- We would change the rules. You no longer have to pay for units of energy. As long as you do not pass the threshold of the system (using for example the free abundant energy) energy is free. As soon when-by accident you force the system to operate beyond the threshold, to transport, generate, convert or store energy you’d have to pay.
Radically different is that you share this unwanted situation of having to pay with all the people. Any collective effort would be aimed at offering alternatives, optimizing the use of free energy and probably even crowd sourcing alternative solutions. (Did you know that water, water with salt and a membrane also generates energy and every house has water access, Did you know that MIT, Uni Delft & Leiden all are working on artificial leaves, that mimic the behavior of treeleaves, turning sunlight (with a bit of water or CO2) in the hydrogen-gas or liquid methanol).
We would have created an energy system as a commons, where there are a growing number of available and free alternatives that ensure that the system gets more resilient and can respond antifragile. The threshold moment at which you have to pay will be higher and higher. Especially when you take into account that the balancing also could be handled by mobility systems that are designed as commons that would support this energy system as mobile/emergent grid you get a hint on the magnitude of change these machine2machine ecosystems could bring: enabling an cooperative energy system not based on scarcity but operating towards abundance.
At ElaadNL we look at smart charging solutions, to make sure that we can charge all electric cars in the future at the best time and the most sustainable way, and make sure that we don’t overload the grid at peak times.
Creating the ideal grid is too big for a single proof-of-concept so we took a smaller part that is easy to extend later on. We created a demonstrator that has a few actors and is able to manage usage on a small scale. It incorporates the the thoughts mentioned earlier and shows the true power of a self balancing grid.
The technical steps
To demonstrate the above mentioned smart charging solution based on IOTA, we aimed on building a device that is interactive, transparent and easy to use. We designed and built a demonstrator that consists of 5 devices showing data and behaviour based on information retrieved from the IOTA tangle.
The 5 devices show simulations of a transformer and 4 charging stations connected to this transformer. Don’t let the term simulations fool you. All simulations are based on real transformer data collected from the ElaadNL premises in Arnhem. The transformer shows the actual total load as well as information per phase. The 4 charging stations show the transformer load as well as their own current status. The energy usage of the simulated charge stations is added to the overall usage of the transformer.
The devices we used are Raspberry Pi’s (3B+) with a 7" DSI touch screen attached. Having the touchscreen attached allows us to make an interactive demonstrator. Internally the Raspberry Pi’s are connected to a gigabit network switch and a small travel router that is capable of connecting to Wi-Fi, ethernet and USB tethering devices (an iPhone for example). The Raspberry Pi’s are powered by a big Anker USB Charger and the touchscreens are powered by their own cable to minimize the power draw from the Raspberry Pi’s.
The transformer device shows real-time data from the actual transformer combined with the virtual usage of the 4 simulated charging stations. Users of the demonstrator are able to change the transformer load threshold to make the system think it has reached its capacity limit for example.
The charging station devices show real-time data they receive from the transformer. All information is gathered from the IOTA tangle and the charging stations publish their own data to the tangle as well.
Transformer data in the tangle
Charging station data in the tangle
Payment transactions in the tangle
For demo purposes, the software on the charging stations starts and stops virtual charging sessions at random moments for a random duration of several minutes. Users of the demonstrator however are able to start and stop charging sessions at any moment in time to see what happens with the total load on the transformer.
The charging stations can have different characterizations based on a random factor. On startup a virtual charging station gets a certain set of settings assigned such as the amount of phases and the amount of amps it can draw from the grid. Based on these settings, the charging station is constantly publishing its energy usage to the tangle on a 30-second time interval. Besides sending data to the tangle, it also sends the energy usage to our backend directly via a HTTP POST message. We had to implement this because we have no other way of checking the actual usage. In a real-world application the best way to solve this is to have a smart meter sending the actual usage reports.
All code is written in javascript. The whole demonstrator consists of a backend and 5 front-ends. The backend is in charge of gathering transformer data and constantly monitoring its load and threshold. The backend is basically the (virtual) transformer and sends out meter values every 30 seconds. These messages are in JSON format and are directly attached to the IOTA tangle via 0-value transactions. The backend is a NodeJS application, this choice was made because the IOTA JavaScript library is by far the most mature.
The front ends are also written in JavaScript and utilize the Electron framework to create a nice interface. We chose Electron for its ease of use and the underlying NodeJS backend so we can use the IOTA Javascript library. All user interface logic is in it’s own thread and is only responsible for updating graphs and values. Next to the UI-thread we have a main thread that is handling all communication and is yielding basic setup settings. Because the IOTA functions are still quite CPU heavy, we created another thread that is in charge of handling all IOTA communication and function execution. The Raspberry Pi’s are not as powerful as desktop computers so handling CPU heavy tasks in their own thread helps to keep the UI responsive. We used the Chart.js library for the graphs and we used some Bootstrap components for the UI.
The biggest challenge while creating this demonstrator was dealing with the limited computational power of the Raspberry Pi’s. Electron allowed us to do development and testing on a normal desktop environment. However, after uploading the application to the Raspberry Pi’s we directly encountered hangups and bad application performance. We dug into the most heavy functions and found the IOTA functions (address generation, bundle creations, signatures) to be the biggest bottleneck. Making transactions is quite heavy because it needs to calculate a new address based on a private seed. We were able to move this calculation to a new thread so it is done in the background without the user noticing. After generating the address, some minor Proof of Work (PoW) needs to be done before a transaction is attached to the Tangle. This PoW is easy for a desktop PC but a bit too heavy for a Raspberry Pi. We found a nice way of offloading the PoW to a cloud solution named powsrv.io that is using a FPGA setup to perform PoW for free for everybody. The powsrv.io setup is easy to use and only requires one javascript function to be executed in order to patch the iota object in our code to use their service. Creating a transaction is now lightning fast!
The transactions created by the backend are not sent to the Tangle individually. At the time of writing it can take up to 3 minutes for a transaction to be confirmed. During these 3 minutes no other transactions can be attached to the Tangle when using the same seed. Combining transactions over a larger period of time can help overcome this issue. Luckily, IOTA offers a way to achieve this. Transactions in IOTA are part of bundles. A bundle is a collection of transactions and once one of the transactions in a bundle is confirmed, the whole bundle is confirmed. We used this mechanism to minimize the amount of time we need to wait before we can send new transactions via the same seed. We collect all transactions over a timespan of 10 minutes and send one big bundle to the tangle to get confirmed.
Sending a transaction or a bundle of transactions to the tangle will not always mean it will be confirmed within a few minutes. Due to the structure of the tangle and the way transactions are linked to each other it is still possible a transaction is placed somewhere in the tangle where it is not referenced enough by new transactions, thus resulting in the transaction not being confirmed at all. There is however a way to make sure the transaction will still be confirmed. IOTA offers a way to reattach a transaction to the tangle. Reattaching a transaction means sending the exact same transaction to the tangle again. The transaction then has a new chance of being confirmed because it is at the end of the tangle again.
Our backend contains a mechanism to monitor all of our transactions (actually the bundles) that are sent to the tangle. Every few minutes we check if they are confirmed and if not, it reattaches the transaction to the tangle (and for bundles it attaches the first transaction within the bundle). This we way can make sure all transactions are confirmed before we send a new bundle of transactions to the tangle.
Besides facing difficulties in software development, we encountered a problem with some of the Raspberry Pi’s overheating. Some functions in the IOTA library are quite CPU intensive and cause a lot of heat generation by the Raspberry Pi. (Un)fortunately the Raspberry Pi starts throttling performance to make sure it does not overheat or cause a release of magic smoke. We tried setting a higher temperature threshold (all the way up to 85 degrees celsius), but even this didn’t fix it. Luckily we did foresee this issue when building the casing for the demonstrator. We plan on fixing this by adding heatsinks to the Raspberry Pi’s and adding a small fan in the wooden enclosure to generate some airflow.
Hindsight
Learning about new technology was our main goal for this project. We set the scope for the project and made a bunch of decisions. It is safe to say we learned a lot!
First, after creating the world’s first IOTA based charging station, we decided to take our IOTA knowledge to the next level by using it for our next demonstrator. We already learned a lot about the usage of IOTA in an embedded environment but decided to try to overcome some issues we already knew about. By applying multi-threading techniques we were able to use IOTA and create a snappy demonstrator. During development, the IOTA foundation released their new version of the Javascript library, this could be tested in the future.
Secondly, the usage of a DLT technology in a project like this one always raises the same question from the audience: How do you overcome the versatility of the token’s fiat worth? We simply leave this out of scope because this is a common issue with (almost) all tokens at the moment. We also vastly believe in a world where tokens will be traded directly for goods or services without having to calculate the fiat value. It would be awesome to see that 1 kWh of energy would costs 1 IOTA and we could trade this peer to peer!
Thirdly, the choice of hardware and software. While thinking about the future and creating a demonstrator like we did multiple times, we think it’s important that one should be able to reproduce it easily. We always search for already available parts that are also affordable. When writing the software, we try to use common programming languages and libraries. After building the hardware and software we do a write-up like this and publish the source code. We do this in order to stimulate innovation and help people get started to build their own solution.
At last it should be mentioned that a demonstrator is built to demonstrate a certain concept or thing. One of the available outcomes during development could always be that things simply don’t work as expected. We faced overheating issues, unstable IOTA nodes and the PoW algorithm that is a bit too heavy for a Raspberry Pi. It is important to mention that we want to be as transparent as possible about our process and make sure other people don’t have to reinvent the wheel.
In the end we managed to create a demonstrator that is easy to use and very portable in case we need to move it to another location or presentation venue. All source code is uploaded to a GitHub repository and is free to use for everyone as long as they also disclose their source code if they base it upon our work.
The lessons learned
To answer the question we raised in the beginning of the blog if such a system could work, short answer: Yes, definitely!
The technology still needs to develop a bit further to scale it up. However, the concept of such an autonomous system will work. We showed that in our demonstration, which includes all the basic functions to run such a system.
How can DLTs create a better grid/system in the future?
We all know what solar and wind energy are become more and more common in our grids, and we also know that at night the sun isn’t shining. This means that we have to use the energy when it’s available, or store it for a later moment in time. By using this technology we can create self sustainable islands which can keep themselves running with the power the harvested. Combining multiple islands would create a much more resilient network, and thus much more resistant to power outages.
The DLT can take care of managing those decentral grids, by taking over the administrative and payment part.
To which problems do we run into when developing such a system?
The challenges we currently still face are related to the technology itself, of the hardware and the software. The hardware we used wasn’t always capable of dealing with the things we asked from it, like plotting graphs and creatings signatures all at once. The software sometimes still feels unreliable, also to the fact that some full nodes of IOTA aren’t that stable. There are multiple developments going on to make this better, but at the time of writing this wasn’t the case yet.
Recommendations
We have a few recommendations for people wanting to continue with this project:
- Extend the charging station behavior: at this moment the charging station will always do what the transformer asks for. This is probably not how things would go in a real world situation, but we left it out of scope for now.
- Add other actors into the grid: right now we only have virtual charging stations but it would be nice to see battery’s, PV and households being added to see how this could work.
- Replace old IOTA library for new one: we believe new is always better in this case. Using the new library might solve some issues.
