D1.3 – Interoperability and Integration Analysis and ...Grant Agreement No.: 773715 Project...

Grant Agreement No.: 773715

Project acronym: RESOLVD

Project title: Renewable penetration levered by Efficient Low Voltage

Distribution grids

Research and Innovation Action

Topic: LCE-01-2016-2017

Next generation innovative technologies enabling Smart Grids, storage and

energy system integration with increasing share of renewables: distribution

network

Starting date of project: 1st of October 2017

Duration: 36 months

D1.3 – Interoperability and Integration Analysis and Requirements

DISCLAIMER This document reflects only the author's view and the Agency is not responsible for any use that

may be made of the information it contains.

Organization name of lead contractor for this deliverable: ICOM

Due date: M12 - 30th of September 2018

Submission Date: 30th of September 2018

Primary Authors Isidoros Kokos, Kostas Tsakalos, Ilias Lamprinos (ICOM)

Contributors Luisa Candido, Ramon Gallart ( EyPESA) Francesc Girbau, Andreas Sumper, Francisco Diaz, Mònica Aragüés (UPC) Joaquim Melendez, Ferran Torrent (UdG) Miha Smolnikar, Marko Mihelin (CS)

Version 1.0 Final Version

Dissemination Level

PU Public X

CO Confidential, only for members of the consortium (including the Commission Services)

2

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grand agreement No 773715

Deliverable reviews

Contributions of partners

Description of the contribution of each partner organisation to the work presented in the deliverable.

Partner Contribution

UdG Annex I: SGAM Models of HLUC 01, 08 - PUC 01- 04, 06, 11, 14-16 Intermediate reviews

UPC Annex I: SGAM Models of HLUC 02, 03, 07 - PUC 08-10, 12,13 Annex II: Standards review Intermediate reviews

SIN - JR Final review of the document

ICOM

Chapters 1-5 Annex I: SGAM Models of HLUC 04, 06 - PUC 05, 27 Annex II: Standards review Overall redaction of document

EYPESA

Annex I: SGAM Models of HLUC 09 - PUC 17-19 Annex II: Standards review Intermediate reviews Final review of the document

CS Annex II: Standards review

Revision table for this deliverable:

Version 0.2

Reception Date

19 of September 2018

Revision Date


Reviewers Stefan Marksteiner (JR)

Version 0.3 Reception Date


Revision Date


Reviewers Ilias Lamprinos (ICOM)

3


Table of contents

Acronyms and abbreviations ......................................................................................................... 7

Executive Summary ...................................................................................................................... 9

1. Introduction........................................................................................................................... 10 1.1. RESOLVD Project ......................................................................................................... 10 1.2. Scope of the reported work ........................................................................................... 10 1.3. Report structure ............................................................................................................ 11

2. Interoperability Analysis with SGAM .................................................................................... 12 2.1. Introduction to SGAM .................................................................................................... 12

2.1.1. Smart Grid Conceptual Model ............................................................................... 12 2.1.2. Interoperability Layers ........................................................................................... 13 2.1.3. Smart Grid Plane ................................................................................................... 14 2.1.1. SGAM Framework ................................................................................................. 16 2.1.2. Use Cases in the SGAM ........................................................................................ 17

2.2. SGAM Toolbox .............................................................................................................. 18 2.2.1. Introduction ............................................................................................................ 18 2.2.2. Modelling process .................................................................................................. 19

2.2.2.1. System Analysis Phase .................................................................................... 19 2.2.2.2. System Architecture Phase .............................................................................. 19 2.2.2.3. Design and Development Phase ...................................................................... 19

2.3. Modelling Process Applied in RESOLVD ..................................................................... 20 2.3.1. Use Case Analysis ................................................................................................. 20 2.3.2. Mapping UCs to the SGAM ................................................................................... 20

2.4. Interoperability Analysis ................................................................................................ 21 2.4.1. Actors ..................................................................................................................... 21 2.4.1. Use Cases ............................................................................................................. 24 2.4.2. Components .......................................................................................................... 25 2.4.3. Results ................................................................................................................... 26

2.4.3.1. Components’ layout .......................................................................................... 26 2.4.3.2. Functions’ layout ............................................................................................... 26 2.4.3.1. Communication technologies and links ............................................................ 27 2.4.3.2. Information Interoperability ............................................................................... 27

3. Integration Analysis .............................................................................................................. 31 3.1. Introduction ................................................................................................................... 31 3.2. Integration Framework .................................................................................................. 32 3.3. Interoperability through Standards ................................................................................ 33 3.4. RESOLVD Approach .................................................................................................... 34 3.5. Integration Elements ..................................................................................................... 35

3.5.1. Enterprise Service Bus .......................................................................................... 35 3.5.1.1. Overview ........................................................................................................... 35 3.5.1.2. Features ........................................................................................................... 35 3.5.1.3. Related Technologies ....................................................................................... 37

3.5.2. Data Management, Analysis and Visualization ..................................................... 37 3.5.2.1. Overview ........................................................................................................... 37 3.5.2.2. Features ........................................................................................................... 37

4. RESOLVD Architecture ........................................................................................................ 39 4.1. Context View ................................................................................................................. 39 4.2. Component View ........................................................................................................... 40 4.3. Deployment View .......................................................................................................... 41 4.4. Standards View ............................................................................................................. 41

5. Conclusions .......................................................................................................................... 43

4


Annex I: Mapping Use Cases to SGAM ...................................................................................... 44

6. SGAM Analysis .................................................................................................................... 46 6.1. BUC Analysis ................................................................................................................ 46

6.1.1. BUC 01: Ensuring grid safety through real-time observability intelligent power electronics devices ............................................................................................................... 46 6.1.2. BUC 02: Ensuring continuity of supply through dynamic network reconfiguration 47 6.1.3. BUC 03: Minimizing/delaying investment for network upgrade through smart grid-operation .............................................................................................................................. 47 6.1.4. BUC 04: Reducing technical losses through power electronics and local storage 49 6.1.5. BUC 05: Detecting non-technical losses (frauds) through advanced sensors and data analytics ....................................................................................................................... 50 6.1.6. BUC 06: Improving power quality through power electronics................................ 51

6.2. HLUC Analysis .............................................................................................................. 53 6.2.1. HLUC01: Prevention of congestion and over/under voltage issues through local storage utilization and grid reconfiguration .......................................................................... 53 6.2.2. HLUC02: Voltage control through local reactive power injection .......................... 57 6.2.3. HLUC03: Improving power quality and reducing losses through power electronics 60 6.2.4. HLUC04: Local storage utilization to reduce power losses ................................... 62 6.2.5. HLUC05: Self-healing after a fault ......................................................................... 67 6.2.6. HLUC06: Power management in intentional and controlled-island mode ............. 69 6.2.7. HLUC07: Detection and interruption of unintentional uncontrolled island-mode .. 73 6.2.8. HLUC08: Detection of non-technical losses .......................................................... 75 6.2.9. HLUC09: Planning of the commissioning of power electronics device and local storage 77

6.3. PUC Analysis ................................................................................................................ 82 6.3.1. PUC01: Demand and generation forecasting ........................................................ 82

6.3.1.1. Details ............................................................................................................... 82 6.3.1.2. Step by step analysis ....................................................................................... 83 6.3.1.3. SGAM Layers ................................................................................................... 86

6.3.2. PUC02: Power flow simulation .............................................................................. 89 6.3.2.1. Details ............................................................................................................... 89 6.3.2.2. Step by step analysis ....................................................................................... 89 6.3.2.3. SGAM Layers ................................................................................................... 91

