10. Quality of the Project and of the Prototype

1. Connection between Quality and Requirements

To assess the overall quality of the developed concept the requirements of this project have to be known.

1.1 General Requirements

The general requirement of this interdisciplinary project between theoretical conception and practical realization was the implementation of a P2P energy trading business case for an energy micro grid by using blockchain and smart contracts as communication and information technologies.

1.2 Business Case and High Level Use Case as Requirement

The business case requirements are further specified in the high level use case under 2. High Level Use Case that says that the energy consumer that is represented by the load owner should enter into energy contracts in every 15 min, every 24h. Also, the energy contracts should contain the amount of kWhs as well as the price for it.

1.3 High Level Use Case and Primary Use Cases as Requirements

Under the high level use case there are two primary use cases to be described. On the one hand, the use case that includes the calculation of the energy fluxies between the energy participants and on the other hand, the P2P contracts which enable energy trading between them. As the energy fluxies were given by Matlab in this project, this was not subject of the technical implementation. However, the data had to be taking from Matlab to put them into the smart energy contracts, so, accessing and adjusting of the data was subject of this hackathon. The P2P contracts for energy trading were also topic of this hackathon.

2. From General Requirements to Hackathon Prototype

Instead of providing a fully integrated software solution for energy trading within the energy micro grids, the general aim of a hackathon is to produce running software prototypes in a limited amount of time . Hence, the results of this hackathon was the development of a Minimum Viable Product (MVP). A MVP is an artefact that may be incomplete in functionality or quality, but displays characteristics with which the customer value can be fulfilled . Therefore, the provided functionalities of the MVP will be evaluated based on customer value of an energy trading application for an energy micro grid.

[Komssi M. et al. 2014]

[Münch J. et al. 2013]

2.1 Qualities evaluated on Customers Value

Blockchain and smart contracts as technologies can only represent a part of the overall tasks within a system in which producers and consumers exchange energy. A holistically functioning energy micro grid requires additional services. These include, for example, energy forecasting services, real-time data recording units and energy suppliers that work like an insurer, balancing energy needs and emissions

[Wunderlich S. et al. 2018].

Transparency in Energy Distribution and Energy Pricing: Within the micro energy system, transparency and trust deliver the highest customer value. Distributed ledger technology, which is provided by a blockchain and smart contracts, allows all transactions to be completely checked and tracked. The origin of energy prices can also be traced and verified. This promotes transparency in the micro grid and increases trust between the involved parties.

Local Energy Consumption and Production: The generation of local energy can be seen as a high value. The people participating in this energy exchange get a better awareness of energy production and energy consumption per se. This enables to actively participate in energy trading and to reduce energy costs by participating in low energy prices.

Real Green Energy Consumption and Production: Contrary to the assumption that green electricity actually reaches the end consumer when green electricity is purchased, the local grid operator can only pass on the electricity to the end customer which receives it from the overlying grid operator. This electricity can come from coal or nuclear power plants. Trading in green energy is based on certificate trading. In a micro energy grid and the associated recording of current flows, the participants can see exactly which current flow they have generated. Baterie storage enables the end consumer to consume the actually green electricity generated in the micro energy grid. This is of great value to an ecologically-motivated consumer class.

Strengthen of Local Structures and Economies: When consuming locally generated energy, the final fees remain in the local community and the end customer knows exactly where his money is going. The producer within a local energy market can use the payments to finance investments or pay for local services. This strengthens local, economic structures.

Reducing Energy Costs through Flexible Tarifs: Energy prices can be very volatile due to rising and falling demand and the varying supply of energy. In a micro energy grid with transparent price generation, a consumer can take advantage of this and then consume energy when it is cheap. This reduces energy costs.

Reducing Energy Costs through Disintermediation: The use of a blockchain with smart contracts allows the direct processing of transactions including the payment process between unknown actors without intermediaries (disintermediation). This results in cost advantages that can reduce the energy price.

Abolition Red Tape through Digital Services: The digital processing of transactions and payment processes enable the end consumer to get rid of his paperwork.

2.2 Technical Qualities provided by MVP

