This page describes the interfaces between components as depicted in Figure 1 "Overview of components and interfaces" in this page.

1 Prediction

Description

This interface provides information about predicted PV production and price model.

Providing component:

Prediction

Requiring components:

GUI

API description:

The predicted PV energy will be stored in a CSV file with the format (timestamp,energy). timestamp is the UNIX timestamp marking the beginning of the period in which this parameter set is valid. energy predicted PV generated energy in Wh. The CSV file name is deviceID_timestamp.csv, where deviceID is the deviceID of the concerning PV system and timestamp is the UNIX timestamp at which the prediction has been made.

2 Prediction update at micro-grids

Description

Prediction updates are computed from weather forecast. The Weather Forecast service pushes files into the cloud.cossmic.eu ftp server.

Providing component:

Weather Watcher

At the cossmic ftp server a WeatherWatcher agent is running, watching for file changes into the ftp directory. The WeatherWatcher agent joins the group-chats of existing neighborhoods. Once a file for weather forecast has been created it notifies the group-chat of the interested neighborhood.

Requiring components:

Prediction Handler

The Prediction Handler is running at each microgrid (household). It joins the group-chat of its neighborhood and waits for weather forecast update. When a new message has been received it downloads the file via ftp and computes the new prediction by launching the pvprediction component. A prediction profile for each PV system is stored into the mas/prediction directory. The prediction profile data format is described in 1.2 Output data.

Producer agent

API description:

It is an interaction protocol based on the exchange of the following XMPP messages.

Weather Watcher --> GroupChat

<from>weatherwatcher@cloud.cossmic.eu</from>
<to>neighborhood@muc.cloud.cossmic.eu</to>
<subject>prediction</subject>
<body>PREDICTION_UPDATE: KN_2015080512.csv</body>

GroupChat--> Prediction Handler [PREDICTION_UPDATE: KN_2015080512.csv]

<from>neighborhood@muc.cloud.cossmic.eu/weatherwatcher</from>
<to> predictionhandler@hostname.domain</to>
<subject>prediction</subject>
<body>PREDICTION_UPDATE: KN_2015080512.csv</body>

3 Prediction update to agents

Description

This interface is used to notify the Producer agent about the prediction updates.

Providing component:

Prediction Handler

It sends a message to the producer agent when the file containing the new prediction is ready. The Producer Agent already knows the file name from its ID.

Requiring components:

Producer Agent

The Producer agent receives from the Prediction Handler an XMPP message that alerts it about the update of its profile.

API description:

The Prediction Handler will notify the producer agent about the availability of a new prediction by an XMPP message

#!xmpp
<from>predictionhandler@hostname.domain</from>
<to> actors_manager_username@hostname.domain/producer_*$deviceid*</to>
<subject>prediction</subject>
<body>PREDICTION_UPDATE</body>

4 Task planning

Description

This interface is used to allow users to create, plan and replan tasks. The current implementation store tasks and its parameters into the emoncms databases.

Providing component:

MASModule

Requiring components:

GUI

API description:

The detailed APIs are described in MASModuleAPI .

5 Load planning

Description

This interface is used to manage loads.

Providing component:

Task manager MASModule

Requiring components:

Scheduler (producer and consumer agents)
MASModule

API description:

The detailed APIs are described in TaskManagerAgent.

6 Device management

Description

This interface is used to access device data as well as send control data to devices to control the device behaviour.

Providing component:

Device integration (Device manager)

Requiring components:

Task manager
GUI
Load controller

API description:

The API description can be be found in DeviceManager.

7 Scheduled loads

Description

This interface is used to notify the Load control about the scheduled loads.

When a plan changes, the task manager updates the list of loads to be removed or allocated and eventually asks for their re-scheduling if it is required. In order to compute the best energy schedule, the MAS needs to know the energy profile of the task and the prediction of production of the PV panels. The energy profile is retrieved by the Get task profile action and it is processed to generate a list of loads.

Providing component:

Load controller

Requiring components:

Consumer agent

API description:

The interface is described in Load Controller.

8 Negotiation

Description

This interface is used for negotiation.

In the figure below, a sequence diagram about the agents is shown. A consumer that wants to schedule his consuming tasks brokers the best producer that can offer the required energy, sends a proposal (SLA template) to it, and gets a schedule or a refusal. According to the response it updates the producers ranking and it contacts the next producer if the energy has not been provided. On the other hand, the producer waits for incoming proposals, evaluates the proposal and sends the schedule if it has available energy.

The negotiation protocol is started by a consumer agent each time a new execution is planned for the handled device sending a proposal. The message body of a proposal is a machine readable SLA (Service Level Agreement) template.

Templates used by agents for negotiation define the energy requirements, by the profile discussed above, including user's preferences and constraints (e.g. start date, termination date, cost, etc.). The SLA will complement the energy requirements with the negotiation parties and actual start time.

A producer can eventually withdraw an SLA if its prediction of production change and the negotiation will be restarted by the consumer.

Providing component:

Producer agent

Requiring components:

Consumer agent

API description:

Details are provided in taskscheduler.

9 User and neighbourhood management

Description

This interface is used for user and neighbourhood management. Currently, XMPP is used for neighbourhood management.

Providing component:

User and neighbourhood management

Requiring components:

GUI

API description:

The API description is provided in neighbourhood management API.

10 Neighbourhood data exchange

Description

This interface is used to exchange data between households in the neighbourhood. XMPP messages are used for exchanging data.

Providing component:

User and neighbourhood management

Requiring components:

User and neighbourhood management

The API is described in the NeighborhoodFeeds.

11 Weather data interface

Description

This interface is used to retrieve weather forecast data from weather service provider.

Providing component:

External weather forecast service provider, e.g., yr.no and DWD.

Requiring components:

Prediction

API description:

The prediction will be stored in a CSV file with the format (timestamp,irradiation,additional parameter 1, additional parameter 2,...). timestamp is the UNIX timestamp marking the beginning of the period in which this parameter set is valid. irradiation is the average irradiation predicted for this period in Watts per square-metre. The CSV file name is neighbourhoodID_timestamp.csv, where neighbourhoodID is the acronym of the neighbourhood (KN, CS) and timestamp is the UNIX timestamp at which the prediction has been made. Sample file name: KN_12345678.csv. Household clients can pull the latest prediction via rsync.

12 Price data interface

Description

This interface is used to retrieve price model from external price service provider. In the trial the price model is static and predefined in the contracts with the electricity provider.

Providing component:

Defined in the contracts with the electricity provider.

Requiring components:

Prediction

API description:

The price data will be represented as CSV-Data with first column time, second column cost/kWh.

The entire users´costs are built out of the initially raised installation costs, the fixed yearly costs paid to the local grid provider and the real consumption costs which depend on the individual contract and the consumption time period during a running week and in the quantity as measured in kWh.

The following figure shows an example of a private household tariff overview for Konstanz, in green marked the low, in yellow the high cost times with additionally integrated heat-pump low cost tariff indication.