sdmay20-12 • Applying Blockchain to Energy Delivery Systems

This theme uses "root" links to dependencies and assets (CSS, JS, images, etc.). Place all theme files and directories at the root of your web server for this page to render as intended.

Problem Statement

Energy Delivery Systems are deployed in an environment that is geographically distributed utilizing public internet infrastructure for communications. The integrity of measurements, commands, and authenticity of control devices performing communication are critical for trusted operations.

Proposed Solution

The purpose of this project is to develop a blockchain Energy Delivery System solution to solve the problem statement. The project is driven by the need described in the problem statement above, to create a secure network for a geographically diverse Energy Delivery System. To help mitigate security concerns, the use of blockchain technology would provide a secure network for managing Energy Delivery Systems by removing the dependency on a central service. Additionally, a permissioned blockchain system ensures a higher level of security when concerned with cyber attacks similar to a fifty-one percent attack. With this project we hope to deploy a permissioned blockchain system for interaction between devices on an Energy Delivery System and users managing those devices.

Diagrams

A simple use case diagram for the project

A high level diagram depicting the basic modules of the proposed solution

Project Demos

UI Demo:

Blockchain Demo:

Project Results

After research and investigation of the types of devices that would be publishing to our blockchain network, we found that a reasonable frequency of data being published would be 60 results per second.

After all components of the project (Blockchain Network, API, UI, and Publishers) were created, we recognized some serious performance issues. The Blockchain originally was only able to create transactions at a rate of about 0.4 Transactions Per Second.

To gather data on a solution, we developed a tool using a publisher-subscriber pattern for performance testing. This tool creates and sends a blockchain transaction, after this transaction is completed it sends a message to the subscriber that there is new data available, the subscriber will then query the blockchain network to retrieve that data. This allows us to test both publishing latency and up-down latency.

After running tests and adjusting blockchain configurations, we were able to increase blockchain performance from 0.4 Transactions Per Second, to almost 3 Transactions Per Second.

Our goal was to get our publishing performance up to 60 results per second and currently our implementation of the Blockchain Network and the Publishers only allows for 3 results per second. To meet our goal, modifications were made to the testing tool to allow multiple results to be sent in the same transaction, which required modification of the chaincode as well.

The Original implementation of the tool for testing performance was able to publish just under 3 results per second without aggregating the data. After modifying the tool, a test was run sending 20 results with each transaction, and still performing 3 transactions per second. The results were much better, and we found that publishing to the database within the chaincode would be a much better solution than making multiple transaction requests.

In the final stage of testing, we modified the tool to create three publishing entities, with each publishing to a different organization. In this test we sent 60 results with each transaction and only performed 1 transaction per second. We expected running three different publishing entities to affect performance, but the results above were exactly the performance we had hoped for. All three organizations were able to keep up with the publishing rate of 60 results per second, with the only issue being that our virtual machines ran out of space.

Project Conclusion

Reflecting upon our implementation of blockchain in an energy delivery system, we are now able to answer some of the questions that our client initially had, such as, is blockchain a viable option in this situation? Our final product shows that blockchain can handle consensus, and validate that integrity of the information in the blockchain is maintained. By modeling our system after the NASPInet standard, see Figure 10, and aiming for a goal of 60 frames per second being published, NASPInet defines that our latency must be less than 100 milliseconds per frame. The best latency our system could achieve was approximately 300 milliseconds. To compensate for this unsatisfactory latency result, the team decided to concatenate frames together. The team was able to achieve 60 frames concatenated into a single create request, then publish this request once per second, resulting in a hypothetical 60 frames per second. Although these results do not perfectly reflect the NASPInet standard, they do meet the goal of publishing 60 frames per second, with some slight modifications to our expectations. Our blockchain network still improved upon typical energy delivery systems’ security by using an authentication system for operations on the network and removed the single points of failure from the system.