D2.1 Executive Summary

This document provides a first look at the MAS2TERING technical platform in terms of user stories, technical requirements and high-level architecture. First of all it was necessary to create a list of detailed user stories in order to properly extract technical requirements and draft a high level architecture. Multiple user stories have been defined for each of the three MAS2TERING use cases:

  • Use Case 1 – Secure and effective connection of commercial home energy boxes with smart meter and consumption profile optimization
  • Use Case 2 – District energy management
  • Use Case 3 – Enhancing grid reliability, performance and resilience

The user stories provided in this document must be considered provisional and might evolve during the project lifecycle. The definitive list will be available later in the project as part of the deliverable D6.1 “Detailed use case scenarios”. A list of technical requirements has been identified and extracted from each scenarios related to each user story. For each requirement the consortium identified the type (Functional and Non-Functional), linked it to one (or more) use case and provided a measurable criterion to be used to verify the constraints have been met. Each partner provided technical requirements according to their expertise and responsibilities in the project. A development-tasks list has been defined inside a web-based software management application. For each task a set of technical requirements was associated: the priority associated with the task have been used to prioritize also the technical requirements, identifying the most relevant ones. Cyber security requirements have been taken account analyzing security aspects and attack scenarios related to each specific use case. Another output of this document is an initial view on the high-level architecture of MAS2TERING platform, highlighting the following aspects:

  • Home area network architecture with Telecom Italia Smart Gateway software components and APIs;
  • Multi Agent System architecture outlining the role and the features of each specific agent in the platform;
  • Generic Enablers evaluation in order to reuse or improve components already provided by other FP7 projects (e.g. FINESCE);

D2.1 Table of Contents

  • Executive summary
  • Document Information
  • Table of Contents
  • List of figures
  • List of tables
  • Abbreviations and acronyms
  • 1 Introduction
  • 2 MAS2TERING Use Cases
  • 2.1 Use Case 1-­‐Secure and effective connection of commercial home energy boxes with public DSO smart meter and consumption profile optimization
  • 2.2 Use Case 2-­‐District energy management
  • 2.3 Use Case 3–Enhancing grid reliability, performance, and resilience
  • 3 Selected user stories for Use Case 1
  • 3.1 Energy consumption reduction and energy efficiency enhancement due to the energy information due to energy information awareness and smart technologies for the house
  • 3.2 Energy consumption management: signal coming from the smart grid
  • 3.3 Use of photovoltaic system and storage to improve energy efficiency
  • 4 Selected user stories for Use Case 2
  • 4.1 Distributed Resources managed by the grid through EMS
  • 4.2 Portfolio of virtualized energy assets as aggregated flexibility resources at district or community level
  • 4.3 Demand Side Management through load control of public and private EV charging stations
  • 4.4 An approach to identify and quantify savings relative to district maintenance
  • 4.5 Detection of smart energy components at district level
  • 4.6 Forecasting of energy consumption and production at district level
  • 4.7 Classification and characterization of energy consumers
  • 4.8 Power quality management inside a district
  • 5 Selected user stories for Use Case 3
  • 5.1 Link boxes exploitation to reduce grid losses
  • 5.2 Link boxes exploitation to balance different energy demand and production among districts
  • 5.3 Energy flow balancing between district links
  • 5.4 Optimization of districts equipment
  • 5.5 Voltage and frequency regulation on grid
  • 5.6 Power quality management between districts
  • 6 Technical Requirements
  • 6.1 Technical requirements from EU recommendation and national policies
  • 6.2 Development tasks and related requirements
  • 7 Cyber-­‐security requirements
  • 7.1 Security aspects and attack scenarios from Use Case 1
  • 7.1.1 High-­‐level architecture
  • 7.1.2 Attack scenarios
  • 7.1.3 Requirements
  • 7.2 Security aspects and attack scenarios from Use Case 2
  • 7.2.1 High-­‐level architecture
  • 7.2.2 Attack scenarios
  • 7.2.3 Requirements
  • 7.3 Security aspects and attack scenarios from Use Case 3
  • 7.3.1 High-­‐level architecture
  • 7.3.2 Attack scenarios
  • 7.3.3 Requirements
  • 7.4 Policies and regulations
  • 7.4.1 Belgium
  • 7.4.2 France
  • 7.4.3 Ireland
  • 7.4.4 United Kingdom
  • 8 High-­‐Level Architecture
  • 8.1 CEMS architecture in the home area network
  • 8.2 District Management Architecture
  • 8.3 Multi-­‐Agent platform
  • 8.4 Generic Enablers
  • 8.4.1 Initial Evaluation and selection process of GEs Selection
  • 8.4.2 Example GE Evaluation–Content Based Security
  • 9 Conclusions
  • References
  • APPENDIX 1–Initial user stories database
  • APPENDIX 2–Eandis data access grant for MAS2TERING letter
  • APPENDIX 3–Technical requirements database

