Benchmark Analysis Ems DMS

www.interpreter.
eu
BENCHMARK ANALYSIS
REPORT OF TOOLS AND
PLATFORMS FOR GRID
OPERATORS
Deliverable D2.3
This project has received funding from the European Union’s Horizon 2020 research and innovation programme
under grant agreement No. 864360 (INTERPRETER). This output reflects only the author’s view and the European
Union cannot be held responsible for any use that may be made of the information contained therein.
Funded by the Horizon 2020

Framework Programme of the European Union
D2.3
Deliverable D2.3
BENCHMARK ANALYSIS REPORT OF TOOLS AND
PLATFORMS FOR GRID OPERATORS
Version 1.1
Organisation: ATOS
Main authors: Ugo Stecchi, Miguel Rodriguez
Date (13/03/2020)
www.interpreter.eu
D2.3
DELIVERABLE 2.3 – VERSION 1

WORK PACKAGE N° 2 – Project Baseline and Definition of Use
Cases
TASK N° 3 – Analysis of the existing platforms for distribution
and transmission management
Nature of the deliverable
R Document, report (excluding the periodic and final reports) X
DEM Demonstrator, pilot, prototype, plan designs
DEC Websites, patents filing, press & media actions, videos, etc.
OTHER Software, technical diagram, etc.
Dissemination Level
PU Public, fully open, e.g. web X
CO Confidential, restricted under conditions set out in Model Grant Agreement
CI Classified, information as referred to in Commission Decision 2001/844/EC
Approvals
Date Version Author(s) Task Leader WP Leader
05/12/2019 0.1 Ugo Stecchi ATOS ORES
10/02/2020 0.2 Ugo Stecchi, Miguel ATOS ORES
Rodriguez, Malena
Donato,
Rodriguez, Malena
Donato, Charalampos
Ziras; Angeliki Syrri
Rodriguez, Malena
Donato, Charalampos
Ziras, Angeliki Syrri,
Louis Marion, Alberto
Sánchez, Jorge
Rueda, Pablo López,
Alexander Rutkowski.
13/03/2020 1.1 CIRCE Final Quality Review
Disclaimer of warranties
This report is part of the deliverables from the project INTERPRETER which has received funding from
the European Union’s Horizon 2020 research and innovation program under grant agreement No
864360. More information on the project can be found at https://www.interpreter.eu
www.interpreter.eu
D2.3
This document has been prepared by INTERPRETER project partners as an account of work carried out
within the framework of the EC-GA contract No 864360.
Neither Project Coordinator, nor any signatory party of INTERPRETER Project Consortium Agreement,
nor any person acting on behalf of any of them:
(a) makes any warranty or representation whatsoever, expressed or implied,
(i) with respect to the use of any information, apparatus, method, process, or similar item
disclosed in this document, including merchantability and fitness for a particular purpose,
or
(ii) that such use does not infringe on or interfere with privately owned rights, including any
party's intellectual property, or
(iii) that this document is suitable to any particular user's circumstance; or
(b) assumes responsibility for any damages or other liability whatsoever (including any consequential
damages, even if the Project Coordinator or any representative of a signatory party of the
INTERPRETER Project Consortium Agreement has been informed of the possibility of such
damages) resulting from your selection or use of this document or any information, apparatus,
method, process, or similar item disclosed in this document.
www.interpreter.eu
D2.3
Executive summary
This document is a report about the activities carried on in Task 2.3 - Analysis of existing platforms for
distribution and transmission system management. The task is aimed at analyzing digital platforms for
power systems and energy applications already available, in order to highlight how interactions and
collaborations can be achieved between the INTERPRETER solution and existing tools.
INTEPRETER project will develop a modular grid management solution where different DSOs can take
advantage of an open-source digital infrastructure with a catalogue of on-line and off-line applications.
The concept at the core of this project is the possibility for any DSO to feed the platform with its own
data (regardless information and data model) and run those services a la carte. This represents an
opportunity for establishing common interactions between system operators through a semantic
repository responsible for the harmonization of the different data sources. These new harmonized data
enable the creation of new grid models and, therefore, the analytics at the core of services portfolio. In
a recent scenario where data sharing is assuming a relevant role in energy industry, this concept will
allow the required collaboration between DSO-DSO and DSO-TSO. Those interactions are the
fundamentals for the implementations of the next energy market options.
This report is aimed at identifying those critical aspects that may affect the interactions between
INTERPRETER open-source platform and existing industrial solutions. To achieve this aim, a
benchmarking analysis has been carried out with the objective of mapping today’s common solutions
and possible interfaces with INTERPRETER. Due to the vast area of interest for the analysis, the
document also includes a preliminary investigation of the digital platforms sector in power systems in
order to delimit the topics of interests. In section 1 a brief explanation of context is provided, while in
section 2 the existing platforms are organized in categories with a description for each one of them.
Among all the existing solutions, only the ones related to distribution (DMS, ADMS, OMS, AMI) and
distribution-transmission (EMS) interactions are considered.
The categorization of section 2 is not enough for circumscribing the analysis, therefore in section 3 there
is a tentative of reducing the complexity of the problem. Starting from the state-of-the-art a smart grid
architecture, the different layers of digital platforms are analyzed. From this analysis the most relevant
parameters and features for the benchmark analysis are listed.
In section 4, a survey of the existing platforms has been conducted considering the technical features
identified in section 3, and some considerations about INTERPRETER interactions are provided with
particular regards of applications. The items for this comparison derive from previous analysis carried
out in section 2 and section 3. Twelve ICT solutions are considered and compared in this benchmark
analysis; some relevant features (from technical sheet and public information) are compared, but
platforms have not been installed and tested from a computational point of view. Finally, the section 5
deals with those aspects characterizing DSO and TSO solutions, bringing out peculiarities, differences
and possible common points.
www.interpreter.eu
D2.3
List of abbreviations
Abbreviation Full name

ADSM Advanced Distribution Management System
AI Artificial Intelligence
AMI Automatic Metering Infrastructure
ASM Active System Management
BESS Battery Energy Storage System
BRP Balance Responsible Party
CIS Customer Information System
DG Distributed Generation
DOA Document of Actions
DSM Distribution Management System
DSO Distribution System Operator
DSS Decision Support System
EV Electric Vehicle
FLISR Fault Location Isolation and Restoration
HV High Voltage
IED Intelligent Edge Device
IoT Internet Of Things
ISO Independent System Operator
LV Low Voltage
MILP Mixed Integer Linear Programming
MV Medium Voltage
NLP Non-Linear Programming
O&M Operation and Maintenance
OMS Outage Management System
QoS Quality of Service
REST Representational state transfer
RL Reinforced Learning
RTU Remote Transmission Unit
SCADA Supervisory Control and Data Acquisition
SGAM Smart Grid Architectural Model
SOAP Simple Object Access Protocol
TRL Technology Readiness Level
TSO Transmission System Operator
VPP Virtual Power Plant
www.interpreter.eu
D2.3
List of Figures
Figure 1: IEC TC 57 reference architecture. ........................................................................................... 10
Figure 2: Common architecture diagram of a dsm. ............................................................................... 16
Figure 3: Common oms architecture [10]. ............................................................................................. 17
Figure 4: Example of architectural scheme for ADMS [10]. ................................................................... 19
Figure 5: Smart Grid Reference Architecture [14]. ................................................................................ 21
Figure 6: Strategy for benchamrk analysis of energy platforms. ........................................................... 27
List of Tables
Table 1: Main categories of solutions for energy service providers....................................................... 14
Table 2: Relevant energy platform features for INTERPRETER benchmark analysis. ............................. 22
Table 3: Data for platforms’ benchmarking (part A) .............................................................................. 29
Table 4: Data for platforms’ benchmarking (part B) .............................................................................. 31
Table 5: QoS requirements for smart grids applications [37] ................................................................ 34
Table 6: interpreter applications mapping vs benchmarked platforms ................................................. 35
Contents
1. Context of the work conducted in task 2.3........................................Error! Bookmark not defined.
1.1. General context .........................................................................Error! Bookmark not defined.
2. Technical approach ........................................................................................................................ 11
2.1. Topics of interest ................................................................................................................... 11
2.2. Categories of platforms to consider ...................................................................................... 14
2.2.1. Distribution Management System ................................................................................ 15
2.2.2. OMS Outage Management System ............................................................................... 16
2.2.3. EMS Energy Management System................................................................................. 17
2.2.4. ADMS Advanced Distribution management System ..................................................... 18
2.2.5. AMI Automatic Metering Infrastructure ....................................................................... 18
2.2.6. Digital Platforms for new market services .................................................................... 19
3. Relevant Features for Benchamarking .......................................................................................... 21
www.interpreter.eu
D2.3
3.1. Business Layer ....................................................................................................................... 22
3.2. Function Layer ....................................................................................................................... 22
3.2.1. Applications For Efficient Operation And Maintenance Of The Grid ............................ 23
3.2.2. Applications For An Effective Grid Planning .................................................................. 23
3.3. Communication Layer............................................................................................................ 24
3.4. Information Layer .................................................................................................................. 24
3.5. Component Layer .................................................................................................................. 25
4. Benchmark of Digital platforms for electric systems..................................................................... 27
4.1. Comparison of available solutions ........................................................................................ 27
4.2. Adoption of Services and Applications .................................................................................. 34
5. Comparison between DSO and TSO platforms .............................................................................. 37
5.1. Communication ..................................................................................................................... 38
5.2. Market functions ................................................................................................................... 38
5.3. Operational functions and operational planning .................................................................. 39
6. Conclusions .................................................................................................................................... 40
7. References ..................................................................................................................................... 42
www.interpreter.eu
D2.3
1. INTRODUCTION – GENERAL CONTEXT
The analysis of digital platforms for power systems and energy applications is a cross-sectorial activity
that could embrace a variety of technologies, applications and techniques. In order to circumscribe the
field of investigation and focus the benchmark on those aspects useful for INTERPRETER purposes, it is
necessary to analyse this portion of the energy value chain and identify and analyse parallelism and
similarities with INTERPRETER solutions. This preliminary activity conducted in section 1 and 2, will lead
to an analysis of technical parameters in section 3 and finally to the survey of existing platforms in
section 4.
The distribution power system is the part of the electric system which is most affected by smart grid
technologies. Transmission systems (high-voltage levels) in general have historically played a central
role for implementation and adoption of innovative solutions, while distribution networks followed at a
distance. Since the dawn of the smart grid era, many electric distribution companies are in the process
or already have transitioned from a typically manual business process to digital aids and decision
support systems [1].
The context of digital services for operators in distribution of electric energy (DSOs and service
providers) has quickly evolved in recent years. The adoption of smart grids technologies and the
diffusion of renewables had impact on the regulation and market framework all across Europe with
relevant effects on the energy industry. System operators used to be equipped with SCADA systems
monitoring HV and MV networks, while today the focus is more oriented in the LV grid, that is the
missing part of the infrastructure. The advent of smart meters has covered a large portion of this
section’s network, but the observability of the system is not proportionally improved, due to a missing
cooperation between metering infrastructure and legacy systems. In addition, two more aspects must
be considered in this evolving scenario: the growing number of “smart” devices connected to the grid
(e.g. distributed generation, building automation, IoT devices) and the introduction of new tools and
services in control centres to exploit the huge amount of new signals from the field. In such a context,
there are today a great number of digital platforms and vendor solutions for monitoring, control and
decision support, with heterogeneous categories of standards and de-facto standards. Therefore, to
make the best use of those data and foster the implementation of the Energy Union Strategy [2] based
on open and competitive concepts, it is important that the different stakeholders (with different
systems) can share information in a common standard.
Thus, the critical phase is to connect all the cyber-physical systems today available, in a unique and
harmonized landscape. It is supposed to be a huge effort considering conventional and legacy systems
still present in many control rooms. This high-level standardization process should cover the gap
between data models in control centres and peripheral assets that give rise to criticalities in reliability
of the systems. Technical Committee 57 from IEC provided a reference architecture in IEC 62357 that is
a basis for implementation of integration strategies (Figure 1) [3].
Without entering in much detail of the reference architecture, it is important to highlight here the
complexity of the platforms we are called to survey. There is a huge number of protocols and
information models available that are at the basis of the different functionalities and services [4].
www.interpreter.eu
D2.3
FIGURE 1: IEC TC 57 REFERENCE ARCHITECTURE.
www.interpreter.eu
D2.3
2. TECHNICAL APPROACH
The analysis of the different digital platforms for distribution systems could be challenging and vast at
the same time. Digital platforms can be considered as one part of a wide cyber-physical system
composed by different entities in a modular structure. The investigation can be conducted from
different points of view or at different depth levels taking into account technological, functional or
business aspects.
This chapter is aimed at outlining the general structure of such frameworks in order to identify critical
aspects to be investigated. Those aspects will be later analysed for the definition of the main features
and parameters useful for the benchmarking.
The main goal required for INTERPERTER is twofold: identifying the differences and the possible
interactions among platforms. So, the objective is to circumscribe those fields of interest that may
characterize digital platforms according to the INTERPRETER purposes and extract the elements for the
comparison.
Information will be collected from INTERPERTER partners and from a literature review.
2.1. TOPICS OF INTEREST

