Week 8.5: Challenge 1 Final Solution

This mid week post will be focused on providing a glimpse of how our solution could be implemented, by providing some insight on our own implementatio.

The architechture

The solution is composed of 4 modules:

• Web Interface: User Interface that allows the user to easily utilize and interpret the developed expert systems.

• Main Server: Simple API Gateway that is responsible for interpreting the requests, directing them to the right expert system, and then structering the response to a format understood by the UI.

• Prolog Expert System: The expert system developed using Prolog

• Drools Expert System: The expert system developed using Drools.

The [AI]xpert System

For the execution of the expert system, a few parameters must be set:

• Period: The date/time range for which the expert system will generate a plan of action.

• Buy Market: The market that should be used to buy energy.

• Purchase threshold: How low the energy price must be for purchase to be favorable against using consumers' flexibility.

• Sell Market: The market that should be used to sell energy.

• Sale Threshold: How high the energy price must be for sale to ba favorable against storing the energy.

• Expert System: Which implementation is to be used (Prolog or Drools).

As for the results, there are a few ways to see the data, here are some examples

Community-wide results over time:

Community-wide results over time (hovering/selecting a given period):

Single Participant over time (with only 2 parameters selected):

Community-wide per period view:

Each parameter has a color associated to it, and each recommendation and justification also has the color(s) of the parameter(s) that they affect, facilitating their interpretation.

All the results presented above are from the Prolog implementation. Even though both implementations usually reach the same conclusions, the Drools implementation uses certainty factors and, as such, is a bit more detailed in its justifications, as seen below:

The Pl [AI] tform (Web Interface) rundown

As the backbone of the solution, The Pl[AI]tform packs a lot of funcionalities that are not directly associated with this challenge, but facilitate its testability and adaptability. As such, this section will focus on detailing those functionalities.

The configuration file

In order to make the Pl[AI]tform reusable and adaptable to future challenges, the team tried to make it as dynamic as possible. Using the same stratagy applied in one of the member's internship, a configuration file is used to dictate how each feature/parameter is handled.

The Pl[AI]tform accepts 3 types of parameters:

• Categorical: simple classification, not variable over time, such as the name, the type of energy etc.

• Numerical: a number that is not variable over time, such as battery capacity.

• Numerical array: parameters that are numeric and vary over time, such as the consumption and generation of energy.

While defining the parameters, it is also possible to specify if it should be converted to scientific notation and its units, which are also defined in the configuration file. The file also provides some more features that will be explored later.

Dataset management visualisation and modification

The main page allows the user to load, remove or download a dataset to/from the Pl[AI]tform.

The Community tab, allows the user to observe the energy balance of the whole community overtime, through charts.

The inner sections ("Overview" and "Production") as well as their charts are all generated dinamically, according to the configuration file and allow for more complex charts such as the one below, which aggregates the energy production by its type.

The Participant tab allows for a more detailed look into each participant data as well as allowing its modification. The main section, "Constants", displays the participant's categoric and numeric information.

The "Forecast" section contains some information of the type numeric array, presented in charts, similar to the "Community" tab. For a more detailed view of this information, there is the "Table View". As the name suggests, this presents the information as a table and allows for modification.

The "Markets" tab displays the price of each market over time and lets the user define price thresholds for purchase and sale of energy. It is possible to change the prices, in a table format. Finally, this tab also identifies which market is the cheapest/most expensive at any given moment, and generates composed markets, that always ensure the best prices.

This was a long one... Unfortunately, due to the amount of technologies used in this challenge, it would be a bit too expensive to host just for demonstration purposes, but hopefully we could provide all the detail needed.