6.3.3. PUC03: Critical event forecasting .......................................................................... 93 6.3.3.1. Details ............................................................................................................... 93 6.3.3.2. Step by step analysis ....................................................................................... 94 6.3.3.3. SGAM Layers ................................................................................................... 95

6.3.4. PUC04: Grid Operation scheduling ....................................................................... 97 6.3.4.1. Details ............................................................................................................... 97 6.3.4.2. Step by step analysis ....................................................................................... 98 6.3.4.3. SGAM Layers ................................................................................................. 100

6.3.5. PUC05: Grid Operation Schedule Dispatch ........................................................ 102 6.3.5.1. Details ............................................................................................................. 102 6.3.5.2. Step by step analysis ..................................................................................... 103 6.3.5.3. SGAM Layers ................................................................................................. 104

6.3.6. PUC06: LV grid observability and monitoring ...................................................... 107 6.3.6.1. Details ............................................................................................................. 107 6.3.6.2. Step by step analysis ..................................................................................... 108 6.3.6.3. SGAM Layers ................................................................................................. 112

6.3.7. PUC07: Data pre-processing ............................................................................... 115 6.3.7.1. Details ............................................................................................................. 115 6.3.7.2. Step by step analysis ..................................................................................... 116 6.3.7.3. SGAM Layers ................................................................................................. 119

6.3.8. PUC08A: Collecting electrical data locally by the PED ....................................... 122 6.3.8.1. Details ............................................................................................................. 122 6.3.8.2. Step by step analysis ..................................................................................... 124 6.3.8.3. SGAM Layers ................................................................................................. 126

5


6.3.9. PUC08B: Collecting external electrical data by the PED .................................... 127 6.3.9.1. Details ............................................................................................................. 128 6.3.9.2. Step by step analysis ..................................................................................... 129 6.3.9.3. SGAM Layers ................................................................................................. 131

6.3.10. PUC 09: Local reactive power management for voltage regulation ................ 132 6.3.10.1. Details ........................................................................................................... 132 6.3.10.2. Step by step analysis ................................................................................... 135 6.3.10.3. SGAM Layers ............................................................................................... 137

6.3.11. PUC10: Local active and reactive power management to correct power quality issues 140

6.3.11.1. Details ........................................................................................................... 140 6.3.11.2. Step by step analysis ................................................................................... 142 6.3.11.3. SGAM Layers ............................................................................................... 143

6.3.12. PUC11: Fault detection and localization .......................................................... 145 6.3.12.1. Details ........................................................................................................... 145 6.3.12.2. Step by step analysis ................................................................................... 146 6.3.12.3. SGAM Layers ............................................................................................... 147

6.3.13. PUC12: Detection of uncontrolled island-mode ............................................... 149 6.3.13.1. Details ........................................................................................................... 149 6.3.13.2. Step by step analysis ................................................................................... 150 6.3.13.3. SGAM Layers ............................................................................................... 152

6.3.14. PUC13: Interruption of uncontrolled island-mode ............................................ 154 6.3.14.1. Details ........................................................................................................... 154 6.3.14.2. Step by step analysis ................................................................................... 155 6.3.14.3. SGAM Layers ............................................................................................... 156

6.3.15. PUC15: Individual Consumption Modelling ..................................................... 158 6.3.15.1. Details ........................................................................................................... 159 6.3.15.2. Step by step analysis ................................................................................... 159 6.3.15.3. SGAM Layers ............................................................................................... 160

6.3.16. PUC16: Consumption monitoring .................................................................... 162 6.3.16.1. Details ........................................................................................................... 162 6.3.16.2. Step by step analysis ................................................................................... 163 6.3.16.3. SGAM Layers ............................................................................................... 164

6.3.17. PUC 17: Grid information data collection ......................................................... 166 6.3.17.1. Details ........................................................................................................... 166 6.3.17.2. Step by step analysis ................................................................................... 167

6.3.18. PUC 18: Analysis of present power measurements ........................................ 168 6.3.18.1. Details ........................................................................................................... 168 6.3.18.2. Step by step analysis ................................................................................... 169

6.3.19. PUC 19: Assessment of suitable location for power electronics device .......... 170 6.3.19.1. Details ........................................................................................................... 170 6.3.19.2. Step by step analysis ................................................................................... 171

6.3.20. PUC 27 : Orchestration .................................................................................... 172 6.3.20.1. Details ........................................................................................................... 172 6.3.20.2. Step by step analysis ................................................................................... 173 6.3.20.3. SGAM Layers ............................................................................................... 176

Annex II: Standards Review ...................................................................................................... 180

7. Introduction......................................................................................................................... 180 7.1. Information Standards ................................................................................................. 180

7.1.1. Common Information Model (CIM) ...................................................................... 180 7.1.2. IEC 61968 ............................................................................................................ 181 7.1.3. IEC 62056 ............................................................................................................ 182 7.1.4. IEC 60870 ............................................................................................................ 183 7.1.5. IEEE C37.118.2-2011 .......................................................................................... 183 7.1.6. IEEE C37.239-2010 ............................................................................................. 184 7.1.7. IEEE C37.111-2013 / IEC 60255-24:2013 .......................................................... 184

7.2. Communication Standards.......................................................................................... 184

6


7.2.1. PRIME ................................................................................................................. 184 7.2.2. MODBUS ............................................................................................................. 184 7.2.1. CAN Bus .............................................................................................................. 185

References ................................................................................................................................ 186

7


Acronyms and abbreviations

AMI Advanced Metering Infrastructure

AMI HES Advanced Metering Infrastructure Head-End System

BMS Battery Management System

CAPEX Capital Expenditures

CEF Critical Event Forecaster

CIM Common Information Model

DCU Data Concentrator Unit

DER Distributed Energy Resource

DG Distribution Generation

DMS Distribution Management System

DSO Distribution System Operator

EF Energy Forecaster

FDA Fault Detection Application

GM Grid Meter

GIS Geographic Information System

GOS Grid Operation Scheduler

GW Gateway

HLUC High-Level Use Cases

ICT Information and Communication Technology

IEC International Electrotechnical Commission

IED Intelligent Electronic Device

ILEM Intelligent Local Energy Manager

JMS JAVA Messages Services

KPI Key Performance Indicator

MDA Model Driven Architecture

MDMS Meter Data Management System

NTLFDA Non-Technical-Loss-Fraud Detection Application

OMS Outage Management System

OPEX Operative Expenses

PCA Principal Component Analysis

PCS Power Conversion System

PED Power Electronic Device

PFS Power Flow Simulator

PMU Phasor Measurement Unit

PRIME PoweRline Intelligent Metering Evolution

pub-sub publish - subscribe

PUC Primary Use Case

PQM Power Quality Monitoring

RMS Root Mean Square

RTU Remote Terminal Unit

SCADA Supervisory Control and Data Acquisition system

SG Smart Grid

SGAM Smart Grid Architecture Model

SGCG Smart Grid Coordination Group

SM Smart Meter

SoC State of Charge

UC Use Case

8


UML Unified Modelling Language

WAMS Wide Area Monitoring System

9


Executive Summary

The RESOLVD project aims at increasing the observability and controllability of Low Voltage (LV) electricity distribution networks with the use of innovative ICT, power electronic and sensor infrastructures. This report presents the results of the work done in Task 1.3 “Interoperability and integration analysis and requirements”. It builds on Use Case (UC) analysis documented in D1.1 – “Use cases definition” and the requirements analysis documented in D1.2 – “Functional and operational requirements” and addresses the presentation of the overall architecture of the project and how integration and interoperability aspects of the solution are tackled.