Power system monitoring and control have been completely transformed after the introduction of
Supervisory Control and Data Acquisition (SCADA), but the technologies and the techniques at the core
of these systems have remained basically unchanged for decades. The advent of smart grid technologies
in a first stage and the process of digitalization of energy systems, originated strong innovations in this
field, disclosing a large variety of new applications, opportunities and novelties affecting different levels
of the energy value chain. Different factors have contributed in this transition:
• Consolidated penetration of the renewables
• Growing number of connected Battery Energy Storage Systems (BESS)
• Diffusion of Electric Vehicles (EV)
• Introduction of new communication/trans-mission protocols (cloud, IoT, blockchain, etc.)
• Progress in data analysis and management (big data, machine learning, AI, etc.).
Although only technical advances are listed here, the evolution of power and energy systems has been
accompanied with regulatory, policy, market and business innovations, in a unique and complex
scenario affected by a radical paradigm shift, that is now involving all the actors and portions of the
value chain [5].
In particular, distribution systems represent a portion of the chain deeply affected by this transition and
where the digitalization of the electric sector has a great impact. The recent possibility to receive a huge
amount of data available at control centres, disclose new challenges and opportunities at the same
time. On one hand data must be treated, transmitted and managed according to a number of
regulations and constraints; on the other hand, they can be used to extract information impossible to
obtain until yesterday.
These two aspects improved the SCADA systems and make them evolve towards new and more complex
digital platforms, prepared for undertaking these tasks. Today it is very common for DSOs to be
equipped with DSM (Distribution Management System), EMS (Energy Management System), OMS
(Outage Management System), AMI (Automatic or Advanced Metering Infrastructure), CIS (Customer
www.interpreter.eu
D2.3
Information System) and other similar tools. In the same way, system operators are now adapting their
processes and operations based on data-driven applications and services.
In particular, the so-called digitalization of the energy sector affected the way distribution companies
can exploit information from monitoring systems. Thanks to huge amounts of data today available from
the field and the recent ICT progress, new opportunities in system operation and management are today
a tangible option for DSOs. The digitalization of the energy distribution is bringing innovation in data
and tools. Signals and measurements from the edge have a higher granularity, with a high rate of the
so-called “data availability”. In addition, new services for processing and treatment of those data are
providing more insights into the traditionally passive grid. These new capabilities allow a wider
observability of the whole infrastructure and a higher level of control. The improvement of
communication technologies gives the data a crucial role in such scenario, that is now essential for the
implementation of new market options. Energy and market players are today managing their own data
hub and they are called to exchange information among them in a more meshed and connected
landscape. DSOs need to exchange information with market operators, neighbouring DSOs and TSOs.
The interactions among stakeholders are increasing and each one of them requires specific interfaces,
whereas deficiencies in standardization are still present [6] .
Even though digitalization occurred in many areas and applications of power distribution, it is possible
to briefly resume this process with three main points:
• Communication and Connectivity
• Interoperability
• Data Analysis and Management
Communication and Connectivity:

There is a large variety of equipment and apparatus that can be connected somehow with respect of
the SCADA technologies from the past. RTU (Remote Terminal Unit) has evolved into IED (Intelligent
Edge Device) and new devices have been massively deployed at LV and MV level thanks to renewables
and building and home automation. In addition, new transmission protocols and standards have been
recently adopted, providing more connectivity options.
Interoperability:
This is a quite broad question, embracing the possibility to monitor and control a device from a
different platform (with their own standards, information models etc.). Recently this concept has been
expanded with a more complete description that is the “ability of a system to cooperate with other
products or systems” [7].
It deals with the standardization of information models and the harmonization of ontologies that is
one of the most relevant industrial concerns of the energy sector. This goes far beyond the mere edge
device connectivity, because it implies the possibility of sharing data, information and services for two
or more digital platforms (a concept that goes straight to the core of the INTERPRETER project as well).
Thus, interoperability not only deals with the problem to overcome vendor lock-in for edge devices,
but it is considered of fundamental relevance for building the EU energy market. The smart grids task
force in the “Electricity and Gas Data Format and Procedures” report [8] states: “The harmonisation
of energy data exchange to ensure interoperability is an important dimension of the European
liberalised electricity and gas markets”. From smart metering openness, to cross-border trading and
the competitiveness at national and European level, the report highlights the different aspects where
interoperability is crucial for setting up the intended Energy Union.
www.interpreter.eu
D2.3
Moreover, in [4] the different urgencies for DSOs regarding standardization at European scale are
provided in clusters. These clusters are organized according to a priority colour code. The most urgent
cluster of priorities includes gaps related to interoperability, such as: “Seamless communication
between control centre and substation” and “Harmonized glossary, semantic & modelling between
back-office applications (CIM) and field applications (IEC 61850)”. The document also highlights the
importance of the alignment between both standards and how this lack of harmonization impacts on
the operation and reliability of the system.
Data Analysis and Management:

Data are today perceived as a new commodity even in the energy market. They can be acquired from
the field, from the equipment installed at different nodes in the grid or even from external platforms,
but the challenge is to extract useful information from them. This could be a complex task, for instance
when a huge amount of data is collected in real or near real time and they need to be processed with
the proper historical information. New algorithms based on deep learning, machine learning or even
artificial intelligence have set a new base line in the data analysis for power systems. Scenarios can be
even more wide and complex if technologies like blockchain are taken into account. There is a huge
impact at application and service level that can be easily reflected in business and market
developments.
According to the International Energy Agency [9] digital services derived from data analysis and data
management have a huge potential for cost reduction in operation and maintenance for system
operators. The joint utilization of these three main points has led to the diffusion of new services in
operation (e.g. optimal grid reconfiguration, congestion and voltage management, reactive power
compensation, capacity allocation) and maintenance (fault location, predictive maintenance,
restoration priority, crew management and ticketing) commonly deployed in DMS and OMS nowadays.
Reducing O&M costs means lowering the costs of generation plants and distribution systems, that
would be eventually reflected in kWh cost reduction for final users.
The benchmarking will be basically conceived on those three main aspects to be examined in detail, as
described in the following sections. The capability for a digital platform to provide real advantages for a
DSO depends on how it undertakes each one of those aspect. Apart from the direct benefits derived
from new services and applications, as well as connectivity and interoperability, there are other
consequences that will affect the energy chain from both technical and business point of view [9].
In the first case it should be considered that power systems are critical infrastructures – in the most of
cases – and thanks to the progresses in smart grids, higher standards of reliability and resilience are now
achievable. Development of microgrid solutions, together with self-healing, adaptive relaying or
predictive maintenance techniques have improved the quality of power-supplying services.
On the other hand, the digitalization of the energy sector has introduced new business options, such
as: demand response, flexibility exchange markets, energy communities and others, that are
transforming the electricity market at wholesale and retail level.
In a such wide area to investigate and survey, the implementation of digital platforms at DSO level is a
first step that could be easily analysed. Recent works highlight that only a limited percentage of
operators is equipped with a DMS platform. [10]
The integration process between legacy systems (already present at DSO control centres) and new
digital platforms is not always easy. The obstacles often reside in long-term decisions (data models,
workflows, business constraints, standard adoption, etc.) that make challenging the migration towards
new solutions. From this brief snapshot, it seems clear enough that there is room for improvement
along this path, towards a full digitalization of the distribution sector.
www.interpreter.eu
D2.3
In “DSO priorities for smart grid standardisation” [4] it is possible to find the full list of clusters of
priorities.
2.2. CATEGORIES OF PLATFORMS TO CONSIDER

