The Energy Economic Lab Playground is an experimental research infrastructure development project that is meant for the project author to play around with technologies and energy system and market design ideas for developing a research infrastructure for experimental energy economics.
Its goal is to investigate good practices, architecture and code snippets of how an energy economic lab can be developed for a subsequent project where it is actually properly implemented. The energy economics lab is intended as a piece of research infrastructure for investigating flesh-and-blood actor interaction within use cases for blockchain-based peer-to-peer energy trading systems involving synthetic actors.
This experiment project involves Angular 7.3.0. and some mock services for the inclusion of external sources that will eventually be added
Following Tomas Trajan, the project separates the code in a commonly shared core module and (dependency-less) SharedModule, as well as a bunch of feature modules. The feature modules encapsulate views and functionality for the different types of actors (Prosumers, Grid Operator, Experiment Designer and Public Actor) in their respective modules, that communicate indirectly with one another, through the external data ressources (EDM layer and blockchain layer, as proxied through the mock EDM service and the blockchain transaction service at this time).
Since the view of the lab is (for now) conceptualized as a single-page application with dynamic components, no routing on top of the actor roles is necessary. For this reason, no routing modules were included with the respective feature (role) modules. This might well be changed (and can be easily added) in later versions, staying consistent with the Angular documentation. This would particularly be the case if the modules for the different actors should be loaded lazyly, which would probably be a good idea, since every type of user has exactly one type of feature module they use once they are logged in through the welcome page. Due to the authors lack of experience with Angular, it is however not clear which would be the best solution for this matter.
The Playground is embedded in a project using two further components: An open data platform (located within the WindNODE Energiedatenmarktplatz) and a blockchain layer within the WindNODE Blockchain Smart Energy project (internal documents only). The other components are mostly developed independently from this component, and will be joined according to (yet internal) interface specifications. Within this project, these components are represented by the Mock EDM Service and the Blockchain Transaction Service, which will function as the interface at a later stage (probably with some respective refactoring).
The code within this repository describes the (stateful) frontend of the lab. In the following, the components are organized by role the user plays within an experiment, as described below.
The frontend application consists of two websites, a welcome page for the selection of the respective experiment and the role of the user within it, and the page the user interacts with during an experiment. The welcome page serves as router and identification page, in order to get the user to the right experiment in the right role. Upon insering a code in the input field and logging in, the user is routed to the respective page detailed below.
The UI components are organized as follows (with a detailed description found below or in the respective documentation files):
Exemplary User Interface Component Organization for Prosumer Components
Since for the early stages of this development the prosumer perspective is in the foreground, (for now) this documentation focuses on these elements. The prosumer view (as single page view) is implemented through the Prosumer component in the prosumer module. It contains prosumer information (if the prosumer is set), experiment information (if information exists), the time component, the persistent resource display, the market view and the fee and levy display. It thus keeps experiment-persisting data (in addition to the asset data kept in the persistent resource display data and the experiment data as managed by the experiment instance and experiment description), and comprises the components managing the operations of a Prosumer.
Persistent resources are those assets that persist throughout an experiment. While their state changes, i.e. they are operationally dynamic, their attributes/characteristics are static. Currently, persistent resources are financial assets (tokens), geographical information (meter point / feed-in coordinates), exogeneous prices (gas and carbon prices) and technical assets. The latter resources can be distinguished by type, currently by controllable generators, non-controllable generators, loads and storage facilities. Persistent resources are stored in the prosumer instance (which is asyncronously fetched from the Experiment Instance Loader Service as an observable), and are displayed dynamically once their data is fetched.
Geographical information is managed by the Feed-in point display, through passing data as Coordinates, while technical assets are based on data of the respective data types (as specified in the respective typescript files). The technical assets are displayed by listing their technical parameters and their generation/load/storage curve, as a chart as implemented through the ChartJS library. When existent, the chart is represented by a canvas element in the html markup, represented by ViewChild data in the typescript (.ts) file. State information is held in the .ts file and enriched with further vizualization information in a Chart object.
Similarly, information about the residual load based on the operation of these technical assets is displayed as a chart as implemented through the ChartJS library. This data is based on the dispatch and trade information of the respective prosumer.
More detail on the respective assets can be found in the user manual.
The asset redispatch functionality is still in an early stage and might be sufficiently changed. For now, it lists all dispatchable assets (controllable generators, storage units and loads) and allows to set a schedule within technical bounds for any future point in time. Through this interaction, Prosumers set the schedule of each individual dispatchable asset.
The bid component allows Prosumers to put an offer for electricity into the P2P electricity market. The component provides a form for this, which Prosumers can use to create a valid offer, as long as it fits into the design of the P2P market design. If the offer is valid, it is written into the blockchain layer.
The market view is used to display information about available offers for electricity for the respective Prosumer based on the P2P market. It allows them to filter available offers by price, time, power and duration, select offers they are interested in and commit to them. It furthermore displays the committed transactions.
The fee and levy view informs a Prosumer about the amount of fees and levies they paid over the duration of the simulation, with a granular breakdown of every single fee.
While this documentation illuminated a number of user-relevant aspects, a more comprehensive user manual is included in the documentation as well.
Since the Energy Economics Lab this playground is meant to be preliminary research for is envisioned to be a versatile tool for the investigation of a number of use cases and research questions, considerable need for software development effort is foreseen. With this recognition, and in accordance to the views of the core author, collaborative, open source development is to be encouraged. In order to motivate other developers and help them understand the structure, thoughts and technical aspects of this project, a developers guide will be developed.
Since the application also serves as a learning environment for Angular for the author, no consistent style exists when several options are available. Instead, different solutions or concepts are used to help evaluate which one is most appropriate for use.
The application is furthermore not yet connected to external APIs, so much data is test data from static, hard-coded data structures.