The chapter "Physical implementation in a Test Network" shows how the basis of the MVP was built up. The private Ehereum blockchain with two nodes and three miners were set up at the beginning of the hackathon and the communication could be ensured. The sample scenario in the previous chapter shows how far the technical implementation of the MVP has come during the course of the hackathon. The sample scenario was implemented and it is possible to comprehend which party buys energy from which provider. Furthermore, it can be seen from the screenshots and the sequence diagram, that the functions related to the transfer of the ether could be implemented as well. Thus, the first part of the MVP has been implemented. It is safe to say, that within the short given amount of time the team could reach their set goal.
In order to implement all requirements, the second part of the MVP would have to be analyzed in more detail, implemented and tested. This was not done during the hackathon, but remains as a future task.
A short explanation of the future task follows:
The Matlab model (created and provided by Petr Tugarinov) that should be used looks like this:
The goal of the model is to calculate and provide the energy offer or demand from every node of the network. The grid and the battery can provide or consume energy, hence they are the only two components that can have positive and negative values. The Matlab model generates energy data every 15 seconds, and every generated data set represents the intended energy data of 24 hours. The energy data include the amount of energy in kWh and the price per kWh.
The next step would be to install Matlab and make use of the already existing model. The generated data should be extracted and implemented in the deployed smart contract. A possible transmission approach is to use the User Datagram Protocol (UDP). This functionality can be applied in the "Packet Output" block in the top middle of the Matlab model. For the output block the timing, the output size, the data type, the host name and the UDP port can be configured. How exactly the Packet Output block should be configured and how the output data can be used by the nodes has to be examined further. A possible option is to make use of a small Java program that transforms the data and calls the methods of the smart contract with the transformed data.
During the course of the hackathon, various problems or obstacles came up. One of them is, that the given use case is very complex and the only ones having previous knowledge about the energy sector were the students working on the business use case and its documentation. This made the implementation and the communication between the teams very difficult and misleading. It was hard to create a common understanding and a basis everybody could start from, because the business students did not have knowledge about the technical aspects. Another problem we encountered was regarding the available hardware. Since the miners need a lot of resources, the decision was made to run them on laptops. However the laptops were fully occupied by the miners, altough some of the laptops were running otn he newest and currently most powerful i5 processors. Because of this, three of the team members could not work properly while the blockchain was running, all this at the already very tight time scedule. Since it was possible to estimate at the beginning that the time is tightly calculated, the MVP had to be divided into two parts of which only one could be worked on. The fact that three laptops were running the blockchain did contribute to the time running out before working on the second part of the MVP could start.
A short video about the project can be found here:
A short powerpoint presentation about the project can be found here: