D2.2 Executive Summary

This deliverable reports on the outcomes of two tasks dedicated to the design of the MAS2TERING monitoring and management hardware and software platforms.

The first part of the deliverable focuses on the design of the monitoring infrastructure and the associated communication architecture. The scope of the monitoring infrastructure is to collect data from the LV grid and communicate it to the optimisation platform for grid management. The focus is therefore on the monitored data that is required by the MAS to carry out the optimisation process.

The monitoring devices that form part of the infrastructure are the smart meter and the Energy Box, that is a home energy management system produced by Telecom Italia (TI), that communicates with home appliances and gives an interface for users to control their appliances through TI’s cloud. Monitored data includes actual consumption and generation, as well as expected use and consumption of smart appliances and technologies of domestic and other users in the local area. Monitoring devices are mapped in a global layout, which also shows how monitored data is used to support the MAS optimisation.

Based on the project objectives and on the use cases, primary attention is given to the design of the Home Area Network (HAN) monitoring and communication infrastructure. This includes specifications of the communication layers available in the Energy Box, enabling interactions between the HAN appliances and smart technologies, the smart meter and the MAS platform.

To support future demonstration activities and business analyses, the defined monitoring layout is also applied to a representative portion of LV grid in the Cardiff area. The real case is used to identify benefits deriving from the additional monitoring and describe them from a qualitative point of view, but also to estimate costs associated with the implementation of the monitoring infrastructure.

The second part of the deliverable focuses on providing the design of the software management platform for LV smart grids. The MAS platform requirements from deliverable D2.1 are first highlighted, then the platform design is documented, and how the platform will be integrated with the other MAS2TERING components is described. Then, the agent types, their roles, behaviors, and interaction are described using the Gaia methodology.

The software management platform is also organized in components; each component provides a collection of classes, functionalities, and services that relate to each other. The platform contains 1) the user interface component; 2) the smart grid model that shall contain a Common Information Model CIM profile for MAS2TERING; 3) the agents component, which contains the agent classes and their behaviors, based on the adapted solution; 4) the constraints and objectives component, which allows devices from the smart grid and agents to model their objectives and constraints for the optimisation algorithms; 5) the communication component, that includes the protocols used by the agents and the description of the message contents, which are defined in D5.3; 6) the security component, that provides agent authentication, agent actions authorization against agent permissions, and message signature and encryption; 7) a utilities component that includes some connectors and integration elements used by the other components.

MAS2TERING also relies on additional components that will be integrated within the final solution. These are the forecasting service and three security components. The Forecaster is provided as a web service and will use current and historical data: current data is collected in the request call of the web service, whereas the historical data is accessed by means of web service calls to the historical data. The security components are also briefly described in this deliverable, and more details are provided in the deliverables D4.1 and D4.2.

Using Gaia methodology, and based on the use cases and the Universal Smart Energy Framework (USEF), four types of agents that will be implemented have been identified. These agents are 1) the Customer Energy Management System (CEMS) that monitors, controls and optimises the flexibility of the prosumer; 2) the Aggregator (AGR) that manages the flexibility produced by a portfolio of prosumers in a local community, and provides flexibility to other participants in the flexibility market. It is an intermediate agent between the prosumer and the Distribution Service Operator (DSO); 3) the DSO, which is responsible of the cost-effective distribution of electricity to end users; 4) the Device agent, which represents the energy-consuming and/or producing systems in the grid. For each of the identified agents a list of protocols and services is provided. These agents are described in more detail in D3.1, where they are also implemented and tested.
Based on the design and the defined agents, the platform requirements (further detailed in D3.1), are mapped into the platform components, to check if all of these requirements are fulfilled by a traceability matrix. Finally, the deliverable is concluded by a deployment schema for the agents and the other components in MAS2TERING.

D2.2 Table of Contents

  • Executive summary
  • Document Information
  • Table of Contents
  • List of figures
  • List of tables
  • Abbreviations
  • Definitions
  • 1 Introduction
  • 1.1 Relationship to Other Deliverables
  • 1.2 Structure of this Document
  • 1.3 Relationship to Standards
  • 2 Grid monitoring HW infrastructure to enable MAS optimisation
  • 2.1 LV grid monitoring
  • 2.1.1 LV grid topology – Radial configuration
  • 2.1.2 Overview on local management scenarios
  • 2.1.3 Monitoring for LV grid and for MAS optimisation
  • 2.1.4 Grid actors and functionalities from the data exchange perspective
  • 2.2 Grid monitoring layout and data
  • 2.2.1 Global LV grid monitoring layout for MAS optimisation
  • 2.2.2 Monitored data
  • 2.3 Monitoring infrastructure design
  • 2.3.1 Home Area Network Platform Design and communication architecture
  • 2.3.2 Non-domestic smart meters & devices
  • 2.4 Cost-benefit analysis of monitoring infrastructure for MAS optimisation
  • 2.5 Use of the monitored data in the MAS optimisation
  • 3 Multi-purpose grid management software platform
  • 3.1 Requirements for the grid management software platform
  • 3.2 MAS platform design
  • 3.2.1 User interface
  • 3.2.2 Smart Grid component
  • 3.2.3 Agents component

