Use Case
Due to the recent advances in household-level renewable electricity generation technology, a new type of market based on peer-to-peer (P2P) electricity trading between households will emerge. In this experiment we design a potential technical framework for energy controlling on a peer to peer network.
Therefore, we set our focus on intuitive Use Cases that can be experienced on the basis of energy data collection within a household and within a community. The Concept is described as following:
By designing his own Smart Home in form of a model instantiation in ADOxx, the User is given an intuitive approach to customize his energy settings, where he sets parameters for deploying Smart Contracts, which deal with energy issues. The processes are executed by machines according to the customers model composition.
A restful web service passes the model and its belonging instances to an Ontology. The ontology serves as database, where the model with its instances and relations are stored. In fact, the User decides how he wants to proceed with his energy resources. If the user decides to trade energy, then a smart Contract is written out of the model into the belonging blockchain, giving him the opportunity to optimise his energy in terms of costs and additionally log his average energy consumption. Furthermore the system will be able to send warnings, when the system recognizes unusual energy consumption behaviour from a particular device. All of the Use Cases are written and executed on the Blockchain, guaranteeing a fast and secure way of transacting and verifying.
To sum up the system contains the following components:
– ADOxx Metamodel: Metamodel for modelling own smart home model
– RESTful Web Service: is used as an architectural style.
– Ontology: Data structure of the system
– Ethereum Blockchain: Platform for the deployment and execution of Smart Contracts
Business Use Cases
Use Case “Log your Energy Consumption”
By querying the ontology or the model we can figure out the consumption of the desired devices within a household and calculate the current energy usage. Using queries and finding patterns we could figure out the consumption of a household and predict the consumption for t+1 in further development steps.
On the basis of these calculations, an automated trading system would be able to cut energy cost peaks by by taking a Long Position in a future transaction in t0 for example.
Use Case “Check Warranty”
The system saves energy labels according to the devices the User registers in his model, which give information about the maximum a device should be able to pull energy. These labels and their belonging maximum energy value of on consuming appliance is written into a Smart Contract. If the system or the user detects an anomalous behaviour of a specific device, then the Smart Contract gets triggered and initiates a warranty claim in case.
Use Case “Trade your Energy”
The aim of this use case is to provide the user the opportunity to sell or buy energy within the network over the blockchain with a smart contract. The user is able to define thresholds pursuant to his market preferences. The smart contract calculates the difference between his production units and the self consumption of his household.
Experiment
Resources for the experiment:
https://github.com/dieni/semanticTechnologiesWS18
The following video represents an example execution of the experiment in one pass:
The execution and the reproduction of the experiment can be described as following:
Step by Step Execution of the ADOxx-Part:
Path to XML model instances: semanticTechnologiesWS18.git\smarthome\modelinstances
Model Instance 1: Execution of Use Case 1 “Log your Energy Consumption” and Use Case 3 “Trade your Energy – Buy Energy”
Creating a model instance for Scenario 1: Execution of Use Case 1 “Log your Energy Consumption” and Use Case 3 “Trade your Energy – Buy Energy”
Creating Class-Instance with one Prosumer, one Energy Source, one Energy Controlling Class and 2 Energy Consumption Appliances
Set Parameter for the Classes:
Prosumer: Attribute “Private Address” = Necessary for deploying and executing Smart Contract!
Energy Source: Attribute “Prower Production Current” = Necessary for Use Case 3, as we want to buy Energy we must set this attribute lower than the Sum of the Current Consumption of all Energy Consuming Appliances. In our case we have 500 Watt of Production.
Energy Consumption Appliances: Attribute “Power Consuming Current” we have inserted 400 + 300 + 100 = 800. As we have 300 Watt more Consumption we have to buy energy.
For Use Case 1 “Log your Energy Consumption” also the “Power Consuming Current” will be retrieved, for saving the consumption into the blockchain. In our case the Smart Home has an Consuming Current of 400 + 300 + 100 = 800 Watt.
At the end the XML has to be exported.
Model Instance 2: Execution of Use Case 2 “Check Warranty” and Use Case 3 “Trade your Energy – Sell Energy”
Creating a model instance for Scenario 2: Execution of Use Case 2 “Check Warranty” and Use Case 3 “Trade your Energy – Sell Energy”
Creating Class-Instance with one Prosumer, one Energy Source, one Energy Controlling Class and 3 Energy Consumption Appliances
Set Parameter for the Classes:
Prosumer: Attribute “Private Address” = Necessary for deploying and executing Smart Contract!
Energy Source: Attribute “Power Production Current” = Necessary for Use Case 3, as we want to sell Energy we must set this attribute higher than the Sum of the Current Consumption of all Energy Consuming Appliances. In our case we have 2000 Watt of Production.
Energy Consumption Appliances: Attribute “Power Consuming Current” we have inserted 600 + 300 + 100 = 1100. As we have 900 Watt we don’t need we can sell energy.
For Use Case 2 we need to set the “Power Consuming Maximum” of one Appliance, lower than the “Power Consuming Current”. 500 – 600 = – 100, we can see that the Refrigerator is over the max limit. So the Smart Contract can be executed.
At the end the XML has to be exported.
Step by Step Execution using the REST framework:
Before starting the experiment, delete the .owl file in /smarthome/.
Upload a smart home by sending an adoxx model to the endpoint
POST: localhost:5000/api/prosumers
(send adoxx model in the body)
This will insert information from the smart home in the ontology.
After this you can retrieve information from the ontology by using the endpoint:
GET: localhost:5000/api/prosumers
GET: localhost:5000/api/prosumers/
Next we can deploy the contracts using the endpoint:
localhost:5000/prosumers/
This creates warranty contracts for each consuming appliance based on the maximum energy consumption and deploys it on the ropsten testnet.
When the same prosumer sends a model to the following endpoint, the warranty contracts will be executed to see if the current consumption of the consuming appliances is higher than the maximum.
PUT: localhost:5000/api/prosumers
(send adoxx model in the body)
By submitting this step we can evaluate the Use Case “Check Warranty”
To log the current energy consumption of the devices execute this endpoint:
GET: localhost:5000/api/prosumers/
This will deploy a smart contract with the current consumption of the devices on the blockchain.
By submitting this step we can evaluate the Use Case “Log your Energy Consumption”
To trade energy, all the current production subtracted by the consumption will be deployed using a smart contract. If the production is higher than the consumption, energy will be sold and vice versa. Therefore, the following endpoint must be executed:
GET: localhost:5000/api/prosumers/
By submitting this step we can evaluate the Use Case “Trade your Energy”
Results
Achievements:
As a result we can see a potential framework for the intuitive interaction between the user, a model and the execution environment.
We achieved to combine promising technologies and establish a potential system for a digitalized energy market.
Restrictions:
It was hard to use the ontology in combination with owlready2, as the documentation is incomplete.
Solidity as programming language for Ethereum Smart Contracts is also not fully developed by now.
Future Extensions:
There are various extensions of the above mentioned Use Cases that can be addressed for further future development:
> Forecasting energy consumption data for a household and for the network as a whole. By achieving this a whole new approach for trading energy could be established.
> A further extension could be an implementation of a Trading Platform, where an Algorithm matches supply and demand, acting according to a business logic.
Reaching the above mentioned could lead to a breakthrough in generating renewable energies and sharing them with each other locally.
Possible future work and miscellaneous master thesis topics can be derived from the experiment and the extensive underlying domain of Peer to Peer Energy Trading. Use Cases arise continuously due to the further development of blockchain technologies and the digitalisation of the energy market.