The work performed during interoperability analysis is based on the proven framework and methodology of the Smart Grid Architecture Model (SGAM), which is described in the Smart Grid Reference Architecture provided by the CEN-CENELEC-ETSI Smart Grid Coordination Group. SGAM uses a three dimensional model that merges the dimension of five interoperability layers (Business, Function, Information, Communication and Component) with the two dimensions of the Smart Grid Plane: the zones, which represent the hierarchical levels of Power System management, and the domains, which cover the complete electrical energy conversion chain. The framework offers the ability to assess Smart Grid (SG) use cases, in terms of supported standards, from different architectural viewpoints, representing the different stakeholders’ views of a SG system, related to: market / business model and business services, functional architectures, data models and interfaces and communications standards. It also offers the ability to identify relevant standardization gaps.

The UCs defined in the project were analysed following a methodology adapted from SGAM framework and the SGAM toolbox, a tool that implements basic concepts of the SGAM reference architecture and helps in the modelling Smart Grid use cases in SGAM. The SGAM analysis task entailed the identification of the most appropriate communication and information standards in the domain, constrained by the relevant standards utilized by the legacy systems of the project. For the reader’s convenience, the results of the SGAM analysis are “aggregated” in top-views per layer, allowing a high-level overview of the results of the analysis.

This report also introduces the integration middleware of RESOLVD and the tools related to data management, analysis and visualization. Following the work of D1.2, a more comprehensive view of these architectural elements - which were introduced for achieving a smooth integration among the newly developed systems, devices and applications, with the legacy ones - is presented. The methodology followed towards achieving this is also presented in the report.

Combining the results of the above analysis, the architecture description of the project is formulated, presenting the architectural elements of RESOLVD and how they function and interrelate to each other and to the DSO’s environment, as well as the principles of the system’s organization.

In order to cover different stakeholders views, multiple architecture views are presented, following the guidelines of ISO/IEC/IEEE 42010:2011 “Systems and software engineering—Architecture description”.

Annexed to this report, the reader can find the results of the SGAM analysis on an individual UC basis, presenting the different SGAM layers as well as the UC analysis results. Finally, a small review of the communications and information standards utilized in the project is presented, pinpointing the use of each one of the with the project implementation phase.

10


1. Introduction

1.1. RESOLVD Project The objective of RESOLVD project is to improve the efficiency and the hosting capacity of distribution networks, in the context of highly distributed renewable generation by introducing flexibility and control in the low voltage grid.

An innovative advanced power electronics device, with integrated storage management capabilities will provide both switching and energy balancing capacities to operate the grid optimally. Continuous power flow control between storage and the grid, and also between phases, will result in a flatter and reduced demand curve at the substation level with an associated loss reduction and an improved voltage control and quality of supply.

The enhanced observability of RESOLVD, provided through cost-effective PMUs and state-of-the-art short-term forecasting algorithms that predict demand and renewable generation, will permit a reduction of uncertainty in grid operation and an increased efficiency. RESOLVD proposes hardware and software technologies to improve low voltage grid monitoring with wide area monitoring capabilities and automatic fault detection and isolation.

This improved observability and monitoring system combined with the capability of actuating on the grid will benefit from robust scheduling methods to support self-healing and grid reconfiguration, hence allowing efficient grid operation and a maximised renewable hosting capacity.

1.2. Scope of the reported work The objective of this report is on one side to present the project’s architecture, detailing the components developed in RESOLVD and interrelations among each other and with legacy systems. On the other side, it aims to present the results of the interoperability analysis realized through SGAM as well as the integration analysis, which is based on the requirements of the RESOLVD components and the results of the interoperability analysis, establishing the maximum level of interoperation. The latter signifies the capacity of the solution to operate in a realistic environment and guarantees its replicability.

The content of this report is of interest for technical staff (e.g. software architects, requirements engineers) who want to understand the decisions and integration aspects of RESOLVD project and/or to proceed with the detailed design of the components of the system, but also for domain experts who seek for reusable and interoperable solutions, capable to be transferred in other projects. Finally, the report addresses the needs of other parties such as managers who might find of interest the high-level architecture of the project along with its interoperability and integration approach.

The work depicted in this report was realized in the context of the task T1.3 “Interoperability and integration analysis and requirements” and is highly related to previous work of the project. More specifically with D1.1 “Use cases definition”, which provides the definition of the project’s Use Cases (UCs) and actors to be analysed in the current report, as well as with D1.2 “Functional and operational requirements” [1], which provides the list of components to be developed or integrated in the project and their functional and non-functional requirements. The former deliverable has restricted access, hence a brief description of the UCs and the actors involved is provided in the current deliverable. In order to fully apprehend the analysis included in this report, the reader should also access the detailed requirements of the identified components, presented in D1.2.

Towards reaching the objective of the task, the adopted methodology involved the modelling of use cases (i.e. High-Level Use Cases - HLUCs and Primary Use Cases – PUCs) with the use of SGAM framework, in order to identify any interoperability problems or standardization gaps. This task entailed the identification of the most appropriate communication and information standards in the domain, constrained by the relevant standards utilized by the legacy systems of the project. The methodology employed follows the general guidelines of the Smart Grid Coordination Group (SGCG) [2] and is closely related to the methodology proposed in SGAM Toolbox [3], a tool for modelling UCs in SGAM. The models that resulted from the SGAM framework analysis provided

11


a fair introduction to the project’s architecture, utilizing views of different stakeholders. Following the interoperability analysis, an integration analysis took place. The standards identified in the former analysis, the supported interfaces with legacy systems and the requirements of the developed components, were utilized to tackle integration issues at different levels – application, information and network. Integration components – the Enterprise Service Bus (ESB) and the tools related to data management, analysis and visualization - were also identified. Finally, by consolidating the different layers of SGAM among UCs, whilst introducing the integration components, different views of the architecture of the project are documented to cover the viewpoints of different stakeholders, providing the architectural description of the project.

1.3. Report structure Chapter 1 provides an introduction to the project, the scope and objective of the report as well as the followed methodology, along with the contribution of each partner. Chapter 2 focuses on interoperability analysis with the use of SGAM. To achieve this, initially a brief introduction to SGAM is presented, explaining the basic concepts and the methodology of SGAM. Following this, the SGAM toolbox and its methodology is presented and how it was adapted to the needs of the project. Finally, the aggregated results of the analysis are presented. Chapter 3 illustrates the outcome of the integration analysis, describing the integration artefacts, the ESB and the tools related to data management, analysis and visualization as well as introduces the followed methodology. Chapter 4 presents the architecture of the project, utilizing different views and covering different perspectives. Annex I provides a detailed mapping of Use Cases (both HLUCs and PUCs) to SGAM layers. Finally, Annex II provides a brief overview of the standards that will be utilized or are under consideration for utilization in the project.

12


2. Interoperability Analysis with SGAM

2.1. Introduction to SGAM SGAM aims at offering support for the design of Smart Grids use cases with an architectural approach allowing for a representation of interoperability viewpoints in a technology-neutral manner, both for current implementation of the electrical grid and future implementations of the Smart Grid. The model and the relevant framework and methodology, which is described in the Smart Grid Reference Architecture provided by the CEN-CENELEC-ETSI Smart Grid Coordination Group [2], is a three-dimensional model that merges the dimension of five interoperability layers (Business, Function, Information, Communication and Component) with the two dimensions of the Smart Grid Plane, i.e. zones (representing the hierarchical levels of Power System management: Process, Field, Station, Operation, Enterprise and Market) and domains (covering the complete electrical energy conversion chain: Bulk Generation, Transmission, Distribution, DER and Customers Premises).