D2.2 Highlights

Monitoring for LV grid and for MAS optimisation
This section clarifies the different types of monitoring required at LV grid level and those that will be particularly considered in MAS2TERING. As shown in Table 2, monitoring the LV grid may be required for three different reasons as shown in the table below:

1
In Figure 5, the types of grid monitoring activities are mapped against the MAS2TERING operational phases and the MAS2TERING scope.

2
As seen, monitoring for DSO’s awareness is required during the planning phase, to support DSO’s decisions, but also during the operating phase, for real-time management of the grid, which is only partially considered in MAS2TERING. Both types of monitoring are thoroughly described in Annex A. The core document focuses only on the monitoring that is required to enable the MAS optimisation.
This type of monitoring includes all monitoring devices and related data that are input to the MAS and are required for the optimisation activities. The key technologies required are the smart meter and the Energy Box, both located in the final user premises (both domestic and non-domestic). In this case the monitored data are not required by the DSO only, but by any player involved in the flexibility management activities (the local flexibility aggregators above all). Of course this type of monitoring is also useful to increase the awareness of the DSO on the status of the grid on a close-to-real-time basis, but in this case data is used for grid management (e.g. self-consumption, peak shaving) and congestions prevention. Data provided by grid monitoring devices (e.g. schedules of home appliances, battery levels, etc., as provided by Energy Boxes) and other external information provided by services that are not part of the monitoring infrastructure (e.g. solar radiation, wind speed, price of electricity, expected behavior of end users, etc.) are used by LFAs to predict generation and demand profiles of their customers for a given period of time (e.g. the following 24 hours). During the various phases of the optimisation process the MAS receives this set of data and runs optimisations aimed at re-allocating flexible demand or generation in the most optimal way and respecting grid physical and statutory constraints. The output is a set of smart optimized profiles for all nodes of the analyzed grid, based on the result of market transactions between players (e.g. between DSO and local aggregators) and on the most effective use of the available flexibility. As shown in Figure 5, monitoring for MAS optimisation is required during the planning and validation phases and during the operative phase.
Since MAS optimisation is based on forecasted information, the whole process is repeated at regular intervals and whenever new information is available. In fact, whenever something is expected to change in future (e.g. solar radiation is expected to cease or decrease at a certain time in future) the MAS runs a new optimisation based on the most updated information (applying what is known as receding horizon control). The expected time step for this operation is 15 minutes. The key technologies required for this type of monitoring are the smart meter and the Energy Box in the domestic user’s premises, besides similar devices required by non-domestic users.

[2]: USEF, “USEF: The framework explained,” USEF, 2015.

D2.2 Conclusion

This deliverable reports on the design specifications for the two main components of the MAS2TERING platform: the monitoring infrastructure and the multi-purpose grid management platform based on MAS. The monitoring infrastructure is required to collect data from the end users of the LV grid and provides them as input to the MAS for grid management duties. The two main monitoring devices are the smart meter and the Energy Box, which are deployed in the end user premises and provide data about the actual consumption, generation, and expected use of smart technologies, as illustrated in Figure 25:

1The Energy Box receives data from the smart meter and the smart appliances and technologies in the HAN and communicates them to the MAS through a specific Device agent. This is responsible for monitoring and sending the monitored data to the cloud, and of invoking the Forecasting service for the definition of a consumption plan, which represents the expected consumption of the device based on the end user’s preferences. Once computed, the Device agent sends its plan to the CEMS Agent, which communicates with the Aggregator agent that in turn communicates with the DSO agent. The process is further detailed in the deployment schema.

2Figure 26 illustrates the deployment schema for MAS2TERING platform, to be developed in the technical WPs of the project based on the requirements specified in the previous deliverable (D2.1), and the platform design provided in this deliverable. The schema can be summarised as follows:

  • At the home level:
    • The energy box hosts the CEMS and the Device agents, each representing a smart appliance/technology.
    • Device agents communicate among each other and with the CEMS using the Zigbee standardised communication.
    • The Device agent accesses the Forecasting web service through the access point (which provides internet access), and sends information about the expected use and the flexibility of the device it represents to the CEMS.
    • The Device agent sends monitored data (actual consumption and generation of the prosumer) to the historical data server.
  • The CEMS sends consumption plans to the Aggregator agent, which is hosted in the cloud.
  • After receiving the plans from the CEMS belonging to the end users of the local community, the Aggregator agent communicates with the DSO agent to validate these plans or ask for a modification.
  • The DSO agent sends a response to the Aggregator agent, which in turn sends the updated plans to the CEMS.

All the agents will be deployed in a JADE platform, which allows communication based on different protocols (see D5.3) and considering security aspects in their connections (see D4.1 and D4.2).

D2.2 Download Link

mas2tering_deliverable_2-2_platform-design-document