Energy platforms may vary based on the way they apply their technologies to the existing infrastructure.
In many cases SCADA are today at the core of a more complex platform where different suites of services
can be built on top. The possibility to integrate signals from smart meters or data from AMI is an example
of how different technological layers can be overlapped through the hard constraint of an adequate
harmonization degree. This is a typical case where innovative solutions should interact with legacy
systems in order to provide the full potential from data insights. In many cases SCADA and AMI are today
operated in parallel without any automatic cooperation between the two systems.
The development in recent years of new services based on data acquired from SCADA has led to the
diffusion of new digital platforms devoted to the improvement of the duties of DSOs in their different
jobs. As a result, it is possible to find solutions for different activities of a generic service provider which
can be divided in 6 categories, as shown in Table 1.
Platform type Service target Short description
DMS Operation and Control DSS for control centres and field workforce for
improving efficiency of distribution system
supervision
OMS Operation and Maintenance Identification and solution of outages and events,
field workforce coordination and management
EMS Energy dispatch Dispatch and control of power flows, optimizing
system balance, including generation assets and
transmission lines
AMI and CIS Customer Management Two-way communication between DSO and smart
meters at final users (billing, dynamic pricing, user
engagement)
ADMS Integration of DMS, OMS, Objective to integrate all services in one modular
EMS, AMI and CIS platform, providing all required services from a
unique interface
Data driven New market services Mainly platforms adopted by actors that do not
operate a power system (e.g. Energy Community
Managers, Aggregators, VPP Managers)
TABLE 1: MAIN CATEGORIES OF SOLUTIONS FOR ENERGY SERVICE PROVIDERS.
This can be a typical categorization that is commonly adopted in the industrial and scientific jargon even
if it does not seem that a formal categorization and standardization of the nomenclature and
applications is available. Bullets one to four represent typical platforms generally adopted by system
operators, while bullet five encompasses all new services which are not covered by the existing systems.
The first three categories are usually built on top of a SCADA system. The solution of course may vary
from one vendor to another and some critical features may differ (e.g. information model, tools
analytics available, latency, scalability), but the trend seems to provide a unique framework for Decision
www.interpreter.eu
D2.3
Support Systems (DSS) to control room operators and planners. Of course, DMS, OMS and AMI are more
distribution oriented, while EMS and DMS can be related to the transmission level, but this depends on
the regulation and market in each country.
The fourth category can be implemented as a separate platform, since it came years later than the
previous ones. Technologies adopted for smart meter implementation severely affect the possibility to
provide considerable advances and exploiting full potentials (e.g. two-way communications, final user
interaction, dynamic pricing, deployment of DR rules.)
Finally, the last category refers to the possibility to sell new services by new actors (e.g. Energy
Community Manager, Aggregator, VPP Manager, BRP) due to the recent evolution of the energy market
and regulation. This point includes platforms adopted by those subjects that do not hold and operate a
power system, but they are allowed to sell energy services. In recent years we have witnessed a rapid
growth of new stakeholders with their own proprietary solutions for engaging final users and
prosumers. In most the of the cases they adopt data-driven platforms where it is possible to integrate
different signals from different sources (e.g. energy, weather, occupancy, costs, indoor temperature,).
Electricity consumption is generally acquired from proprietary hardware installed at customers’
premises, able to receive signals for the demand response mechanism. In the near future, full
integration of AMIs and the interoperability of the systems would probably allow to have access to smart
meters and deploy demand-side management rules directly on the meter. IoT-cloud architectures can
be generally used for this purpose, where the analytics are usually executed. In some cases, a
marketplace can be also part of the platform.
SCADA is not taken into account in this categorization, because it is a consolidated technology and it no
longer represents the state of the art in this analysis. In the following sub-sections information is
provided for those platforms which are useful for the scope of this document. Therefore, EMS is
excluded, as it seems to be more oriented to power transmission and market analysis which is out of
scope of this project.
2.2.1. DMS – DISTRIBUTION MANAGEMENT SYSTEM

The Distribution Management System (DMS) is a Decision Support System (DSS) that supports control
centres and field workforce for improving the efficiency of the distribution system supervision and its
connected devices. It basically provides advanced controls that also provide benefits for the security &
safety of the system and for the power quality due to advantage in reliability and resiliency of the
system. [11].
DMS has historically evolved as an extension of the SCADA systems, where the growing volume of data
received from the field and the increasing performance of the optimization algorithms has led to the
creation of additional modules for service applications, which have been gradually aggregated into a
more structured solution (see ADMS).
As a matter of fact, each vendor develops its own technology, with its own terminology, so it is possible
to find DMS with different application ranges and solutions, but at least three provided main
functionalities can be identified [10]:
1. Monitoring and Communication. Through the SCADA, or sometimes through different SCADA,
DMS should have the capability to establish a bi-directional communication between control
rooms and RTU/IED.
2. Analysis and Control. DMS should provide network analysis supporting the control room
operators identifying optimal set-points of equipment. Analytics and simulation functionalities
are often organized as follows:
www.interpreter.eu
D2.3
a. Core Functionalities: State Estimation, Load Flow, Optimal Power Flow, Unbalanced
Power Flow, etc.
b. Real Time Operation: Volt-Var optimization, Load Forecast, Generation Forecast, etc.
c. Fault Management: Fault location, isolation and restoration.
d. Off-Line Services: Contingency Analysis, Short circuit analysis, Network Planning,
Operator Training Simulator.
3. Visualization and HMI. Advanced geographical and schematic (single-multi wires) visualization
are essential tools in control centres. In many cases geo-mapping and GIS interfaces are
becoming common services as well, to obtain a clear status of the actual operating condition
and support operators with their knowledge. Other interfaces and services may be towards
metering infrastructure or other external platforms (CIS, weather, etc.).
A typical DMS architectural scheme is reported in Figure 2 [10] :
FIGURE 2: COMMON ARCHITECTURE DIAGRAM OF A DSM.
2.2.2. OMS – OUTAGE MANAGEMENT SYSTEM

The OMS is a software platform devoted to identification and solution of outages and in many cases
includes the coordination and management of the crew.
Distribution systems have been considered the critical section at the end of the energy supply chain,
with consequences in quality of services and reliability of the network. The development of OMS is
intended to overcome this gap and improve the efficiency of the grid operation. According to [12]
around 90% of outages occur at MV and LV level. This percentage seems obvious but assumes a critical
value if we consider the recent central role of distribution systems with the diffusion of DG and
upcoming disclosure of DR potentials.
Even though for OMS standardized specification and platforms exist, they may differ across vendors. It
is generally composed by a suite of tools covering the following functionalities [10], [13] :
1. Preliminary Assessment. Data analytics tools for predictive and preventive maintenance
analysis and damage forecast.
www.interpreter.eu
D2.3
2. Outages tracking and management. Fault location, isolation and restoration (if not present in
DSM), ranking the restoration efforts and reporting information about the lines affected by the
event and number of final users involved.
3. Crew Management.
4. Interface with other systems. In some cases, it is possible to receive inputs from AMI, CIS and
call centres in order to generate new tickets or improve the assessment analysis. In the same
way data from OMS can shared with other platforms (DMS, GIS, etc.) for parallel analysis.
A typical OMS architecture is depicted in Figure 3 [10]:
FIGURE 3: COMMON OMS ARCHITECTURE [10].
2.2.3. EMS – ENERGY MANAGEMENT SYSTEM

Similar to DMS and OMS, EMS receives data from SCADA for controlling and optimizing the performance
of generation assets and transmission lines. It is generally aimed at organizing the dispatch of power
flows and controlling the overall balance of the system for both, generators and loads.
It has been adopted by TSOs, but in recent years it is possible to find downscale solutions for microgrids
or even for domestic applications. Moreover, with the evolving role of the DSOs and the formation of
regional markets and local communities, according to the regulations in force, DSOs could be equipped
with EMS as well.
In general, an EMS is composed by a suite of tools covering the following functionalities:
1. Real-Time Applications. Active and reactive power control, Optimal power flow (OPF), load
shedding, control sequences, alarms/events manager, etc. In some cases, Wide Area
Monitoring Systems (WAMS) can be interfaced with EMS
2. Dispatch and Scheduling. Generation dispatch and control through security and economic
constraints, closed-loop control, reserve monitoring, generation and load forecast, energy
scheduling, unit commitment
www.interpreter.eu
D2.3
3. Distributed Generation Control. For small-scale applications (microgrid, VPP, etc.) EMS can
provide DG control and BESS control, EV charging station monitoring and control, and
interaction with building energy systems.
2.2.4. AMI – ADVANCED METERING INFRASTRUCTURE

Smart metering has sensibly improved the monitoring and control of final nodes in distribution grids,
providing a great number of advantages and progresses. The AMI is the cyber-physical system that
provides a two-way communication between DSO and smart meters at final users. As a matter of fact,
AMI has been frequently deployed as a stand-alone system (in parallel with the existing SCADA), but the
availability of data from smart meters for SCADA, DMS and OMS has represented a crucial object of
investigation in recent years (see ADMS). Fiscal data are always be managed in a dedicated way, with
different protocols and security restrictions compared to traditional SCADA signals.
The technologies and constraints for data acquisition and transmission generally depend on national
regulation in force in each European Country.
2.2.5. ADMS – ADVANCED DISTRIBUTION MANAGEMENT SYSTEM

In previous sections platforms for distribution and transmission purposes have been described. Those
solutions are typically modular and in ADMS they are interconnected through a common bus for data
sharing. In Figure 4 [10] a typical architecture diagram for ADMS is represented. According to the
interoperability concept described in previous sections, EMS, DMS, OMS and SCADA could be coupled
in a common framework if each platform was developed following the harmonization standards.
Therefore, DSOs and TSOs should be allowed to integrate their legacy systems with updated solutions
and operate within a unique environment. According to such hypothesis the implementation of ADMS
should be vendor-agnostic and it would bring the possibility even to small operators to easily improve
their control system.
www.interpreter.eu
D2.3
FIGURE 4: EXAMPLE OF ARCHITECTURAL SCHEME FOR ADMS [10].
ADMS functionalities vary, mainly depending on the components which compose the system. If AMI is
integrated too, the grid operator can hold the entire set of operation and control tasks within the same
framework. Although this is not commonplace to date, the trend points in that direction and some
vendors are already providing such solutions.
2.2.6. DATA-DRIVEN PLATFORMS FOR NEW MARKET SERVICES