D2.1 Highlights

CEMS architecture in the Home area network
The CEMS is a functional component enabling optimization of energy consumption and production in a home environment. It is in charge to interact with connected devices and users, being aware about consumer’s settings and contracts, receiving grid signals. Typical interactions between CEMS and devices are:

  • collection of consumption information,
  • collection of load profiles
  • appliances scheduling
  • devices direct control
  • devices configuration (e.g. of thresholds, etc.).

The CEMS must be also interconnected with the Multi-agent platform to cooperate with the network. The diagram below outlines main connections between the CEMS the devices in the house and the Multi-agent platform.hlaThe Energy@Home alliance reference implementation of CEMS is an open source software called JEMMA (Java Energy ManageMent Application). It can be used to rapidly prototype and deploy smart energy applications at home. Jemma first released (v0.0.1) in October 2013, is based on a CEMS solution developed and validated in the Energy@home trials and its initial code have been developed by Telecom Italia. The diagram below outlines the main layers of the software.jem

The CEMS implementation relies on OSGi (Open Service Gateway Initiative) 4.2 specification, it runs on a variety of refence implementation (Equinox, Felix and ProSyst) and it is strongly based on a Service Oriented Architecture and its component can be easily
deployed and upgraded at runtime using a set of tools provided by Telecom Italia which allows a central Telco operator to remotely manage a population of gateways through cloud services implementing also OSGi Bundle Repository specification. This degree of flexibility in software lifecycle management allows the operator to add features such as an additional protocol support or modules implementing additional business logic. Right now JEMMA implementation provides full support of ZigBee Home Automation
1.2 cluster library included in the ZigBee network manager (also called ZigBee adapter) but it can be easily extended to add support for other protocols.

The communication with the devices is also eased to third parties application thanks to the Device Abstraction Layer implementation (OSGi rfc0196 and rfc0210): it provides a standard way to interact with the devices even without knowing the protocol that the device is using. A device APIs are exposed in a standard way in terms of functionalities it provides. Each device’s functionality is registered as a service in the OSGi environment and each service is enriched with meta-information describing operation, properties and events the device can provide. The Device Abstraction Layer APIs can also be exploited by application running outside the gateway using a REST and WebSocket APIs.

D2.1 Conclusion

The content of this document provides the basis for the future development, simulation and integration tasks in technical work packages (WP2, WP3, WP4, WP5 and WP6). MAS2TERING developers can now rely on:

  • A set of shared user stories for each of 3 use cases;
  • A technical requirements database: the developed components must satisfy these requirements and the fit criterion defined can be used to set-up and configure automated testing utilities.
  • A set of development tasks defined by each task leader, linked with technical requirements priorizing them.
  • A shared high-level view of the architecture: now the role of the components in the Home Area Network and Multi-Agent system platform have been clearly defined.
  • An analysis of security and privacy aspects related to the 3 use cases

Since this is the first deliverable containing those technical details, it is plausible that some of them will be subject to changes during the project lifecycle. Those changes will be present in the coming technical deliverables that will be provided in later project stages.

D2.1 Download Link

mas2tering_deliverable_2-1-platform-technical-requirements

Scroll Up