In addition to qualities with regard to customer benefit, qualities are also determined by how well the IT application can meet the general requirements. In our hackathon, the MVP is responsible for meeting the IT requirements.

The most important information technology qualities of the MVP are described below. The section also describes how the qualities support the requirement for a smooth and open energy trading service within a micro energy grid.

Performance: The MVP works within a private blockchain according to the consensus Proof of Authority. As we are in an energy micro grid that works with a manageable number of participants, it is not necessary to set up a public blockchain in this case. Other consensus approaches e. g. Proof of Work are known for a rather slow and energy-intensive way of working. In contrast, Proof of Authority has the advantages of a higher performance for proofing blocks and a reduced energy consumption per block.

Availability: The availability of the blockchain network from PoC 1 can be checked accessing the private blockchain via a node. Furthermore an account is required. The availability of the development environment in Poc 2 and 3 can be tested using the same approach for testing the availability of POC 1 but accessing an different private blockchain.

Interoperability: The parts of the MVP presented as PoC 2 and 3 can communicate with each other. The data from the Matlab simulation can be transferred from to the smart contracts storred in the development environment. As a possible further development of this MVP, the smart contracts can be written to the private blockchain of PoC1. In the operational blockchain, additional nodes can be connected with little effort and thus the network can be expanded quickly with small limitation to scalability.

Security: Security as a quality aspect played a subordinate role in the creation of the MVP. The security of a blockchain and the content written on it provide a basis of security through the application of distributed ledger technology. Nevertheless, a blockchain cannot be 100% save at this time. Vulnerabilities can occur due to 51% attacks or due to gaps in the configuration of of the network.

Testability: The basis function of creating new blocks on the blockchain network from PoC 1 can be tested with nodes that have the authority to mine blocks. A used testing environment during the hackathon was the command line interface Geth. The smart contracts from the development environment in PoC 2 were filled with data generated by the Matlab simulation in POC 3. This function could be tested running the environment blockchain using Geth and starting the developed JavaScript webserver that pushes the Matlab data to the smart contracts using the Web3 library.

Usability: The concept is based on the automatic generation of smart contracts. Due to this, the usability of the blockchain in form of a graphical interface for manual interactions is not necessary for the end customer. A monitoring function as a controlling instrument is conceivable and was identified during the course of the hackathon.

Modifiability: The possibility of establishing new nodes within the blockchain makes it possible to connect new market participants to the energy scenario in the micro grid. Moreover, new smart contract templates can be published to the blockchain as adaptions to each energy stakeholder that salvages new requirements.

2.3 Qualities in Software Design

Besides qualities that are determined by the technical MVPs, qualities that result from the software design are also decisive. These are referred to below.

Separation of Concerns: Through the procedure of mapping smart contracts between the energy participants, each participant receives only his decisive information. This promotes the idea of Separation of Concerns. However, this does not limit the transparency of the entire application, since all data is stored on the blockchain and can also be viewed by authorization.

Information Hiding: Information within the blockchain concept are hidden behind several layers. On the first layer the smart contract information is only retrievable when having access to the private network where the blockchain is running. Furthermore, the RPC and the network ports are only open to special services even within the network. Using smart contracts, on the second level of abstraction, requires the address and ABI of the deployed contract and the parameters defined in Solidity can follow hiding paradigms.

Desing Patterns: By using templates and code snippets from several tutorials, the design follows the given pattern that were not evaluated. Used interfaces e. g. Web3 specify particularly creational and behavioral design pattern.

Documentation to handle Complexity: The documentation of a devloped software supports the understandability and furthermore gives insights to the complexity of the software entity. The information provided in this documentation can be considered as a support artefact to the programming code developed during the hackathon and can be used for further projects.

Pair Programming: During the hackathon pair programming was used as the development technique, on the one hand, to reduce the occurrence of mistakes by reviewing and, on the other hand, to accelerate the development by navigation.

Test-First: This MVP can be considered as a test case for future development regarding integrating blockchain into the energy sector. According to the principle fail fast, learn fast testing serves the improvement of quality. The satisfying testing results of the defined blockchain concept were achieved because of this principle using several applications, services and approches for one intend.

​

​