In recent years many market players have emerged thanks to the evolution of regulation and the
opening of new markets for energy services. Many of these market actors try to collect the production
and load capabilities from a large number of small prosumers with the goal to create an aggregated
offer for ancillary markets, demand response or even trading. The primary need is the monitoring of
assets (e.g. PV, EV, BESS). To do so, service providers typically install dedicated hardware at customer
premises for monitoring and sending control signals to those devices (e.g. for DR applications), because
smart meters are in general “closed”. In many cases IoT solutions are adopted to develop these
frameworks and machine learning algorithms are frequently used to extract information from the
connected devices.
The functionalities can be very diverse depending on the business area of the service provider. The
following list is a tentative proposal for categorization of these services:
1. Real-Time Applications: Monitoring and control of assets (closed-loop control)
2. Market-Place / Trading: Transactions between a coalition of prosumers and market provider or
P2P and/or blockchain transactions within autonomous energy communities
3. VPP / Aggregation: dedicated algorithms for optimal coalition creation according to specific
market requests, similar to classical energy scheduling or unit commitment
www.interpreter.eu
D2.3
4. Advanced Analytics: Forecasting of loads and generators, deep learning and machine learning
algorithms for data analytics (clustering, segmentation, prediction, etc.)
5. Interfaces: High level of interconnection with external services or platforms (e.g. API Rest
service)
www.interpreter.eu
D2.3
3. RELEVANT FEATURES FOR BENCHAMARKING
This section will explain the main features to explore in the benchmark analysis, according to their
relevance, the technologies behind them and their trend in today’s solutions.
The choice of relevant features that will be considered in this section can be addressed from different
points of view. In this case, since one of the main topics of the INTERPRETER project is the Smart Grid
concept, a good base to set these features is the Smart Grid Architecture Model (SGAM) as proposed in
[14]. As shown in Figure 5, this model is divided into five layers:
• Business Layer: Set regulatory and economic structures and policies, business models, products
and services.
• Function Layer: Functions and services, strongly related to use cases which are independent
from actors.
• Information Layer: Information exchanged between functions, services and components.
• Communication Layer: Protocols and mechanisms for the interoperable exchange of
information between components.
• Component Layer: Physical distribution of all participating components in the smart grid
(system actors, applications, power systems equipment, protection and control devices,
network infrastructure and computers).
FIGURE 5: SMART GRID REFERENCE ARCHITECTURE [14].
www.interpreter.eu
D2.3
Since the target of this document is to compare different platforms to extract information about the
interaction with smart grid layers, in the following section, relevant features are identified for each of
the SGAM layers. A summary of these features is given in Table 2.
SGAM Model Energy platform feature Definition

Business Layer Customization of services Ability of platforms to adapt to different
and applications regulatory scenarios
Function Layer Applications and services Set of applications and services to manage
the energy optimization in different contexts
Communication Layer Communication protocols Low-level definition of the way to exchange
digital messages between computing systems
APIs for integration Interface or communication protocol
between different parts of computer
programs
Information Layer Data Model or Ontology Specification of the meaning of the
information in a univocal way to enable
interoperability between different actors
Component Layer Scalability Ability of a system to handle a growing
amount of work by adding resources
Latency Delay in the transmission of information
Real-time processing Ability of continuous input, processing and
output of data in small time periods
TABLE 2: RELEVANT ENERGY PLATFORM FEATURES FOR INTERPRETER BENCHMARK ANALYSIS.
3.1. BUSINESS LAYER

Customization of services and applications
The continuously fast evolving framework of regulations and policies in the energy sector and its
regional diversity requires the ability of platforms to adapt to different scenarios. This ability is
fundamental for a proper functioning of any platform at present and in the future.
3.2. FUNCTION LAYER

Applications and/or services available and typology
The platform should integrate a set of applications and services to manage the energy optimization in
different contexts. These contexts derive different typologies of applications because the problems to
solve are not the same, for example, inside a house or in a district. Therefore, it is a relevant aspect to
analyze each application or service per platform in order to be able to interact with it in a proper way.
Moreover, these typologies allow to classify each platform in the energy sub contexts in a more accurate
manner.
INTERPRETER platform will integrate different applications, which can be divided in two categories: (1)
Efficient grid operation and maintenance and (2) Efficient grid planning. The benchmark analysis will
take into account this specific condition as described below, citing.
www.interpreter.eu
D2.3
3.2.1. APPLICATIONS FOR EFFICIENT GRID OPERATION AND MAINTENANCE
The INTERPERTER applications of this category are:
• Detection of non-technical losses: This application aims to identify non-technical losses
including irregularities/anomalies or frauds in the grid consumption measurement and
subsequent billing. This application requires Machine learning techniques to analyse patterns
to identify the origin of the anomaly.
• Ancillary services for DSO based on voltage balance and congestion: the aim of this application
is anticipating possible grid congestions. The main technique to achieve it is the forecasting of
the consumption with special interest in the high penetration of distributed variable generation.
• DSO/TSO interaction for ancillary services extension: this application is intended to go beyond
the LV level and provide support for frequency control at high-voltage level (TSO). The idea is
to coordinate many LV grids to regulate power or primary frequency reserves.
• Predictive maintenance strategies: The objective of this application is to optimize the handling
of faults and failures through the use of advanced data analytics and self-learning algorithms.
• Grid Control Optimisation and Self-Healing: This application is aimed to find the optimal physical
configuration of the network, in order to restore the service to most possible customers after a
fault, taking into account all loads and distributed generation. When a fault is detected, the
application recalculates the optimal distribution of load and generation considering the option
of physical reconfiguration. This application is based on techniques like reinforced learning (RL),
mixed integer linear programming (MILP) and multi-objective nonlinear programming (NLP).
3.2.2. APPLICATIONS FOR AN EFFECTIVE GRID PLANNING

The INTERPERTER applications of this category are:
• Automated grid modelling: this application considers available data (e.g. grid topology,
customers, consumption) to create a model of the LV grid. This application has been added to
grid planning, but its result (the grid model) will be employed for both, operational and planning
applications.
• Optimal reactive power compensation: this application aims to propose optimal equipment
characteristics and best location within the distribution grid for reactive power compensation
at MV and LV level.
• Planned phase balancing: the purpose of this application is to obtain a completely balanced grid
by proposing changes in the current grid configuration or in the future planned infrastructure.
This application will be based on the grid model, historical data and representations of the
behaviour of flexibility resources.
• Nodal capacity allocation: this application aims to calculate the nodal capacity of different grid
nodes to know the maximum limits of new RES units that grid nodes are able to receive ensuring
safe operation conditions.
• Dispersed storage unit location optimization: the functionality of this application is the
optimised sizing and siting of dispersed storage units. Through this tool, the system operator is
able to know the size (MW and MWh) and siting (location and number of installations) of energy
storage solutions needed to solve network congestions or reactive power flow control issues.
• Environmental and economic assessment: this application aims to assess the environmental
impact of a proposed technical solution and configuration.
www.interpreter.eu
D2.3
3.3. COMMUNICATION LAYER
The context of the communication layer is focused on the protocols and mechanisms for the
interoperable exchange of information between components. Therefore, this section is focused on
describing the communication protocols and the APIs for integration.
Communication protocols
The communication protocols define at low level the way to exchange digital messages between
computing systems. The communication protocols must support authentication, error detection and
correction, and signalling [15]. The communication protocol concept is a generic concept related to the
world of telecommunications but, from the point of view of the benchmark analysis, it is interesting the
wide acceptance in the world of energy management.
It will be important to determine the communication protocols in the following OSI (Open Systems
Interconnection model) levels. The list below lists the three relevant levels and gives some examples:
• Physical and data link level: Wi-Fi, RS232, Ethernet
• Transport level: TCP, UDP, DLMS/COSEM
• Application level: HTTP, Modbus, DLMS/COSEM
APIs for integration

Application programming interface or API [16] is an interface or communication protocol between
different parts of computer programs intended to simplify the implementation and maintenance of
software.
One of the main challenges of INTERPRETER project is to integrate many and heterogenous applications.
Hence, this communication feature plays a very relevant roll in this project.
Most relevant examples of API types are those which are based on REST (Representational state
transfer) and SOAP (Simple Object Access Protocol). These types of APIs are widely extended on the
INTERNET. In addition, there are other types of APIs based, for example on CORBA or RPC, but they do
not have such widespread acceptance as REST and SOAP.
Another important feature to consider is the API Data Model. This is the model of the messages used
by the API. A good election of this data model could greatly simplify the transformation of messages
between services. This feature is much related to the Information Layer, in fact, it could have been
described in the Information Layer, but it has been considered more convenient to do not separate from
the APIs for integration, which is more appropriate to be described in this layer. In this context, the use
of a common semantic model is very valued with special interest in Context Information Management
CIM [17] API definition in ETSI, (not to be confused with Common Information Model, IEC CIM [18]). The
purpose of the Context Information Management API (ETSI) is “enabling close to real-time access to
information coming from many different sources”. The Context Information Management [17] defines
an API to interact with devices and applications, while Common Information Model [18] is a set of
standards for the harmonization of data from electric systems.
3.4. INFORMATION LAYER

The main purpose of the Data Model, also called Ontology, is to specify the meaning of the information
in a univocal way to enable interoperability between different actors. According to IEEE 610,
“interoperability is the ability of two or more networks, systems, applications, components or devices
www.interpreter.eu
D2.3
from the same vendor, or different vendors, to exchange and subsequently use that information in
order to perform required functions”.
The aim of analysing this feature is to evaluate the Data Models used by the platform from the point of
view of energy services. In this context, the following initiatives are very relevant and are therefore
taken into account in this study:
• Common Information Model (CIM): developed by IEC (International Electrotechnical
Commission) [18].
• OpenADR: designed to facilitate automation of Demand Response operations [19]
• Energy@Home: this model is focused on home networks [20]
• Smart Appliances REFerence (SAREF) ontology: shared model of consensus that facilitates the
matching of existing assets in the smart appliance’s domain [21].
The assessment of this feature will consider very positively whether they are based on data models like
the previously mentioned.
Other considerations to evaluate are:
• Scope: Low voltage, Medium Voltage and High Voltage.
• Definition level: the definition should be based on appropriate languages to define data models
or ontologies like UML or RDF.
• Brands or Associations adopting the Data Model.
It may be mentioned here, that this assessment is fundamental for the INTERPRETER platform
development, as it is foreseen to define the data model based on industrial standards, where a project
data space will be specified. This data model must consider the following aspects:
• DSO/TSO information
• Potential partners’ data platforms
• Grid sensors
• Measurements
This information can be modelled with different data models or ontologies. The benchmark analysis is
intended to provide valuable knowledge about the standards and trends which are most suitable in the
different contexts of the electricity grid (LV, MV, HV).
The definition of the data model is decisive for the integration of the different sources of information in
a common ground or Common Information Model. In addition, the data model facilitates replicability
and exploitation of INTERPRETER applications.
During the assessment, another two special conditions of the data model will be evaluated, as thay are
crucial for the concept of INTERPRETER:
• The Data model must be legally open, so it should be accessed in a public domain.
• The Data model must be machine readable and non-proprietary, so it can be accessed and used
via common standards.
3.5. COMPONENT LAYER