The associated SGAM methodology [2], offers the ability to use the framework for assessing Smart Grid use cases and whether they are supported by standards, whilst the different architectural viewpoints (Business, Functional, Information and Communication), represent abstraction of the different stakeholders’ views of a SG system: ensuring consistency and coherency of market / business model and business services, validating functional architectures, verifying the applicability of data models and interfaces, as well as checking the adequacy of existing communications standards and identifying relevant standardization gaps.

In order to better understand SGAM, one must first trace back to some basic concepts of the Smart Grid domain:

The European Conceptual Model and how it evolved from the Smart Grid model proposed by NIST;

The interoperability layers and their origins;

The concept of the Smart Grid Plane, the two-dimensional space representing the different physical domains and Power Systems management levels of the Smart Grid.

The concepts are analysed in the following subchapters, prior to the introduction of the SGAM framework.

Figure 1 NIST Conceptual Model

2.1.1. Smart Grid Conceptual Model The National Institute of Standards and Technology (NIST) has introduced the Smart Grid Conceptual Model which provides a high-level framework for the Smart Grid [4]; it defines seven high-level domains and shows all the communications and energy/electricity flows connecting each domain and how they are interrelated. In Figure 1, the most up-to-date conceptual model is presented, whilst an earlier version was available at the time SGAM was developed. In addition,

13


Table 1 provides the definition of the different concepts of the model: Generation1, Transmission, Distribution, Customer, Service Provider, Operations and Markets. These concepts are also utilized in the definition of SGAM framework.

Based on the NIST model, the EU Conceptual Model was constructed, being extended to fulfil specific European requirements, with the major difference being the introduction of the DER Domain (see Figure 2).

Table 1 Domains and Roles/Services in the Smart Grid Conceptual Model [4]

Figure 2 EU extension of the NIST Model [2]

2.1.2. Interoperability Layers Interoperability refers to the ability of two or more devices from the same vendor or different vendors, to exchange information and use that information for proper co-operation. In other words, two or more systems (devices or components) are interoperable, if the two or more systems are able to perform cooperatively a specific function by using the information that is exchanged [2].

1 Bulk Generation in the previous version of the NIST conceptual model.

14


Figure 3 SGAM Interoperability Layers (right) and their relation with the interoperability model proposed by the GridWise Architecture Council (left)

The GridWise Architecture Council [5] proposed different levels of interoperability, therefore introducing a widely accepted methodology to describe requirements for achieving interoperability between systems or components. The proposed categories are as follows:

Organizational interoperability, further divided in interoperability concerning economic, regulatory, policy, and business objectives.

Informational interoperability, divided in business context and semantic understanding interoperability.

Technical interoperability, divided in syntactic, network and basic connectivity interoperability.

Apart from this individual categorization, the Council also defined cross cutting issues - topics that affect more than one interoperability levels (e.g. cybersecurity, performance).

The SGAM framework addresses interoperability, by aggregating the interoperability categories of the GridWise model, into five abstract interoperability layers, namely Business, Function, Information, Communication and Component. The relation of the GridWise model with the SGAM approach is presented in Figure 3. All the layers are defined in detail in [2] so only a brief introduction follows:

Business Layer: Represents the business view on the information exchange related to Smart Grids; appropriate for mapping regulatory and market structures and policies, business models products & services;

Function Layer: Describes functions and services including their relationships from an architectural viewpoint;

Information Layer: Concerns the information used and exchanged between functions, services and components; appropriate for establishing the common semantics for interoperable information exchange;

Communication Layer: Describes protocols and mechanisms for the exchange of information among interoperable systems;

Component Layer: Describes the physical distribution of all participating components in the Smart Grid context.

2.1.3. Smart Grid Plane The Power System is a complex system incorporating processes both in the physical domain of the electrical energy conversion chain and in the hierarchical zones (or levels) of information management related to the electrical process. These different viewpoints can be mapped in a two-dimensional conceptual model, the Smart Grid Plane (see Figure 4), which enables the representation on which levels (hierarchical zones) of Power System management, interactions

15


between domains take place.