This layer addresses topics like the physical distribution, system actors, applications and power system
equipment. Since scalability and latency are features which have a great influence on the topics
www.interpreter.eu
D2.3
previously mentioned, these concepts are described in this section. Finally, real-time processing is
added as it is closely related to scalability and latency.
Scalability
Scalability is the ability of a system to handle a growing amount of work by adding resources [22]. The
assessment of this feature of a platform will consider the following aspects:
• Horizontal scaling: the possibility to add more computational nodes in the system.
• Vertical scaling: the ability to extend the capacity of a single hardware with more allocated
resources. For example, in case of a computer, this extension could be carried out by adding
more RAM or another hard drive.
Moreover, in power system control, scalability can also be considered from an electrical point of view:
that means up to how many electric nodes (single and three phase) the platform (Scada, DMS, etc.) is
able to manage.
Latency
The concept of latency, related to communications, is interesting for managing smart grids in general.
It is referred to the delay in the transmission of information and depends on the amount of information
transmitted. The latency is measured in milliseconds (ms). This factor can be decisive in a platform when
high response speed is required in certain smart grid operations related (see real-time processing).
Real-time processing
According to [23] “Real-time data processing involves a continual input, process and output of data.
Data must be processed in a small time period (or near real time). Radar systems, customer services
and bank ATMs are examples”.
In the context of Smart Grids, this feature could give the possibility of anticipating to critical situations
like sudden overheating of the lines caused by a large excess of energy generation and a large decrease
in consumption.
www.interpreter.eu
D2.3
4. BENCHMARK OF DIGITAL PLATFORMS FOR ELECTRIC SYSTEMS
In this section, a technology review has been conducted in order to understand the actual adoption of
most relevant features of energy platforms. This benchmarking is based on the platform categories of
platform selected in chapter 2 of this report and it will be focused on observing those features and
parameters identified as relevant for INTERPRETER in chapter 3. In Figure 6 the strategy for this
benchmark analysis is represented.
Categories of Platforms
Data
DMS OMS EMS ADMS AMI
driven
SGAM Layers
Business Functional Communication Information Component
• Customization • Applications • Communication • Data Model / • Scalability;

of services and/or Protocol; Ontology • Latency;
and services • API for • Real-time
applications available integration processing
Features for Benchmark
FIGURE 6: STRATEGY FOR BENCHAMRK ANALYSIS OF ENERGY PLATFORMS.
Before describing the benchmark analysis in detail, it is important to explain that this is not a typical
benchmark as in computer science, thus no test has been conducted on software tools for evaluating
the processing speed or other performance criteria. In this case a comparison of the different solutions
already available is carried out only at literature review level, with no specific trials or tests.
4.1. COMPARISON OF AVAILABLE SOLUTIONS

Finding public information about such critical aspects of commercial solutions is challenging. To
overcome this issue and provide a broad view of the existing products, some platforms not already
market-ready have been considered. Those are the results of research and innovation activities with a
high TRL. This is required because some of these more advanced solutions meet the recent needs of
certain markets. Therefore, in addition to the features identified in chapter 3 ((Table 2), three more
aspects of comparison have been added, in order to provide a better understanding of how the market
is actually affected by these innovations: “Category”, “Type of License” and “Maturity”.
• Category: will group the investigated platform according to the categorization explained in
chapter 2; only those categories will be taken into account.
www.interpreter.eu
D2.3
• Type of License: is a parameter that will clarify if this sector is open only to proprietary closed
solutions, or there could room even for open source.
• Maturity: will provide information about the actual status of the platform, if it is ready for
market applications yet or still on a previous level of development.
Considering the huge number of this kind of new platforms, research-grade solutions (low TRL) have
been discarded from this analysis.
For obvious reasons, many technical specifications are not publicly available. That implies some
difficulties in surveying information. This condition has an impact on the choice to consider one platform
rather than another for some large enterprises that have many solutions in their portfolios. For the
same reason, other platforms have been considered whether all information are not present. Therefore,
for large enterprises with different solutions for different market applications the best-documented
solution is considered.
For sake of clarity, the data collected for the benchmark analysis has been split in the following Table 3
(Part A) and Table 4 (Part B).
A brief interpretation of the two tables reveals that the platforms are basically organized into DSM-like
platforms and data-driven platforms. The first category is traditionally oriented for grid operation, while
the second one is for new market players. The major part of the analysed solutions is market ready with
business license; but it is interesting to remark that 4 platforms are open source (platforms #2, #3, #5
and #6). Two of these four platforms are associated to commercial actions from vendors. In particular,
platform #2 has proposed an EMS solution for BESS management, while platform #6 is a more generic
asset manager for DG and DR applications.
Concerning the Connectivity aspects, DMS-oriented suites are based on SCADA systems, so they can
rely on a full spectrum of connectivity options. Data driven platform are likely to be IoT oriented and
they cannot have the same capability as SCADAs. Although it would be more convenient to have more
information, it must be highlighted here, that JSON (JavaScript Object Notation) is a very common open-
standard file format that is used by platforms #2, #3, #5 ,#10 and #12 (5 out of 12). Even if based on a
limited number of samples, this seems a relevant percentage for adoption of JSON.
In addition, REST (REpresentational state transfer) API or also called RESTful Web Services are needed
in order to ensure connectivity with external services and data sources. They are used in platforms #3,
#5, #10 and #12.
It is well known that JSON is currently the most widely used data format for data interchange through
INTERNET. In the same way, API REST Web services are commonly used as the architecture to exchange
information in JSON format.
Information concerning ontology and Data Model used at the core of the platforms are not easy to find.
It seems that consolidated brands have already adopted the CIM ontology [18], while others prefer to
keep with proprietary solutions. It can be observed that major vendors (platforms #4, #8 and #9) have
already implemented CIM data model and this trend is confirmed also from other vendors not included
in this analysis. As mentioned at the beginning of this chapter, only the platforms with enough
information have been benchmarked. Nevertheless, other major vendors have been checked even if
not present in this document. With special regards to CIM adoption, it is worth mentioning that General
Electric’s ADMS “PowerOn” has developed a CIM connector [35] and also Siemens EMS “Spectrum
Power” has developed capabilities for CIM compliant data model export [36]. As a matter of fact, CIM
allows to overtake vendor format and interchange data among different applications. Indeed, the
development of harmonized models and ontologies take advantage of deregulation of the energy
industry.
www.interpreter.eu
D2.3
TABLE 3: DATA FOR PLATFORMS BENCHMARKING (PART A)

Platform 1 Platform 2 Platform 3 Platform 4 Platform 5 Platform 6
Name Sogno [24] OpenEMS Volttron EcoStruxure FUSE [28] Dynamic
[25] [26] [27] Demand 2.0
[30]
Brand GridHound OpenEMS Pacific Schneider Atos Open Energi
Association Northwest Electric Research &
(Fenecon) National Innovation
Laboratory
Category DMS EMS advanced ADMS IoT data- IoT data-
scada driven driven
platform platform
Type of License - Open source open source Proprietary open source open source
(copyright under
by Fenecon) Apache
License v2.0
(registered
trademark)
Maturity Research Ready for Ready for Market ready for Market
Grade Validation Validation ready validation ready
Commu- physical - TCP/IP, RS485, RS485, - ad-hoc
nication RS485 Ethernet, Ethernet, solutions
Protocol trans- IEC61850, Modbus BACnet, IEC61850, HTTP -
port IEEE RTU adn DNP3, oBIX, IEC60870,
C37.118 TCP, SEP2, MODBUS,
Sunspec, ModbusTCP RTU,
other /IP, Modbus MODBUS
propietary RTU, SEP2, TCP/IP,
protocols OCPP DNP3 (from
SCADA
module)
API Proto- for data Modbus TCP json-rpc API Python API REST API -
col ingestion/int or RTU Slave json
errogation API,
and service Websocket/
access (not JSON-API,
detailed) Connection
to Backend;
data proprietary Open data -
model model
Data Model / CIM Volttron CIM FUSE data -
Ontology data model model
(support based on
open ADR) FIWARE and
SAREF
Applications/Servic State Peak- weather Modularity Load Frequency
es Estimation, Shaving data with DMS, Forecasting, regulation.
Fault Reactive integrationa OMS, EMS, Basic Energy
Location Power sset GIS and AMI Analysis trading.
Isolation voltage simulation (load and Capacity
and characteristi (load, pv generation), services.
www.interpreter.eu
D2.3
Restoration, cs Q-by-U, and bess), Clustering & Peak price
Generation Energy DR events; Segmentatio managemen
and Load Storage n, Booking t.
prediction, Cluster, and Constraint
Power Charging/Dis Publishing managemen
Quality charging (with t.
Evaluation; advanced blockchain Energy
controls, transactions efficiency,
EV charging ) Energy
booking/con Scheduling,
trol
PV inverters
monitoring
and
controls;
Customization of only short- possibility to - - yes, partially -
Applications/Servic term edit code of (Forecasting
es prediction, services customizabl
e based on
day ahead
or intraday
prediction;
Clustering
customizabl
e for
features and
timing; UI
customizabl
e).
Scalability - - - - limited by -
HW
requirement
Latency / Real - - - - near real -
time processing time (for
platform
core)
www.interpreter.eu
D2.3
TABLE 4: DATA FOR PLATFORMS BENCHMARKING (PART B).

Name Opower [30] Network Survalent Smart Monet NETGIS © 3
Manager 1 ONE ADMS metering 2 [33][34]
[31] [32]
Brand Multi- ORES
vendor
Oracle ABB Survalent solution Siemens
Category data-driven DMS ADMS AMI IoT-Data GIS and
platform for (modular driven DMS
customer solution platform
engagement with scada,
DMS and
OMS)
Type of License Proprietary Proprietary Proprietary Proprietary Proprietary Proprietary
(Oracle,
coldfusion,
mapguide,
Autodesk)
Maturity Market Market Market Market Ready for Market
ready ready ready ready validation ready
Communic physical N/A based on Ethernet Ethernet Based on Based on
ation abb scada Siemens Siemens
Protocol scada TG8000
scada
transpor N/A OPC, IEC HTTP Modbus Based on Web base
t/ 61850, TCP/IP, Siemens application
applicati Multispeak IEC60870-5- scada
on to DLMS, 104,
ICCP, SNMP IEC61850,
SNMP, FTP,
IEC-870-5-
102;
API protoco IEEE POSIX, NDA API n/a REST API - webservices
l DB Server (Network
API, ActiveX Database
wrapped DB Access)
Server API,
ODBC, OPC,
DAIS, TASE,
IEC, DNP
data Proprietary proprietary n/a proprietary - -
model
Data Model / Proprietary CIM Multispeak / - - Proprietary
Ontology CIM
1
It includes OSM functionalities
2
A set of applications for LV and MV smart metering. Information provided by Cuerva
3
Information provided by ORES
www.interpreter.eu
D2.3
Applications/Servic Energy State DMS Supply EV manager, Topology
es Efficiency, Estimation; Applications Points Load; Assets processor,
Peak Load Flow; Topology Fraud manager, GIS
Managemen Short Processing; events; DG forecast, interface
t, Load Circuits; Network Billing; DR
Shaping, Optimal Modelling; Electric functionaliti
DER mgmt, Feeder Power Flow; quantities es,
Smart Reconfigura FLISR; monitoring,
Meters tion; Volt-Var Fault
engagement Loss Optimizatio detection,
Minimizatio n; MV and LV
n; Voltage models,
Load regulation; Feeder
Managemen Short-Term mapping,
t (Feeder Forecast;
Voltage OMS
Control and Applications
Load Outage
Switching); analysis;
FLISR; Crew mgmt;
Automatic Reliability
switching indices;
plan Switch
generation; order;
Network
Modelling;
Customization of - - - - - Customizati
Applications/Servic on by
es developmen
t (only by
developmen
t)
Scalability - - - limited by - Limited by
HW hardware
requirement (number of
servers),
about
40.000
substations
monitored
Latency / Real - - - Granularity: - near real
time processing 1 hour, 15 time
mins, 5mins;
Data
availability 1
day, 1hour,
5mins
www.interpreter.eu
D2.3
On the other hand, platform #3 ontology is based on OpenADR standard, in order to enable full demand
response potentials, while platform #5 adopts a data model based on SAREF ontology for full IoT
interoperability.
Considerations about applications/services and their customization are summarised in the dedicated
following Section 4.2.
Parameters like scalability, latency and real-time processing (i.e. the possibility to running real-time or
nearly real-time processes) have not been easy to identify during this survey. They are not only tightly
bounded to the performance of a product, but there is also a hard correlation with the entire cyber-
physical system. This means that the communication infrastructure heavily affects the possibility to stay
within given thresholds. While in this analysis only the capability of the platforms is considered.
Scalability is another parameter which is difficult to analyse due to the lack of information. Nonetheless,
it is possible to add some considerations about it. During the survey for the benchmark some platforms
for market operators have been considered as well (even though they are not included in Table 3 and
Table 4), that means digital infrastructures for the implementation of new market services. Traditional
SCADA-based platforms have already available consolidated solutions for different grid sizes (from
microgrid to country-scale systems), and no sensible advances are highlighted. Platform #12 for instance
is able to manage at the moment 40,000 substations and has a scalability only limited by the number of
servers as in platform #5. The focus for scalability is now oriented to new market applications, where
the involvement of a great number of small players could originate huge volumes of transactions.
Blockchain applications are typical examples where scalability is strongly required for such systems. The
challenge resides in the ability to collect and exploit the measurements from devices at final users in a
short-term timeline, and eventually enabling thousands to millions of transactions. IoT and cloud-based
solutions are enabling technologies for big data platforms. The possibility to analyse large volumes of
data is crucial for upcoming market implementation (local and community energy market, VPP
management, aggregation of small prosumers for ancillaries and DR mechanisms) and other business
innovations (optimization of customer engagement, clustering and segmentation of the portfolio, tariff
customization, etc.).
Even though INTERPRETER is not specifically oriented to this goal, it definitely includes the possibility to
receive data from smart meters for improving the observability of LV network and providing new
services at distribution level. The collaboration with external operators is envisioned through the
available services. In this sense, INTERPRETER should guarantee the possibility to receive data from a
variable number of final users for ensuring the availability of services even for larger DSOs.
Latency and real-time processing can be considered as critical parameters too, with obvious
dependence from the communication system of the smart grid. Actually, both of them contribute to
the so-called Quality-of Service (QoS) in power system performance. Therefore, it is quite difficult to
understand the real ability of a digital platform to achieve real-time or nearly real-time processing. In
[37] useful information for understanding the typical values of QoS (including latency) thresholds are
reported. Some of these values are listed in Table 5 considering three typical grid operations at different
voltage levels: oscillation monitoring, state estimation and demand response.
Even though, no specific values for latency could be derived from this benchmark analysis, results can
be useful for defining some communication requirements of INTERPRETER solution and the
performance of the services to provide. In the light of the objectives of this report, this Table 5 provides
useful information for the interaction of the solution to be developed with existing platforms and
services.
www.interpreter.eu
D2.3
TABLE 5: QOS REQUIREMENTS FOR SMART GRID APPLICATIONS [37].

Oscillation
Application State Estimation Demand Response
Monitoring
Purpose Control Monitoring Peak shaving
Latency < 100 ms <1s From seconds to hours
Category Real time Near real time Slow
Device PMU Substation or PMU Smart device Gateway
Rate 30 updates / s 5 updates / s 4 updates / min
Scope Selected PMU All PMUs All gateways
# publishers < 100 Hundreds From hundreds to millions
Location Transmission Distribution Behind the meter
4.2. ADOPTION OF SERVICES AND APPLICATIONS

Due to the heterogeneity of the platforms, it is interesting to understand if the services proposed by
the INTERPRETER project have been reflected somehow in the survey. This information is reported in
Table 6, where a mapping of INTERPRETER applications vs. benchmarked platforms is provided. The goal
of this table is to shed light on the actual utilization of services in the applied energy industry.
Information has been obtained from the vendor’s websites previously visited for Table 3 and Table 4.
It can be noticed that some services are quite popular in the digital energy framework. Many
correspondences can be found in the classical SCADA/DMS frameworks (that is supposed to be the
natural evolution for DSO grid management). The possibility to join different modular suites in a unique
ADMS-like platform (see platforms #4, #7, #8, and #9) enables a wide catalogue of services. Hence, DSOs
are supposed to accomplish all their activities by a unique platform. This very same trend is also
confirmed by some observed platforms not directly included in this benchmark [35] [36], characterized
by high modularity and with a complete portfolio of services available. Some applications like “Detection
of Non-technical losses” are prerogative of AMI and/or CIS like software, thus it has low correspondence
in the table. Also the “DSO/TSO service coordination tool” has lower correspondence in this table. Here,
it is important to remark that one of INTERPERTER’s peculiarities resides in the possibility to provide
services for DSO and TSO at the same time, taking advantage of a semantic repository to harmonize the
information model among different system operators. This crucial element of the architecture grants
the possibility to offer this kind of services for DSO-TSO coordination, trying to overcome
interoperability issues (see chapter 2). In this analysis one major electric enterprise (platform #8)
provides a similar service in a pure DSM suite where DSO can share (and receive) their data with TSO
for a safer grid operation. On the other hand, a similar tool in platform #6 has been conceived for market
operators in order to send/receive information from TSO and DSO and participate at regional and local
flexibility markets.
www.interpreter.eu
D2.3
TABLE 6: MAPPING OF INTERPRETER APPLICATIONS VS. BENCHMARKED PLATFORMS.

Applications PLATFORMS
#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12
Detection of non-
* 
technical losses
Optimal grid
reconfiguration and self-  * 
healing
Predictive Maintenance
 
strategies for grid assets
Grid congestion and
*    
Voltage balancing
DSO/TSO service
* * *
coordination
Optimal reactive
    
compensation
Planned phase balancing *   
Nodal capacity allocation *   
Optimal location of
* 
dispersed storage
Environmental and
* * *
economic assessment
(* means that the service only has some similarities with the equivalent INTERPRETER application)
From the applications matching in Table 6, it is possible to deduce the following considerations:
1. The INTERPRETER applications are more oriented to SCADA-like platforms (DMS, OMS, EMS).
As a matter of fact, most of the correlations are in the columns corresponding to those typical
DSO platforms. This is not a mystery, since the modularity of DMS software allows the
composition of different packages and suites.
2. There are few correlations with assets managements. Since INTERPRETER is based on grid
analysis and modelling, most of the resulting services are based on those models (i.e. the
applications are oriented to grid optimization (lines and substation equipment, rather than
DG, BESS and load management).
3. There is a poor correspondence with DSO/TSO coordination service. While most of the services
have two or three correlations with existing platforms, DSO/TSO coordination has only two
weak relationships (it means the identified applications in existing platforms are not the same
of INTERPRETER service, and they only share some generic similitudes). This means that there
is no specific service available today with such specific ability in generic market solutions.
4. The two platforms specifically developed for demand response and microgrid control (#3 and
platform #11) seem to have poor correlation with INTERPRETER applications. INTERPRETER
applications cover many aspects of grid optimization in a more traditional way. On the other
hand, some innovation derived from full implementation of smart grids technologies can still
www.interpreter.eu
D2.3
be provided. Services like asset management, renewable generation forecast, EV booking and
brokering, dispatch & scheduling, are more oriented to new distribution operation at smaller
scale or for local energy market implementation (e.g. VPP management, energy community
islanding, microgrid operation, etc.).
5. DSOs structured with enough ICT internal expertise could consider the possibility to develop
in-house solutions (Platform#12). The reasons for taking such decision can derive from internal
policies (not depending from external licensing, privacy, etc) or from technical aspects
(customized solutions, specific needs, proprietary code). In this case obviously there is a weak
correspondence with INTERPRETER applications since the platform has been developed by a
project’s partner. The DSO has implemented an ad-hoc solution for mapping network topology
and events on a georeferenced graphic layer.
6. Most of the analysed platforms are providing interoperability with georeferenced data. This is
an added value service that could enable significant improvements in DMS / OMS productivity
and in crew management. Asset manager can also take great advantage from georeferenced
data with sensible improvements in business operations. This is also witnessed from Platform
#12 where ORES developed its own solution for integrating GIS functionality.
7. It seems that it is not easy in general to customize and personalize analysis and simulation
tools in typical SCADA/DMS-based applications. To overcome this issue, in-house solutions like
platform #12, have the advantage to bring ad-hoc services that can be easily adapted or
modified for future needs. Other home-made solutions from ORES – not reported in Table 4 –
cover the management of DG, generation forecasting and customer ticketing. On the other
hand, the sample of four open-source platforms included in this benchmark, of course have
the possibility of a full access to code. These platforms are mostly oriented to assets
management.
www.interpreter.eu
D2.3
5. COMPARISON BETWEEN DSO AND TSO PLATFORMS
A critical aspect in system operators’ platforms is the possibility to share common information between
TSOs and DSOs. This gains even more relevance considering the emerging new roles of DSOs as assumed
in the “Clean Energy for all Europeans” Package [38]. The increasing quantity of renewable sources
connected to MV and LV systems along with demand-side management from final users have converted
the traditional unidirectional course (from TSO, to DSO, to final users) in a new bidirectional and
multibranch process where DSOs are expected to gain more centrality. Thanks to their closer position
to new assets, DSOs will be able to collaborate in DG management for peak load smoothing and to
procure voltage and reactive support to TSOs [39]. This new vision of DSO’s role also changes the
perspective on how to evaluate a digital platform for distribution grid management and the
functionalities they should have. At the same time, for the aforementioned reasons, all the features
about interoperability are now relevant for both actors, TSO and DSO.
The TSO has responsibility for system security and the coordination of ancillary services provision on
the transmission level [40]. The DSO is responsible for continuity of service in distribution networks. On
the one hand, the TSO will continue to have the primary responsibility for coordination of balancing,
frequency control and system recovery, while the DSO will retain responsibility for the management of
distribution networks. On the other hand, a closer coordination between the TSO and DSOs is
envisioned, which will enhance the latter’s role in the management and security of modern power
systems.
The level of observability/monitoring and automation has traditionally been much greater at the
transmission level. As voltage levels decrease, the intensity of monitoring and automation decreases.
This intensity varies significantly between DSOs and there is no clear answer on what exactly the
situation is on the medium and low voltage networks. Even though there are also variations on the
transmission level among TSOs, there is a higher level of standardization, and differences tend to be
smaller.
While both TSOs and DSOs use active system management (ASM), there are significant differences in
those platforms. ASM is a set of functionalities and tools performed and used by DSOs and TSOs for the
cost-efficient and secure management of their networks [40].
All TSOs employ ASM to supervise and control the transmission network. According to a survey among
36 participants[41], 96% of DSOs employ SCADA systems. Further, 60% of the DSOs reported the use of
a DMS for enhancing network security, minimizing losses and optimizing the capacity of power lines
[41]. The functionality of a DMS can be divided into the following categories:
1. System monitoring
2. Decision support
3. Control actions
Control actions can be split into automated (performed by the DMS without operator intervention) and
manual. Manual actions can be further divided into remote and manual control. In the former, the
operator can perform actions remotely, while in the latter actions must be performed by the DSO’s
specialized crew upon demand [42].
State estimation is fundamental for ensuring the stability of the power system and that’s why it is
performed by all TSOs. On the contrary, according to [40], only 40% of the DSOs perform such tasks,
56% employ forecasting tools and 48% of respondents indicated the use of dynamic ratings. As
expected, monitoring and control functions at the LV level are currently very limited.
Interestingly, 70% of the participants reported a sampling rate for MV feeder monitoring of less than a
minute. However, only 40% of respondents stated that much of their network is currently automated,
www.interpreter.eu
D2.3
and less than 11% monitored their MV/LV transformers. The results of the survey are revealing
regarding the deterioration of monitoring and automation as voltage levels decrease.
Only 13% of MV/LV transformers can be remotely tap-controlled, in contrast to 92% of HV/MV
transformers. Only 4% of protection devices are capable of automatic reclosure on the LV, in contrast
to 83% on the MV level.
5.1. COMMUNICATION
A fundamental difference in the monitoring performed by TSOs and DSOs is communication with other
operators. TSOs need to communicate with neighbouring TSOs to ensure that no congestions occur, the
scheduled power exchanges are fulfilled and that stability margins are maintained. There is no indication
that regular communication among DSOs takes place, and currently only limited information exchanges
between DSOs and the TSO occur. According to [40], these exchanges are limited and ad-hoc. In other
words, they do not happen on a regular basis but only when some issues arise. Only 30% of the
participants reported a regular exchange and 20% on demand. DSOs can potentially provide services to
the TSO, mainly concerning load forecasting and voltage support.
The existence of a formalized framework for information exchange between DSOs and the TSO will
enhance the operation of the power system and increase its reliability. To this end, common data
models and procedures for information exchange must be established, along with the required ICT
infrastructure. The joint work presented in [39] suggests that TSOs and DSOs should work with the
industry in order to facilitate information exchange by defining proper communication interfaces.
5.2. MARKET FUNCTIONS

The definition of roles and responsibilities of all actors (network operators, market participants) at the
TSO-DSO interface is of significant priority for achieving improved coordination. Currently, TSOs are
heavily involved in the operation of the energy markets. Balance response parties must report their
scheduled net positions to the TSO and TSOs can interfere in the market clearing processes by imposing
additional constraints to ensure the secure operation of the system. Additionally, TSOs are responsible
for operating balancing markets and activating reserves. They are also handling various ancillary
services, i.e. they acquire primary and secondary frequency reserves, they need to calculate area control
errors and communicate the necessary signals to parties offering ancillary services, they receive
schedules by balance responsible parties etc. These operations currently do not involve DSOs.
However, there is ongoing research and discussions on possible TSO-DSO coordination on the
procurement of active and reactive ancillary services, which is closely related to the so-called flexibility
services. Regarding reactive power ancillary services, voltage has to be managed by the DSOs within
their control area such that it will not create imbalances in neighbouring distribution and upper
transmission grids. Future DSO ASM may need to incorporate market-related functionalities, so that
DSOs can procure flexibility services and/or work in coordination with the TSO in the procurement of
ancillary services. In the face of the upcoming large numbers of installed DERs, DSOs will need to employ
ICT, automation and smart metering infrastructure to provide real-time and accurate information to
TSOs in a timely manner, to enable and utilise the grid services from DERs. In short, suitable
communication and automation interfaces between TSO and DSOs will be crucial for such tasks.
www.interpreter.eu
D2.3
5.3. OPERATIONAL FUNCTIONS AND OPERATIONAL PLANNING
Each system operator has observability of its own system, which is high for the TSO and frequently low
in the case of DSO, particularly in LV systems. TSOs need and already use information to estimate and
forecast the state of the network on higher aggregation levels. This information is needed for a variety
of tasks [43]:
1. Monitor and update telemetry and telecontrol parameters within the control area
2. Adjust power flows and approve arranged interchange in the system
3. Curtail confirmed power interchanges that adversely impact system reliability
4. Deploy ancillary services for balancing generation and load considering reliability
5. Direct emergency procedures incl. load shedding and coordinate system restoration
6. Operate the control area to maintain load-interchange-generation balance
7. Conduct switching and develop automated switching regimes
On the other side, traditionally, DSOs usually do not perform these tasks, especially on high resolutions
and the LV network. However, due to higher DER integration, more detailed forecasting is needed.
Regarding dynamic data and measurements, access depends on the sampling rate: the higher the
sampling rate, the more relevant becomes direct access of the TSO. Some TSOs may thus be interested
in obtaining pilot measurements from selected DERs in the distribution system. In case the distribution
system contains phasor measurement units (PMUs), TSOs could benefit from accessing these PMUs to
obtain real-time data from the distribution level [44]. For DSOs though, direct access to measurements
in the TSO network is frequently not allowed or limited to measurements on the TSO side of TSO/DSO
substations.
With the objective of a better load and generation forecast at system level, considering that generation
will be more and more present at the distribution level (mainly due to PV systems), it will be necessary
that DSOs transmit forecasts and measurements to the TSO. TSOs will remain responsible of system-
level forecasts, but the quality of forecasts will be more tied to data provided by DSOs. This
decentralization will require several adaptations from DSOs: gather relevant measurements, create
forecasts and communicate them.
Conventionally, stability margins are determined by TSOs from available SCADA/EMS data. The accuracy
of those calculations can be enhanced by additional information from DSOs. Generation or load
shedding at a DSO level can be necessary in critical cases and can be requested by the TSO. A higher
degree of automation, facilitated by faster and more effective DSO-TSO communication, is crucial for
future power systems [44].
www.interpreter.eu
D2.3
6. CONCLUSIONS
In this document a brief analysis of existing platforms for energy distribution applications has been
carried out. This benchmark analysis started form a general context of today’s solutions for grid
monitoring and control and the identification of those solutions that fit best with INTERPRETER
objectives.
In this first framework definition, carried out in chapter 2, the following platform categories have been
identified for benchmarking:
• DMS – Distribution Management System
• OMS – Outage Management System
• EMS – Energy Management System
• ADMS – Advanced Distribution Management System
• AMI – Advanced Metering Infrastructure
• Data Driven platforms for new market services
These are basically large-scale applications for grid and asset management, commonly adopted by
system and market operators. The main aspects of their architecture, the advantage they could bring
(in the context of INTERPRETER impacts) and the services they could provide have been identified.
In chapter 3 the analysis has been detailed with special focus on some technical characteristics
(features). Smart grid platforms have been analysed considering the approach of the SGAM layers:
business, functional information, communication and component layers. For each layer one or more
features have been identified for the benchmarking.
• Business Layer: Customization of service and applications
• Function Layer: Applications and/or services available
• Communication Layer: Communication Protocol, API for integration
• Information Layer: Data Model/Ontology
• Component Layer: Scalability, Latency, Real time processing
Further preliminary data have been collected in the benchmark:
• Initial information: Name of the platform, Brand, Category, Type of license and Maturity.
From the benchmark analysis itself, the following conclusions have been obtained:
• SCADA/DSM-based platforms denote a wide range of connectivity possibilities in terms of
transmission protocols. But in general, RESTful web service in JSON format is the most common
methodology for data exchange and seems to be a future trend.
• Common Information Model (CIM) appears to be the state-of-the-art for backend (control
centre) data model interoperability. Most of the vendors and all the big players in electric
industry are providing solutions based on CIM or at least adapting their existing platform with
CIM connectors.
• No specific numeric values could be obtained from the benchmarking about scalability and
latency, but requirements for some useful parameters have been provided for Quality of Service
(QoS).
• Concerning services and applications:
o The modularity provided but SCADA/DSM-like suites allows DSO to eventually manage
all tasks from a unique interface, providing a very wide range of applications
o The focus on interoperability and system operators’ interactions, seems to be a
relevant service that could be provided by INTERPRETER
www.interpreter.eu
D2.3
o With respect to this benchmark, only the “DSO/TSO coordination service” has no
correspondence with analysed platforms and thus will most likely fill an existing gap
o CIM appears to be the most adopted solution for control centres interoperability with
perspective to even more widespread adoption
o The services included in INTERPRETER portfolio are more oriented to network control
and optimization rather than asset management; this could be a gap when considering
new market options (demand response, ancillaries, EV management, local energy
market, etc.)
o Data-driven platforms for novel energy market options are also available open-source;
4 out of 12 analysed platforms are basically open source. This is an evidence that could
convey interesting considerations about energy decentralization and deregulation.
Finally, a brief comparison between TSO and DSO platforms has been reported in chapter 5, from which
it is possible to extract the following considerations:
• At the moment, interaction of TSOs and DSOs with other operators are limited or missing
• Apart from system security and safety, cooperation between TSO and DSO are foreseen for
active and reactive ancillary services, as well as flexibility
• All DSOs are equipped with SCADA but only 60% of them have implemented DSM applications
• Other differences between TSOs and DSOs regard the state estimation analysis (not popular in
distribution environment) and the monitorization and the tap-control of LV/MV transformers
(only available on the 10% approximately of the transformers)
• DSOs are expected to incorporate market-oriented tools in their platforms, due to their new
role in a full deregulated market scenario.
www.interpreter.eu
D2.3
7. REFERENCES
[1]. B. Seal, R. Uluski; “Integrating Smart Distributed Energy Resources with Distribution
Management Systems” Report EPRI, September 2012, available at
https://pdfs.semanticscholar.org/0c56/beabe0d8be31adaa500a4dec5ea3ba76ed50.pdf,
[2]. Communication from the commission to the European Parliament, the council, the European
economic and social committee, the committee of the regions and the European investment
bank “A Framework Strategy for a Resilient Energy Union with a Forward-Looking Climate Change
Policy”, /* COM/2015/080 final */, 2015, available at https://eur-lex.europa.eu/legal-
content/EN/TXT/?uri=COM:2015:80:FIN;
[3]. T. Lefevbre, H. Englert, “Power system management and associated information exchange”, IEC-
TC57, poster, available at https://www.iec.ch/resources/tcdash/Poster_IEC_TC57.pdf, accessed
03 Feb.2020;
[4]. Eurelectric, EDSO, “DSO priorities for smart grid standardisation”, position paper, available at:
https://www.edsoforsmartgrids.eu/wp-content/uploads/public/DSO-Priorities-Smart-Gird-
Standardisation.pdf, accessed 27 Jan. 2020.
[5]. Prettico, G., Flammini, M. G., Andreadou, N., Vitiello, S., Fulli, G., Masera, M., “Distribution
System Operators observatory 2018 - Overview of the electricity distribution system in Europe”,
EUR 29615 EN, Publications Office of the European Union, Luxembourg, 2019, ISBN 978-92-79-
98738-0, doi:10.2760/104777, JRC113926.
[6]. EURELECTRIC “The power sector goes digital - Next generation data management for energy
consumers”, Eurelectric report, May 2016, available at
https://www3.eurelectric.org/media/278067/joint_retail_dso_data_report_final_11may_as-
2016-030-0258-01-e.pdf, accessed 23 Jan. 2020.
[7]. Catapult.org.uk, “An Introduction to Interoperability in the Energy Sector”, Published: 12
December 2018, website available at https://es.catapult.org.uk/news/an-introduction-to-
interoperability-in-the-energy-sector/, accessed on 30 Jan. 2020
[8]. Smart Grids Task Force, “Terms of Reference for Working Group on Electricity and Gas Data
Format and Procedures”, available at
https://ec.europa.eu/energy/sites/ener/files/documents/tor_eg1_wg_on_data_format_procedur
es.pdf, accessed 03 Feb. 2020
[9]. IEA, "Digitalisation and Energy", IEA, Paris (2017), available at
https://www.iea.org/reports/digitalisation-and-energy, accessed 20 Jan. 2020.
[10]. Y. Agalgaonkar K. Schneider C. Marinovici R. Melton S. Vadari, “ADMS State of the Industry and
Gap Analysis”, U.S. Department of Energy, Public Report, March 2016,
[11]. AVAZOV, Artur R.; SOBINOVA, Liubov A. “Advanced Distribution Management System.” In: EPJ
Web of Conferences. EDP Sciences, 2016. p. 01004.
[12]. G. Kumar and N. M. Pindoriya, "Outage management system for power distribution network,"
2014 International Conference on Smart Electric Grid (ISEG), Guntur, 2014, pp. 1-8. doi:
10.1109/ISEG.2014.70055981
[13]. https://en.wikipedia.org/wiki/Outage_management_system, website accessed on 28 Jan. 2020
[14]. Smart Grid Coordination Group. Smart Grid Reference Architecture; Technical Report; CEN-
CENELEC-ETSI: Brussels, Belgium, 2012.
[15]. Techopedia, Communication protocol,
https://www.techopedia.com/definition/25705/communication-protocol, website accessed on
28 Jan. 2020
www.interpreter.eu
D2.3
[16]. Wikipedia, Application Programming Interface,
https://en.wikipedia.org/wiki/Application_programming_interface, website accessed on 28 Jan.
2020
[17]. ETSI GS CIM 009 V1.1.1 "Context Information Management (CIM); NGSI-LD API", 2019, available
at ttps://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_CIM009v010101p.pdf,
accessed 10/02/2020;
[18]. IEC - TC57, "IEC 61970-301:2016 Energy management system application program interface
(EMS-API) - Part 301: Common information model (CIM) base", international standard, 2016,
[19]. Open ADR alliance, “OpenADR 2.0 Specifications”,
https://openadr.memberclicks.net/specification web site accessed on 28 Jan. 2020
[20]. Energy@Home, Energy@home Technical Specification, 2015, http://www.energy-
home.it/Documents/Technical%20Specifications/E@h_Specification_2.1.pdf website accessed on
28 Jan.
[21]. ETSI M2M architecture, “Smart Appliances REFerence (SAREF) ontology”,
https://sites.google.com/site/smartappliancesproject/ontologies website accesed on 28 Jan 2020
[22]. Bondi, André B. “Characteristics of scalability and their impact on performance.” Proceedings of
the second international workshop on Software and performance, 2000. – WOSP '00. p. 195.
doi:10.1145/350391.350432. ISBN 158113195X
[23]. https://www.hadoop360.datasciencecentral.com/blog , website accessed on 27 January 2020;
[24]. https://www.sogno-energy.eu/Media/Deliverables website accessed on Jan. 2020;
[25]. https://openems.io/ website accessed on Jan. 2020;
[26]. https://volttron.org/ website accessed on Jan. 2020;
[27]. https://www.se.com/es/es/work/campaign/innovation/platform.jsp website accessed on Jan.
2020;
[28]. http://booklet.atosresearch.eu/node/2093 accessed on January 2020;
[29]. https://www.openenergi.com/ website accessed on January 2020;
[30]. https://docs.oracle.com/en/industries/utilities/opower-platform/ website accessed on January
2020;
[31]. https://library.e.abb.com/public/d812ff32efa92201852575fa00562955/BR_SCADA_DMS.pdf
website accessed on January 2020;
[32]. https://www.survalent.com/adms-platform-overview/ website accessed on January 2020;
[33]. https://www.researchgate.net/publication/315924725_Monet_An_Innovative_System_to_Mana
ge_Energy_Services website accessed on January 2020;
[34]. https://www.slideshare.net/Sam_Francis/monet-an-iot-energy-management-platform-based-on-
mongodb website accessed on January 2020;
[35]. https://www.ge.com/digital/sites/default/files/download_assets/brochure_reliability%20respons
e_PowerOnAdvantage-web.V1.pdf , website accessed 13 Feb. 2020;
[36]. https://www.downloads.siemens.com/download-center/download?DLA02_7456 , website
accessed 12 Feb. 2020;
[37]. T. Predojev, A. Al-Hezmi, J. Alonso-Zarate and M. Dohler, "A real-time middleware platform for
the smart grid," 2014 IEEE Online Conference on Green Communications (OnlineGreenComm),
Tucson, AZ, 2014, pp. 1-6., doi: 10.1109/OnlineGreenCom.2014.7114440Directorate General for
Energy – European Commission, “Clean Energy for all Europeans”, Report, May 2019, doi:
10.2833/9937
[38]. IRENA, Innovation landscape brief: “Future role of distribution system operators”, 2019,
International Renewable Energy Agency, Abu Dhabi, ISBN 978-92-9260-115-7
[39]. TSO-DSO report: An Integrated Approach to Active System Management. 2019
www.interpreter.eu
D2.3
[40]. Mauri, G., Pilo F., Taylor J., Bruno G., Kampf E. “Control and automation systems for electricity
distribution networks of the future”,2017, In Cigre WG C6.25/B5.
[41]. Rezkalla, M., Heussen, K., Marinelli, M., Hu, J., & Bindner, H. W. “Identification of requirements
for distribution management systems in the smart grid context.” Proceedings of the Universities
Power Engineering Conference, November 2015.
[42]. E. Vaahedi, “Practical Power System Operation”, 1st ed. John Wiley & Sons, 2014.
[43]. A. M. Prostejovsky, C. Brosinsky, K. Heussen, D. Westermann, J. Kreusel, M. Marinelli, “The future
role of human operators in highly automated electric power systems”, Electric Power Systems
Research, Volume 175, 2019, 105883
[44]. F. Pilo, G. Mauri, B. Bak-Jensen, E. Kämpf, J. Taylor and F. Silvestro, "Control and automation
functions at the TSO and DSO interface – impact on network planning," in CIRED - Open Access
Proceedings Journal, vol. 2017, no. 1, pp. 2188-2191, 10 2017.
www.interpreter.eu

Benchmark Analysis Ems DMS

Uploaded by

Copyright:

Available Formats

Benchmark Analysis Ems DMS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Benchmark Analysis Ems DMS

Uploaded by

Copyright:

Available Formats

www.interpreter.

Funded by the Horizon 2020

DELIVERABLE 2.3 – VERSION 1

Abbreviation Full name

FIGURE 1: IEC TC 57 REFERENCE ARCHITECTURE.

2.1. TOPICS OF INTEREST

Communication and Connectivity:

Data Analysis and Management:

2.2. CATEGORIES OF PLATFORMS TO CONSIDER

2.2.1. DMS – DISTRIBUTION MANAGEMENT SYSTEM

FIGURE 2: COMMON ARCHITECTURE DIAGRAM OF A DSM.

2.2.2. OMS – OUTAGE MANAGEMENT SYSTEM

A typical OMS architecture is depicted in Figure 3 [10]:

FIGURE 3: COMMON OMS ARCHITECTURE [10].

2.2.3. EMS – ENERGY MANAGEMENT SYSTEM

2.2.4. AMI – ADVANCED METERING INFRASTRUCTURE

2.2.5. ADMS – ADVANCED DISTRIBUTION MANAGEMENT SYSTEM

FIGURE 4: EXAMPLE OF ARCHITECTURAL SCHEME FOR ADMS [10].

2.2.6. DATA-DRIVEN PLATFORMS FOR NEW MARKET SERVICES

FIGURE 5: SMART GRID REFERENCE ARCHITECTURE [14].

SGAM Model Energy platform feature Definition

3.1. BUSINESS LAYER

3.2. FUNCTION LAYER

3.2.2. APPLICATIONS FOR AN EFFECTIVE GRID PLANNING

APIs for integration

3.4. INFORMATION LAYER

3.5. COMPONENT LAYER

• Customization • Applications • Communication • Data Model / • Scalability;

Features for Benchmark

FIGURE 6: STRATEGY FOR BENCHAMRK ANALYSIS OF ENERGY PLATFORMS.

4.1. COMPARISON OF AVAILABLE SOLUTIONS

TABLE 3: DATA FOR PLATFORMS BENCHMARKING (PART A)

TABLE 4: DATA FOR PLATFORMS BENCHMARKING (PART B).

TABLE 5: QOS REQUIREMENTS FOR SMART GRID APPLICATIONS [37].

4.2. ADOPTION OF SERVICES AND APPLICATIONS

TABLE 6: MAPPING OF INTERPRETER APPLICATIONS VS. BENCHMARKED PLATFORMS.

5.2. MARKET FUNCTIONS

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.