One axis of the Smart Grid plane contains the Smart Grid domains which are physically related to the electrical grid (Generation, Transmission, Distribution, DER and Customer Premises, arranged according to the electrical energy conversion chain. The different domains and their description are presented in Table 2.

The second axis of the Smart Grid plane contains the zones, which represent the hierarchical levels of Power System management, based on the concept of aggregation and functional separation. The concept of aggregation concerns both spatial as well as data aggregation (e.g. data from the field zone is usually aggregated or concentrated in the station zone in order to reduce the amount of data).

The conceptual domains Operations and Market are part of the information management and represent specific hierarchical zones, whilst the conceptual domain of Service Provider, which represents a group of actors having a universal role in the context of Smart Grid, can be located at any segment of the Smart Grid plane. Apart from the Operation and Market zones, four more zones are introduced, namely the Process, Field, Station and Operation zones. The description of the SGAM zones is given in Table 3.

Figure 4 Smart Grid plane [2]

Table 2 SGAM Domains [2]

16


Table 3 SGAM Zones [2]

2.1.1. SGAM Framework The SGAM framework is established by merging the concept of the interoperability layers with the Smart Grid plane. This merge results in a model which spans three dimensions: Domain, Interoperability (Layer) and Zone, as presented in Figure 5. The SGAM introduces interoperability aspects and how they are taken into account via a domain, zone and layer based approach. It allows for a holistic representation of entities and their relationships in the context of Smart Grid domains, detailing information management hierarchies and enabling the consideration of interoperability aspects.

Figure 5 The SGAM Framework

SGAM is based on the following principles:

17


Universality: The model is solution and technology agnostic, and gives no preferences to existing architectures;

Localization: The model places entities to the appropriate location in the Smart Grid plane and layer respectively;

Consistency: Absence of an entity in one or more SGAM layer(s) implies that there is no specification (data model, protocol) or component available. Consistency ensures that the five layers are unambiguously linked; interoperability ensures that the conditions for interaction (interfaces, specifications, standards) are met within each layer

Flexibility: The model allows alternative designs and implementations of use cases;

Scalability: The model allows a localized view to specific domain and zones;

Extensibility: Ability to extend the SGAM by adding new domains and zones;

Interoperability: Consistent representation of entities, interfaces, data models (information layer) and protocols (communication layer). Following the concept of interoperability categories (introduced in section 2.1.2), cross - cutting issues (e.g. cybersecurity) apply in the same manner to the abstract interoperability layers.

2.1.2. Use Cases in the SGAM The document describing SGAM [2], also proposes a process for mapping use cases to SGAM framework, as depicted in Figure 6. Use case analysis is the preliminary imperative step in the system analysis process, followed by a subsequent phase of use cases mapping into the SGAM architecture, which finally leads to a complete architecture model.

Figure 6 Use case mapping process to SGAM

Use case definition and analysis traditionally follows a predefined template that is utilized to provide a uniform way of execution and documentation of the consecutive steps. Based on the standard defined in [6] by the International Electrotechnical Commission (IEC) the SGCG/SP (Sustainable Processes Working Group) provided three different versions of use case template [7]: short, general and detailed. The general version entails the basic information of the use case, which are the narrative, the actors list and the conditions, as well as additional fields such as the relation to other use cases, the viewpoint, and scope & objective. The different perspectives, business or technical, of the use case can be defined by using the viewpoint attribute. In addition, the detailed version contains a step-by-step analysis of information exchanges and requirements. The short template can be used to document use case concepts, providing information in the narrative of the use case, supported by diagrams.

In the guidelines for SGAM framework usage [8], the SGCG indicates a mapping of information present in their use case analysis template to the SGAM (Figure 7), depicting how different requirements in terms of interoperability (vertical axis) and with different levels of abstraction (horizontal axis) can be documented.

18


In the proposed process, the Component Layer is derived from the use case information on actors, placing the relevant component in association to the domain and zone of the actor. Accordingly, business entities are located to the appropriate domain and zone and modelled in business cases in the Business Layer.

The subsequent construction of the Function Layer intends to represent functions and their interrelations in respect to domains and zones, based on the functionalities described in the use cases.

Finally, the Information and Communication Layers are created, depicting the information object elicited by the use case analysis steps and the canonical data models that were identified by the analysis of standards, protocols and mechanisms that are relevant to the interoperable exchange of information between the use case actors to the domain and zone in use.

Figure 7 Mapping of information present in the SGCG use case analysis template to the SGAM

2.2. SGAM Toolbox

2.2.1. Introduction The SGAM toolbox [3] is a tool that implements basic concepts of the SGAM Reference Architecture and helps in the modelling of Smart Grid use case in SGAM. It is provided as an extension for the modelling tool Enterprise Architect (EA) from Sparx Systems [9] providing template models and semantics (within EA) which facilitate the creation of SGAM layers inside EA. The modelling process supported by the SGAM toolbox is inspired by the SGAM Framework and Model Driven Architecture (MDA), which separates the development process into three phases:

System Analysis Phase;

System Architecture Phase;

Design and Development Phase.

Based on the MDA, the different development aspects are modelled with different artefacts over four different layers, with specific transformations in between:

Computational Independent Model: Provides a functional description of a system without mentioning any technological aspect;

Platform Independent Model: Decomposes the system that is not yet linked to any specific technology or platform;

19


Platform Specific Model: Combines the specifications in the PIM with the details required to stipulate how a system uses a particular type of platform or technology, providing a detailed design;

Platform Specific Implementation: Implementation of the detailed design of the system.

The discrete phases of the above methodology are briefly presented in the following subchapters, whilst a high-level depiction is provided in Figure 8. Further info is available at [10].

Figure 8 Smart Grid use cases modelling process supported by the SGAM Toolbox

2.2.2. Modelling process

2.2.2.1. System Analysis Phase This initial phase aims at defining the particular functionalities to be delivered by a certain system. Initially, the Business Analysis is performed, which involves the identification of Business Actors (physical, legal or regulatory entities) and their particular Business Goals. Their interactions towards achieving their goal are documented in Business Cases. Subsequently to the Business Analysis, a Model Transformation is conducted, defining the High Level Use Cases (HLUC), which cover the functionality necessary to fulfil the originating Business Cases. Furthermore, Logical Actors, logical entities involved in a particular HLUC, are derived from the Business Actors. The following task is the Functional Specification, which deals with detailing the identified HLUC using a Use Case template, whilst at this phase HLUCs are decomposed into several Primary Use Cases (PUC), which are also analysed by means of standard Unified Modelling Language (UML) mechanisms such as Sequence Diagrams or Activity Diagrams, identifying Information Objects as well. The outcome of this phase is the Computational Independent Model, containing the Business Model corresponding to the SGAM Business Layer, and the Functional Model represented by the SGAM Function Layer.

2.2.2.2. System Architecture Phase During this phase, the identification and description of particular components and their interrelations for realizing the previously defined functionality takes place. As first task, a Model Transformation aims at mapping the prior described Logical Actors onto Physical Components. The second task of this phase, the Domain Specific Architecture Development aims at specifying the interrelations between particular components. These interrelations are described on the basis of the lower three SGAM layers, i.e the SGAM Information Layer (information exchange from a logical perspective), the SGAM Communication Layer (protocols used for communication) and the SGAM Component Layer (description of the ICT networks used for communication). The outcome of this task is the Platform Independent Model, represented by the SGAM Component/Information/Communication Layer.

2.2.2.3. Design and Development Phase

20


This final phase aims at realizing the particular components and integrating them into a complete solution. In terms of the MDA, this phase yields a detailed design (Platform Specific Model) and the corresponding implementation (Platform Specific Implementation).

2.3. Modelling Process Applied in RESOLVD The use case modelling process applied in RESOLVD is presented in deliverable D1.1, but due to access restrictions of this deliverable, it is briefly presented in the following subchapters.

2.3.1. Use Case Analysis The methodology adopted by RESOLVD is based on the guidelines of use case analysis provided by the Smart Grid Coordination Group (SGCG) [2], and follows the example of the SmarterEMC2 project [11], modified and adapted to the scope of RESOLVD. As presented in [8], we discriminate among use cases on the basis of:

1. Business Use Cases (BUCs), which describe business processes that the actors of a given system must or may execute. These processes are derived from roles which have been previously identified and analysed; there is no technical view.

2. Technical Use Cases (TUCs), which are further subdivided to: a. Concepts (or High-Level Use Cases, HLUC) which describe the general idea of

a function together with generic actors. b. Device/System Use Cases (or Primary Use Cases, PUC): A use case

implemented in a specific system characterized by a defined boundary (i.e. it can be mapped on a defined architecture).

The use cases are analysed following the template of [12]- Part 2: “Definition of the templates for use cases, actor list and requirements list” and the work of SGCG (i.e. [8]). The steps for documenting the use cases in the template are:

1. Use case description: Details the name of the use case, version management, scope and objectives, short narrative, actor list, conditions and Key Performance Indicators;

2. Technical details: Presents a detailed narrative and use case diagrams; 3. Step by step analysis: Details scenarios, scenarios’ steps, sequence diagrams and

activity diagrams; 4. Information Exchanges: Documents the exchanged information.

In RESOLVD, HLUCs were analysed on the basis of a generic template, following step one of the above process, whilst PUCs were analysed and independently documented with a detailed template, following all the steps of the process.

2.3.2. Mapping UCs to the SGAM Following the modelling process proposed by SGCG and supported by the SGAM toolbox, the SGAM layers were created on the basis of the UC analysis. The HLUCs were modelled in the Function Layer, providing a high-level functional decomposition in the form of PUCs. PUCs, which were documented independently using the detailed template, were modelled in Component, Information and Communication Layer. As far as the Component Layer is concerned, a common model of the components in the respective domain and zone along side with a component mapping (see SGAM toolbox methodology [10]) was created, which was instantiated by each PUC, referring only to the related components. The whole process is depicted in Figure 9.

21


Figure 9 Use cases’ modelling process applied in RESOLVD

2.4. Interoperability Analysis This subchapter aims to present the outcome of the interoperability analysis on the basis of the use case modelling methodology presented above. For the sake of the reader’s convenience an aggregated view of the analysis is presented in this section, whilst a more detailed analysis, detailing the UC analysis and the relevant SGAM layer developed, is presented in Annex I. In order to prepare these views, an aggregation and consolidation of the information produced by the SGAM analysis of the UCs was performed. A presentation of the business and logical actors that participated in the UC analysis and corresponding components identified – along with the relevant mapping- is presented prior to the analysis of the results.

2.4.1. Actors The list of business actors that participated in the business case analysis along with a brief description of their role is presented in Table 4.

Actor Name Type Description

Distribution

System Operator

(DSO)

Role

A business entity responsible for distribution system

development, operation, and maintenance. It represents the main

business actor of the use cases under exploration in RESOLVD.

Aggregator Role

Aggregates energy flexibility from different sources (e.g.

generation, storage and demand-response assets). Aims at

economic benefit by offering flexibility to other business actors,

empowered by the presence of the new technologies.

Retailer Role Entity selling electrical energy to consumers.

Energy

Community Role

A cooperative/partnership/non-for-profit organisation of final

customers who typically consume and generate energy

(prosumers). Will benefit from advanced power management

strategies and higher installed capacity.

Prosumer Role A party that, apart from consuming electricity, can also produce it

from DERs. Could have economic benefit by offering flexibility to

other business actors, empowered by the presence of the new

technologies.

DER/Storage

Owner

Role A party that produces electricity from DERs and / or owns storage

assets. Could have economic benefit by offering flexibility to other

business actors, empowered by the presence of the new

technologies.

Table 4 Business Actors relevant to RESOLVD

The list of logical actors that participated in the UC analysis is presented in Table 5, indicating the

22


type of actor along with a brief description.

Actor Name Type Description

Advanced Metering Infrastructure (AMI) System

System

A system in charge of measuring and transmitting consumption and generation data from Smart Meters (SMs) of LV grid consumers and generators. The infrastructure is composed by the following devices and systems: MDC, DCU, SM and GM.

Battery Management System (BMS)

System

In charge of managing different battery technologies providing power and storage capacity, according to the energy management requirements. It forms part of the PED. To be developed during the project.

Critical Event Forecaster (CEF)

Application Application, in charge of predicting possible congestion or over-under voltage events in the succeeding forecasting time-horizon (H-time). To be developed during the project.

Critical Event Prevention Application (CEPA)

Application

Application implementing the orchestration mechanism of data management and executive actions, for the prevention of critical events through the utilization of local storage and switching actions. To be developed during the project.

Data Concentrator Unit (DCU)

Device

DCUs are units responsible of gathering measurement data from multiple metering devices installed at the substation or at the customer premises level, on a regional basis and sending them to the MDC.

Data Pre-processing Application (DPA)

Application Application that permits to clean, correct, complete and validate data once aggregated from various sources. To be developed/integrated during the project.

Distribution Management System (DMS)

System

A system utilized by the DSO which provides functionalities for advanced monitoring and control of the distribution grid from a centralized location, typically the control centre. In most of the use cases it participates as a main actor orchestrating the realization of the use case. Its operation can be automatic or subordinated to human control.

Energy Forecaster (EF)

Application

A forecasting application in charge of predicting demand and generation values in the succeeding time-horizon (H-time), in specific points of the grid, using aggregated values of individual consumptions/productions and weather forecast data. To be developed during the project.

Fault Detection Application (FDA)

Application

Application in charge of detecting, classifying and localizing a grid fault. It is based on real-time signal processing of field data and triggers warnings based on predefined thresholds with respect to expected operation. To be developed during the project.

Gateway (GW) Device

A device enabling the interconnection of various systems and devices. It can provide functions such as data aggregation, protocol conversion and coordination of end devices. To be developed during the project.

Geographic Information System (GIS)

System A Geographic Information System is a system designed to capture, store, manipulate, analyze, manage, and present all types of geographical data. It maintains the model of the grid and its assets.

Grid Operation Scheduler (GOS)

Application

Scheduling application that provides separate schedules for each actuator of the grid, satisfying a predefined objective function that depends on the specific scenario. To be developed during the project.

Grid Planner Human Actor

Human actor/analyst making use of mathematical formulations that help to identify the optimal location and size of the power electronics devices to be installed in the LV grid. The Grid Planner interacts with the Planning Task Force by requiring relevant data.

Intelligent Local Energy Manager (ILEM)

Device An intelligent electronic device (IED) in charge of communication and implementing the control logic of PED. To be developed during the project.

Island Power Management Application (IPMA)

Application Application implementing the orchestration mechanism of data management and executive actions, for the power management of a controlled island. It can work autonomously or controlled by a

23


human operator. To be developed during the project.

Loss Reduction Application (LRA)

Application

Application implementing the orchestration mechanism of data management and executive actions, for the reduction of losses through local storage utilization. It can work autonomously or controlled by a human operator. To be developed during the project.

Meter Data Collector (MDC)

System

Responsible of the collecting and managing measurement data at the operation centre of the DSO, by interfacing data concentrating units (DCUs). The data are then forwarded to MDMS for storage and analysis.

Meter Data Management System (MDMS)

System System for validating, storing, processing and analysing large quantities of Smart Meter data.

Non-Technical-Loss-Fraud Detection Application (NTLFDA)

Application Application that permits to detect non-technical losses. It can be based on different strategies.

Phasor Measurement Unit (PMU)

Device

A device enabling time-synchronized measurements of voltage, current, frequency and grid’ phase properties (i.e. synchrophasors) in a distributed system. It features a reference timing source (typically obtained via global navigation satellite system, GNSS) and fast and reliable communication links to feed the data to phasor data concentrators and consequently the WAMS. To be developed/integrated during the project.

Planning Task Force

Human Actor(s)

Group of people composed of DSO employees and technology providers/installers that collaborate with the common objective of identifying the most suitable technology size and location, by providing information regarding the grid and by collecting technical and economic data.

Power Conversion System (PCS)

Device Device capable of acting on the grid providing switching and energy management capacity, through power electronics. It forms part of the PED. To be developed during the project.

Power Electronic Device (PED)

Device

Device in charge of locally managing energy at different levels. It is composed of an Intelligent Local Energy Manager (ILEM), a Power Conversion System (PCS), a Battery Management System (BMS) and the batteries themselves. In the use case description, when possible, the single components are brought into play, while the term “Power Electronics Device” is used if it is necessary to refer to the whole group of software and hardware components. To be developed during the project.

Power Flow Simulator (PFS)

Application

An application that simulates power flows in the grid, predicting the voltage and current values of each bus for the following H-time. The calculation is based on the existence of a vector of measurements or predictions, related to demand and generation, for the same H-time. To be developed during the project.

Power Quality Analyser

Device

Power quality analyser which permits to measure, store and analyse grid data. Could be a device permanently installed in the grid (such as PQM) or a portable device installed for a limited period of time on the lines of a secondary substation. It allows the recording of a continuous set of power data (i.e. voltage, current, active and reactive power, harmonics, etc.).

Power Quality Monitoring (PQM)

Device

A device enabling precise power quality monitoring (e.g. harmonics, RMS, active/reactive power). The measurements fall in two basic categories, i.e. disturbances (parameter peak or RMS value exceeding a specified threshold during a transient event) and steady state variations (presented with statistical significance of parameter variation over time). To be developed/integrated during the project.

Remote Terminal Unit (RTU)

Device

A communications enabled Intelligent Electric Device (IED) that interfaces the Distribution Management System (DMS) or Supervisory Control and Data Acquisition (SCADA) system and field devices for exchanging telemetry data and control messages.

24


Self-healing Application (SHA)

Application

Application implementing the orchestration mechanism of data management and executive actions, for self-healing after a fault. It can work autonomously or controlled by a human operator. To be developed during the project.

Smart meters (SM) Device Device installed at the customer premises or DER location that measures power profiles and energy consumption.

Supervisory Control and Data Acquisition system (SCADA)

System

A system in charge of the overall monitoring and control of the distribution grid, integrating remote control systems, a monitoring infrastructure based on a telecommunication network, data analytics and data storage functionalities.

Switchgears Device Actuators of the LV grid that permit to switch lines and change grid configuration.

Weather Forecaster Application A service offering forecasting weather conditions services.

Wide Area Monitoring System (WAMS)

System

System in charge of managing (collecting, concentrating, transmitting and monitoring) georeferenced field data coming from distributed sensors. It is composed of Phase Measurement Units (PMU) and gateways, dedicated ICT infrastructure to connect PMUs with operation systems, and a software implementing the wide area monitoring strategy with the exploitation of PMU data. To be developed during the project.

Table 5 Logical Actors relevant to RESOLVD

2.4.1. Use Cases A list of the HLUCs and PUCs analysed with the SGAM framework is presented in Table 6 and Table 7, respectively. The detailed description of the UCs is presented in Annex I.

No. Name

01 Prevention of congestion and over/under voltage issues through local storage utilization and grid reconfiguration

02 Voltage control through reactive power injection or consumption

03 Improving power quality and reducing losses through power electronics

04 Reduction of power losses through local storage utilization

05 Self-healing after a fault

06 Power management in intentional controlled island mode

07 Detection and interruption of unintentional uncontrolled islanding

08 Detection of non-technical losses

09 Planning of the commissioning of power electronics and local storage

Table 6 List of HLUCs analysed with SGAM framework

No. Name

01 Demand and generation forecasting

02 Power flow simulation

03 Critical event forecasting

04 Grid operation scheduling

05 Grid operation schedule dispatch

06 LV grid observability and monitoring

07 Data pre-processing

08A Collecting electrical data locally by the PED

08B Collecting external electrical data by the PED

09 Local reactive power management for voltage regulation

10 Local active and reactive power management to correct power quality issues

11 Fault detection and localization

25


12 Detection of uncontrolled island-mode

13 Interruption of uncontrolled island mode

15 Individual consumption modelling

16 Consumption monitoring

17 Grid information data collection

18 Analysis of present power measurements

19 Assessment of suitable location for PED

27 Orchestration

Table 7 List of PUCs analysed with SGAM framework

2.4.2. Components As presented in the methodology, the next step in the modelling process is the transformation of Logical Actors to Physical Components. This mapping is presented in Figure 10, where one might notice that apart from one-to-one relation, many-to-one and one-to-many types of relation can also exist in the transformation. Different Logical Actors can be deployed in a single component (e.g. DMS), whilst a Logical Actor could be also decomposed in different components (e.g. PED decomposed in ILEM, PCS and BMS).

Figure 10 Component Mapping

deployment Actor Mapping

External Systems

Operation applications (DMS) WAMS

Legacy Systems

Supervision and analytics services

Power Electronics Device

«Logical Actor»

EF

(from

Actors)

«Logical Actor»

PFS

(from

Actors)

«Logical Actor»

CEF

(from

Actors)

«Logical Actor»

GOS

(from

Actors)

«Logical Actor»

PED

(from

Actors)

«Logical Actor»

Switchgears

(from

Actors)

«Logical Actor»

WAMS

(from

Actors)

«Logical Actor»

SCADA

(from

Actors)

«Logical Actor»

Weather Forecaster

(from

Actors)

«Logical Actor»

Data Pre-processing

Application

(from

Actors)

«Logical Actor»

FDA

(from

Actors)

«Logical Actor»

NTLFDA

(from

Actors)

«Logical Actor»

CEPA

(from

Actors)

«Logical Actor»

LRA

(from

Actors)

«Logical Actor»

SHA

(from

Actors)

«Logical Actor»

IPMA

(from

Actors)

«Logical Actor»

DMS

(from

Actors)

DMSPMU

GW

Smart

Meter

SCADA

Weather

Forecaster

WAMS

PFS

ILEM BMSPCSSwitchgears

EF CEF GOS

«Logical Actor»

MDMS

(from

Actors)

MDMSRTU

«Logical Actor»

GIS

(from

Actors)

GIS

DCU MDCGrid

Meter

«Logical Actor»

AMI

(from

Actors)

PQM

«Logical Actor»

PQM Device

(from

Actors)

«Logical Actor»

PMU

(from

Actors)

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»«trace»

«trace»

«trace»

«trace»

«trace»«trace»«trace»

«trace»

«trace»

«trace»

«trace»«trace»

«trace»

«trace»

«trace»

26


2.4.3. Results This subchapter presents a top view of the results of the analysis, focusing on the components’ positioning and interrelations (SGAM Component Layer), their functionality and functional interrelation (SGAM Function layer) from the scope of the UCs analysed, as well as the interoperability of communications (SGAM Information and Communication Layers).

2.4.3.1. Components’ layout The SGAM Component Layer, which presents the architecture of the system (aka Domain Specific Architecture), positioning of the components in the relevant domain and zone of the SG plane, is presented in Figure 11.

Figure 11 RESOVD Components’ layout in the SGAM plane

The figure presents the components identified in the component mapping (refer to Figure 10).

2.4.3.2. Functions’ layout The SGAM Function layer presents the functions of components and possible interrelations. In Figure 12, based on the already presented architecture of the system modelled in the SG plane, the main functions of the components are analysed. Each rectangle presents a function and is laid over the component(s) it relates with. Different colouring is introduced in order to differentiate the common overlays over the same components.

Figure 12 RESOLVD Functions’ layout in the SGAM plane

27


2.4.3.1. Communication technologies and links In Table 8 the communication technologies that are relevant to RESOLVD are presented, based on the communication infrastructure utilized for components’ interactions. Each row presents a communication link, the relevant communication technology and the related use cases. In Figure 13 the communication technologies are mapped onto the RESOLVD Components layout.

Link No.

Communication Link Communication Technologies Use Case

1 MDMS-MDC FTP 06 2 DCU-SM PRIME 06 3 DCU-GM Modbus RTU 06 4 DCU-MDC STG-DC3.1C 06 5 DMS - CEF IEC 61968-100 01, 27 6 DMS - EF IEC 61968-100 01, 27 7 DMS -GOS IEC 61968-100 04, 27

8 DMS -PFS IEC 61968-100 02, 27 9 DMS-MDMS IEC 61968-100, 01, 03, 15, 16 10 DMS-SCADA IEC 61968-100 05, 27 11 DMS-WF Web-services 01 12 DMS-WAMS HTTPS 11 13 CEF-GIS HTTPS 03 14 EF-GIS HTTP(S) or FTP 01 15 PFS-GIS HTTP(S) 02 16 GOS-GIS HTTPS 04 17 EF-MDMS HTTPS 01 18 WAMS-GW IEEE C37.118.2, MODBUS 06 19 GW-PMU IEEE C37.118.2 06

20 GW-PQM MODBUS TCP/IP 06 21 RTU -ILEM MODBUS TCP/IP 05.08B 22 RTU-Switchgears MODBUS RTU 05, 06 23 SCADA- RTU IEC60870 05, 06 24 ILEM-PCS MODBUS RTU 08A,09,10,12,13 25 PCS-BMS MODBUS RTU 08B

Table 8 Communication technologies and links identified in RESOLVD

Figure 13 Mapping of communication protocols onto the RESOLVD Components layout

2.4.3.2. Information Interoperability Table 9 presents various information standards that were identified by the SGAM analysis, for realizing communications among components, based on the specifications of the legacy systems and the state-of-the art use of domain information standards. Each row presents an information object with a short description, the relevant information standard(s) and the related use cases. In Figure 14, the information models are mapped onto the RESOLVD Components layout.

28


No. Information Object Name Short Description Relative

Standards Use

Case(s)

1 Charging/Discharging Schedule Charging/Discharging Schedule for PEDs (ILEM) IEC60870-5-104,

MODBUS 05

2 Charging/Discharging Schedule

Acknowledgement Acknowledgement for new Charging/Discharging Schedules of PED

IEC 60870-5-104, MODBUS

05

3 Consumption & Generation Data Energy demand and supply measurement data per customer for a specified time period CIM (IEC 61968) 01,15,16

4 Consumption & Generation Data

Request Request for energy data containing location (or grid ID) and time period CIM (IEC 61968) 01,15,16

5 Critical Event Forecast Voltage at each bus and current through line with a detected critical situation (e.g. overcurrent) CIM (IEC 61968) 03, 27

6 Critical Event Forecast Request Request for forecast of critical events, containing power flow simulation, SM voltage and grid

configuration data CIM (IEC 61968) 03, 27

7 Critical events analysis Critical events (over/under-voltages) list including the magnitude, duration and location (bus

and/or line) of the event. CIM 06

8 Fault detection alert Alert of fault detection specifying fault type, component which performed the detection (WAMS or

FDA), fault time (PMU data timestamp used to detect the fault), and fault localization Proprietary 11

9 Fraud detection alert Alert of fraud specifying meter identifier and magnitude/likelihood of fraud Proprietary 16

10 Generation and Demand

Forecast Energy consumption and generation forecast as a time series, with model uncertainty, at each

specified bus and each time-slot for the requested time period CIM (IEC 61968) 01, 27

11 Generation and Demand

Forecast Request

Request for calculating and providing energy forecast for a specified period and locations (grid or model ID). Request also contains last week's consumption and generation data, weather

forecast for the target time period, relevant buses for energy forecast CIM (IEC 61968) 01, 27

12 Grid Configuration and Status Data that depict the current grid topology and status (switchgear status, lines or regions that are

offline due to maintenance, fault etc.) CIM (IEC 61968) 01, 27

13 Grid Configuration Data Request Request for calculating and provision of grid configuration data (switchgear status). CIM (IEC 61968) 27

14 Grid Operation Schedules Set of grid operation schedules to be considered by the DMS with the estimated optimality of each one. Each schedule consists of a sub-schedule for each grid actuator (PED/switchgear)

CIM (IEC 61968) 04

15 Grid Schedule Grid Schedule containing control commands for Switchgear and Charging/Discharging

Schedules for PEDs. CIM (IEC 61968) 05, 27

16 Grid Operation Schedule

Request

Request for a Grid operation schedule by defining optimization objective and enclosing, grid information, expected energy generation and demand, grid actuators information (battery status,

capacity, switchgear connections, etc.) CIM 04, 27

17 Grid Topology Grid topology containing electrical features of the grid (e.g. lines impedances) CIM 01, 02, 03, 04

18 Grid Topology request Request for acquiring the model of a desired part of the grid. CIM 02, 03, 04

19 SM measurements Energy consumption and generation and voltage data, including CUPS and associated DCU IEC 62056

(DLMS/COSEM) 06

20 SM measurements request Request for energy consumption and generation and voltage data IEC 62056

(DLMS/COSEM) 06

29


21 Historical SM voltage and

demand and generation data Historical data from SMs containing voltage and demand / generation measurements. CIM (IEC 61968) 07

22 Historical SM voltage and

demand and generation data request

Request for Historical SM voltage and demand and generation data request CIM (IEC 61968) 07

23 Historical weather data Weather data (temperature and irradiance) at each time-slot for the specified time period. Proprietary weather

data format 01

24 Historical weather data request Request for weather data containing location and time period and time granularity. Proprietary weather

data format 01

25 PED state

Describes the state of the PED, detailing the PED ID, voltages, current and power at the point of connection, SoC of the set of batteries (aggregated), alarms and warnings, availability and

information related to the activation of main functionalities (such as Reactive compensation, Harmonic current mitigation).

Modbus, CIM (IEC 61968)

06

26 PED state request Request for PED state (including PED ID) Modbus,

CIM (IEC 61968) 06

27 BMS state Status of batteries from the battery management system (e.g. SoC). Modbus 06

28 PCS state Status of the power conversion system including information collected by embedded sensors

(e.g. voltage and current data). Modbus 06

29 PMU data request Request for PMU data, i.e. all PMU data from the last request until the time of the request. The

request specifies PMU ID CIM (IEC 61968) 07, 11

30 PMU data Frequency, voltage and current synchrophasor measurements, including timestamps, PMU ID IEEE C37.118.1 06, 07,11 31 Power Flow Simulation request Request containing energy demand and supply and grid configuration CIM (IEC 61968) 02, 27 32 Power Flow Simulation Results Results of power flow analysis as a time series of voltage/current values per location CIM (IEC 61968) 02, 27

33 PQM data Power quality measurements (RMS, harmonics, total harmonic distortion…), including timestamp

and PQM ID IEEE C37.118.1 06, 07,11

34 PQM request Poll request CIM (IEC 61968) 07,11 35 Switch Position Command Switch Position Command for Switchgears IEC 60870-5-104 05

36 Switch Position Command

Acknowledgement Acknowledgement for control command of Switchgears. IEC 60870-5-104 05

37 Switchgear state Switchgear state, including switchgear ID Modbus 06 38 Switchgear State request Request for switchgear state, including switchgear ID Modbus 06 39 Voltage data Voltage data measured by SMs in the specified grid and for the specified time period. CIM (IEC 61968) 03 40 Voltage data request Request containing location (or grid ID) and time period CIM (IEC 61968) 03

41 Weather Forecast Time series of weather forecast data (temperature and irradiance) for a specified time period. Proprietary 01, 27 42 Weather Forecast Request Request for weather forecast containing location and time period and time granularity. Proprietary 01, 27 43 Field measurement (PCS) Modbus data map from PCS (also available in ILEM for external consultations) Modbus 08A,12 44 Poll request (PCS) Request for PCS state Modbus 08A,12 45 Grid Meter state Modbus data map from a Grid Meter Modbus 08B 46 Poll request (GM) Request for Grid Meter state (through RTU) Modbus 08B 47 Dispatch request (ILEM) ILEM request a specific reactive power in order to perform the voltage regulation Modbus 09,10

30


48 Power Quality command A bit-signal to command that the PCS balances currents, compensates reactive power or/and

mitigates harmonics. Modbus 09

49 Reactive power set-point A signal to command/parameterize the PED to a specific reactive power for voltage regulation. Modbus 10 50 Island Verification Command A signal sent by SCADA or RTU to ILEM to verify the uncontrolled island situation. Modbus 12

51 Interruption Request (PCS) The ILEM A power profile (active-reactive power setpoints) in order to break the generation

consumption equilibrium. Modbus 13

52 Island Interruption Alarm Information (bit) notifying ILEM whether the island was interrupted or not. Modbus 13

Table 9 Information Objects and standard information models

Figure 14 Mapping of information models onto the RESOLVD Components layout

31


3. Integration Analysis

This chapter presents the methodology followed for integration analysis and introduces the integration middleware and the tools related to data management, analysis and visualization.

3.1. Introduction European Committee for Standardization (CEN) TC310 WG1 defines three levels of integration:

Physical Integration: Interconnection of devices via computer networks; Application Integration: Interoperability of software applications and database systems in

heterogeneous computing environments; and Business Integration: Coordination of functions that manage, control and monitor

business processes.

All these aspects are of interest to the project, especially the latter two, aiming at creating an integration of novel applications in the environment of the control centre and in the traditional business processes of the operator.

Integration can be classified in different types with regards to direction (horizontal/vertical), reach (intra/inter-organizational), domain (data/function/program wise) and can cover different integration aspects such as combining existing systems or integrating new systems or establishing interoperability. F

Date post:	25-Jan-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times