A cloud-based service-oriented architecture to unlock smart energy services

Abstract

In a modern smart energy system with increased penetration of renewable energy resources, the amount of data from various sources is growing significantly. Such systems require complex algorithms and controlling on-demand. These requirements can be addressed with on-demand scalability and a stable system. Nowadays, on-demand scalability is achieved by considering cloud computing and Internet of Things (IoT) technologies. This paper presents a cloud-based platform based on service-oriented architecture to perform analyzes on smart energy system services. It is the result of the European FISMEP (FIWARE for Smart Energy Platform) project to demonstrate an information and communication technology (ICT) architecture for the smart energy sector. The presented architecture is powered by FIWARE, open-source and customizable building blocks for future internet applications and services. Furthermore, the feasibility of the architecture is evaluated using various test cases.

Introduction

The energy fraction used for heating, ventilation, air conditioning and refrigeration (HVACR) accounts for about two-thirds of the total energy consumption of buildings. Monitoring and optimizing the operation of building energy systems (BES) holds great potential for energy savings and can be even more effective at lower costs as passive approaches lowering the energy consumption, e.g. retrofitting of the building envelope. However, the integration of volatile energy, decentralized energy sources and the effort to build integrated smart energy systems, wherein building hold great potential for flexibility, increases the complexity of future BES and the required ICT. Buildings and their BES are usually planned highly individually, with many distributed sensors and actuators.

On the other hand, electric power systems are experiencing a radical transformation towards the full implementation of the so-called smart grids, offering valuable opportunities for the increase of reliability and efficiency. The transition towards emerging active distribution networks is in the first line of interaction between the power sector and the 21st-century end-users: in fact, the energy distribution infrastructure is penetrated by distributed generation, mobility of prosumer nodes and changed the paradigm of energy markets. The operation of electric power systems undergoes dramatic changes in the era of smart grid deployment, due to increased energy harvesting from local resources, accommodating a larger share of unpredictable and stochastic electricity transfer, to an ever-increased share of power electronics mediated energy transfer, but also thanks to advancements in instrumentation.

Moreover, the newly designed control algorithms rely on information delivered mainly by distributed, synchronized measurement (SM) systems, and made available in data streams with different reporting rates. Applications such as wide-area monitoring and control (WAMC) and hybrid state estimation (Asprou et al. 2012; Asprou et al. 2016), need aggregation of data received with high reporting rate from smart meters having lower reporting rate, and an innovative ICT platform to integrate multiple acquisition systems is expected to cover and correlate such information. Simultaneously monitoring of the electric quantities at High Voltage (HV), Medium Voltage (MV) and Low Voltage (LV) levels of the grid, using a dedicated platform and Phasor Measurement Units (PMUs) is the desired solution. In this way, a lot of information will be getting, extremely useful in power system analysis.

Furthermore, the continuous decrease of available mechanical inertia in the evolving power systems requires new control algorithms, faster control loops and accordingly a measurement layer with higher dynamic performances. Hence suitable automation systems need to be designed, to satisfy the specific grid requirements.

Therefore, smart energy system services seem to be an ideal application for the concept of IoT. Nevertheless, to the best of our knowledge, there are only a few commercial solutions for integrating smart energy services such as building energy management systems (BEMS), automation and control in a smart grid with an IoT infrastructure. To achieve this goal, FISMEP leverage activities performed at European and local level in the last few years.

Start of art

Based on the existing European road-maps and implementation plans concerning smart energy system, there is a need to support the modernization of the electricity grids in Europe for the increased flexibility of the European power system, an efficiency increased transfer capacity and active participation of new market actors including end-users.

The open-source ICT infrastructure principle are supposed to facilitate a connection with external actors such as producers, distributors, and consumers. Therefore, innovative energy services and business ideas can quickly be integrated into the platform for deployment.

At the moment a lot of effort has been performed by the smart grids professional community in developing specific solutions or protocols for communication, while little work has been placed in developing an overarching integration platform where services can be deployed. This is the main differentiator that FISMEP is tired to achieve.

FISMEP targets the need to unlock smart grid technologies and services through a standardized service platform that can support interoperability. The FISMEP approach is based on a customizable open-source IoT platform setup using FIWARE (FIWARE-NGSI v2 Specification), to facilitate an efficient, automated and sustainable energy supply for single buildings as well as municipalities. The goal is to enrich the set of use-cases in the platform that addresses customer involvement and distributed grid operation. FISMEP has the ambition to become the reference architecture for smart energy services giving European companies a competitive advantage in terms of rapid development of innovative Smart Grid solutions.

Objectives

The key objectives of the project are:

• Demonstrate open-source software platform for smart energy systems that can be adopted by different actors such as Transmission System Operators (TSOs), Distribution System Operators (DSOs), equipment providers, energy retailers, service providers, ICT companies, etc.

• Enabling an increased flexibility of power system to cope with growing share of intermittent, variables and decentralized renewable generation and managing the complex interactions.

• Dynamic management of production and network capacity by supporting increased generation and transmission resulting from renewables and internal energy markets. One of the field tests is able to address this challenge thanks to innovative solutions based on advanced sensors, such as PMUs.

• Provide information, services, and market architectures to support open markets for energy products and services, whilst facilitating the active participation of customers.

• Target future smart districts and cites by adopting energy efficiency, performance and user-centered approaches.

• Focus on customer’s involvement via direct feedback strategies and user-centered adaptation.

FISMEP is about service implementation. The energy sector needs to focus on developing these service ideas without significant hurdles in the ICT sector.

Approach

FISMEP is a highly interdisciplinary project that involves advanced solutions in the area of energy, ICT and behavioural science. Concerning the energy scenario, FISMEP focuses on:

• Advanced monitoring solution applying for the last advances in the area of distribution grid monitoring based on PMU technology. PMUs are widely used in transmission systems but a recent trend is showing a new role for this technology in support of distribution level state estimation. This is a new area developed in support of the concept of an Active Distribution Network driven by the penetration of renewable energy sources.

• Advanced automation solution for multi-terminal Medium Voltage Direct Current (MVDC) grids. Direct Current (DC) technology is seen as a key enabler in enhancing network capacity.

Concerning the ICT scenario, FISMEP builds on the scientific result of the Future Internet Public-Private Partnership (FI-PPP) that developed the most advanced use of internet technology in terms of:

• Cloud-based platform, performing virtualization in support of scalability in terms of geography and size.

• Service-oriented architecture to support extensible Application Programming Interface (API) among various actors.

• 3-layer platform model (integration of various data sources, middleware and API layer) to allow small and medium enterprise provider of services access to multiple data sources.

Concerning the behavioural science aspects, the user-centred approach developed:

• to study insight and appliance on the artefact landscape affecting the user level energy consumption behaviour.

• to monitor existing infrastructure on single household

• to design and implement a user-centered feedback system as well as analysis on general data and user experience.

One of the key outcomes in this project for providing an open-source architecture is the development of a customizable and flexible ICT architecture for a future smart energy system which is serving different the electricity network as well as BEMS to provide an integrated infrastructure for smart sector coupling, where a wide range of renewables are being used and formed a large distributed smart energy network.

In this context, a standardized software platform is the key enabler of interoperability and the main vehicle for the rapid implementation of innovative energy services. The goal is to transform the energy services through a service-oriented architecture (Haghgoo et al. 2020) and link the services into the broader concepts of the smart city district.

This dimension is given by the compatibility with FIWARE components and using cloud computing which forms the IoT. The FIWARE IoT platform is founded by European Union and the European Commission. It is enriched by OpenStack-based cloud, where its catalogue is hosted. The FIWARE Catalogue contains Generic Enablers (GEs), representing a rich library of components.

In regards to the FISMEP platform, FIWARE GEs covers the main part of the proposed ICT architecture and supports plug and play connection of data, devices and services to enable interoperability.

Platform requirement specifications

To prevent ICT complexities while developing smart energy services, the basic functionalities must be provided directly from the platform, giving more power to the developer of smart energy system services. Combining all these aspects, this paper introduces an ICT platform architecture and describes how a third party such as service provider can use this architecture. Furthermore, the associated third party can then deploy several applications and services such as grid controlling and monitoring, energy management with more user involvements, etc.

This open-source platform allows developers to make more informed decisions, enforce energy policies, and have a smarter solution for the smart energy domain. In this regard, the functional and non-functional requirements for these applications and services need to be analysed and addressed in the system architecture (Rohjans et al. 2012). These requirements are as follows.

Functional requirements

Security and resilience as a requirement need to be met in the critical infrastructure (Neureiter et al. 2016) since the smart energy system is subjected to cyber-attacks as well as other challenges including natural disasters and component failures. Secure key infrastructure for authentication, confidentiality and integrity should be deployed. Therefore, resilience needs to be natively designed in the ICT architecture.

Furthermore, The architecture must provide numerous open-source interfaces that mediate between different services to address openness and extensibility. Accordingly, the inter-connectivity of the architecture be ensured.

Scalability is necessary for a sense that numerous services are actively supported in the future smart energy ecosystem. The modular structure of the architecture with open-source interfaces allows this. Size scalability is realized with load balancers and Virtualized Network Functions (VNF). Geographic scalability is possible because every medium and low-voltage grid has its controllers and network functions.

Non-functional requirements

Communication between the components can be considered as a first non-functional factor. There exist several ways to establish communication like cellular networks, powerline, Ethernet, or fibre. The communication network needs to fulfil the minimal latencies conditions in transforming the set points. The setpoints of inertial response and primary frequency response are required to be sent every 2 minutes.

The other non-functional item is frequent the response time. To apply grid and building monitoring algorithms, the value of inertial response and frequency response has to be recorded twice per second; time to apply grid automation algorithms like service restorations and controlling every ten seconds; and for reactive power system every two minutes.

Data storage as other non-functional is considered to store the monitored data for further analysis. The high frequency of stream data results in a huge amount of data that must be sent and stored. To make it more efficient, buffering data in some levels is used and then data can be sent for monitoring at HV, MV and LV levels of the grid.

Other non-functional requirements are hardware requirements that can be a list of devices in the edge such as central controller, converters, as well as cloud servers.

ICT platform architecture

To meet the requirements as listed in the previous section, a suitable ICT architecture has been designed as illustrated in Fig. 1. This architecture is capable of monitoring the data from PMUs, building sensors, and Intelligent Electrical Devices (IED). Moreover, it runs a grid protection algorithm when anomalies and fault happen in the system. The architecture provides secure and resilient data processing (data communication, data storage, and privacy), and affordable solutions.

Fig. 1

ICT architecture for an integrated, scalable and flexible solution for future smart energy systems

The proposed architecture demonstrates an easy (yet efficient) way to incorporate and utilize energy-related services in smart energy IoT networks. This ICT architecture presents the designed capabilities using cloud-based virtualization aspects that help to develop programmable and re-usable functions and provide services based on the gathered data. To manage the physical infrastructure, developed services send command and functionalities to the hardware infrastructure using the API. The various components of this architecture are explained as follows.

Hardware infrastructure

This component comprises all the hardware devices ranging from building energy management devices like Thermal sensors, actuators etc. to the grid’s transmission and distribution infrastructure consisting of transmission lines and hybrid grids.

Present capabilities

The present capabilities involve automation and control of power distribution grids, building monitoring and energy management, etc. to carry out the various tasks in the smart energy system. All of these capabilities are achieved by using the open API that acts as an interface between the services, applications and hardware.

FIWARE GEs

From the FIWARE catalogue, some general GEs are selected to initiate a customizable part of the platform which is described in more details on Haghgoo et al. (2020). To interface hardware infrastructure, IoT Agents employed. It is an intermediate component between hardware infrastructure and Context Broker. Data management and the process is done by Orion Context Broker (CB). It uses MongoDB as data storage. CrateDB and Quantum Leap provided the capability to store and analyse historical data.

Project partners

The FISMEP project leverages activities performed at the European and local level. It has received funding in the framework of the joint programming initiative ERA-Net Smart Grids Plus, with support from the European Union’s Horizon 2020 research and innovation program. FISMEP is a 36-month project that started on 1st May 2017 and ended 30th Nov 2020, with a budget of 2872 M€.

According to Table 1, in FISMEP, a total of seven research and industrial partners from Germany, Sweden and Romania are jointly worked on a smart energy solution that provided new capabilities in the area of distribution grid management. In addition to a modern energy system, which is oriented towards the vision of a smart city. The FISMEP project is made up of seven partners:

Table 1 Project partners

From Sweden, we exploit the experience built both in the city of Malmö in developing a completely new and innovative Smart City District and in the city of Gothenburg in co-creatively using and researching a habitation living lab named HSB Living Lab as part of both flagships the Building Technology Accelerator (BTA) and the Smart Sustainable Districts (SSD), both under the leadership of the Climate-KIC to gain expert advice in up-scaling and replicating implemented smart solution.

From Romania, we exploit the long-term collaboration of UPB-Electrica S.A in the field of distributed energy resources equipment and system, including sensing, synchronised measurements and smart metering, since UPB has been a member of the SmartRegions IEE project 2011-2013. UPB also brings know-how in instrumentation for building automation from the Emerging technology for power supply of high-tech buildings (EHNIT) project.

From Germany, we exploit the work performed in the context of the research campus FEN where an innovative concept of energy management in DC is under development. FISMEP plan to plug in this development and making sure that future power systems and advanced ICT solutions stay aligned.

Results and impact

This section presents the implementation of the introduced architecture in a different field test in three European countries Sweden, Romania, Germany. The German field test (FT1) focused on automation for distribution grids at medium voltage level. In the Swedish field test (FT2), a sustainable living environment, energy management services are applied to real residential buildings down to the end-user level, including their energy behaviour. The Romanian field test (FT3) realizes monitoring of distribution grid at different voltage levels using data from PMUs. The complete process of applying the proposed architecture is briefly described in the following.

Field test 1: automation of electrical distribution networks

The German field tests of the FISMEP project implements the described platform to enhance the automation of electrical grids. In particular, two different use cases were performed: the automation of the MVDC network and the protection algorithm so-called Service Restoration (SR) for distribution grids. In case of fault on the electrical grid, the protection system opens the circuit breakers upstream and downstream the fault location. To find how and which normally open switch has to be closed in order to restore the power, different techniques and approaches have been developed by researchers. this algorithm called SR.

Among the new technologies of the smart grids, important achievements are being reached by implementing the DC for distribution systems at MV level, following the experience with HV in transmission grids. The pilot site for the MVDC network automation is situated on RWTH-Aachen University Campus in Germany: 5 km cables connect three different locations that host high-power DC/DC and DC/AC converters to form hybrid AC/DC grid structures. Voltage and current measurements from the DC grid are collected by instrument transformers that are located at grid connection points and in the high-power converters. These measurements, used for the monitoring of the grid operations, are virtualized in the FISMEP platform by using the Message Queuing Telemetry Transport (MQTT) communication protocol. The FIWARE components accomplish the acquisition of measurements according to the specific communication protocol for power systems, via one of its IoT Agents, and the time-series database CrateDB. The Orion Context Broker manages the data flow and issues notifications in case of unacceptable condition of the DC grid.

To integrate the control of distribution grids besides their monitoring, the SR algorithm was implemented as a middleware component in the cloud-based FISMEP platform and tested in the laboratory of RWTH-Aachen University. The occurrence of faults in distribution grids causes electricity interruption to the customers and, consequently, several economic impacts to the grid operators (Warren 2003). In the automated electrical grids, once the fault is isolated by the nearest switching devices, the SR operates the reconfiguration of the network to re-energize the disconnected customers. The developed SR middleware is a rule-based algorithm that is specifically suited for cascade or multiple faults, as in the High Impact Low Probability (HILP) events (Dognini et al. 2020). Firstly, the disconnected customers are identified and, among them, the one with the highest priority (e.g. hospital, transportation, communication or gas network site) is chosen as a target for the restoration. Successively, the SR algorithm determines the most suitable primary substation to re-energize the target node through an alternative feeder, by closing the normally open tie switch. Each network topology, obtained by closing the bus-tie unit for each substation in the network that can reconnect the target node, is considered as a candidate solution and evaluated with a state estimation approach (Abur and Exposito 2004; Stengel 2012). Once the technical constraints (voltage, thermal and network radiality) are verified, the SR algorithm determines the most optimal solution by implementing a Multiple-Criteria Decision Analysis (MCDA) approach, which considers as objectives the minimization of power losses and/or the utilization of electrical lines. The SR component, as middleware, has a standard interface for the data exchange and is independent of the specific distribution grid to be managed. In the FISMEP platform, the real-time network data for the execution of SR (status of the switches, measurements of power injections, voltages or currents) are retrieved from the CB, which also issues the computed closing commands to be operated by the tie-switches. The occurrence of a fault, with the consequent tripping of the nearest circuit breakers, is detected by the CB, which initiates the SR; the process iteratively continues until all the de-energized loads are reconnected or the grid constraints are violated.

Assessment of field test 1

The automation of the MVDC network has been accomplished by virtualizing the electrical measurements in the FISMEP platform and deploying the monitoring functionalities with the FIWARE components. The picture in Fig. 2 shows the transducers installed in the MV switchgear, which measure line current and the two-poles voltage, and the IED, which maps the measurements according to the data model of the power systems protocol (as the IEC 61850 standard) and interface the FISMEP platform. The same Fig. 2 shows the plots of the measurements from the platform database, using the web application Grafana (?grafana); in particular, the step reduction and increase of transmitted power are recorded and represented. The Orion Context Broker is configured so that an event is notified, in case of correspondence of the acquired value to a specific entity: in our implementation, the violation of electrical constraints (e.g. voltage and thermal limits) issues alarms and corrective actions.

Fig. 2

Picture of the MVDC switchgear (left) and plots of voltage and current measurements (right)

The assessment of the SR use case deploys the power grid emulation via the Real-Time Digital Simulator (RTDS). The distribution network model for the test is shown in Fig. 3: it includes four primary substations, at 13.8 kV, and hosts two Distributed Generations (DGs) in addition to passive loads (Dognini et al. 2020). Black and white squares indicate the normally closed and normally open switches, respectively.

Fig. 3

Model of distribution grid for the service restoration

Through the Gigabit Transceiver Network (GTNET) card of RTDS, the real-time grid data are provided to the CB in the FISMEP platform. The occurrence of the fault is emulated with MV industrial protection relays that are connected with RTDS via IEC 61850-GOOSE communication protocol: injection of over current in the relay terminals causes the tripping of the emulated circuit breaker, in RTDS, and the initiation of SR. The service restoration platform is evaluated according to the communication network latency and the processing time of the SR algorithm. Concerning smart grids that deploy advanced distribution automation, the proposed implementation confirms its suitability.

Field test 2: building energy management systems and user-involvement

The aim of the second field test in the context of the FISMEP project is to examine the application of FIWARE as an open-source platform for the smart building domain and evaluate its value for rapid implementation of innovative energy services, including an IoT solution (CESO by E.ON), new-built apps (ERO and MKB diary by Chalmers), as well as other building automation services (BAS) by RWTH. For this purpose, the platform was set up and evaluated for the integration of both non-residential buildings and residential buildings down to individual housing units.

Integration of residential building and user involvement

The Swedish partners, supported by the German partners, carried out three different field tests, of which one located in Gothenburg and two in Malmö, aiming to implement the technical integration of new tools and services on small-, medium- and large-scale residential buildings.

The CESO platform was successfully connected to FIWARE through a cloud-to-cloud integration. The platform receives data, and from a user interface it is possible to control the heat to the buildings. Power control of the buildings is used during production with satisfactory results: The thermal inertia is used in such a way that the control does not affect the indoor temperature more than 0.5^∘C. This means that peak loads can be reduced, and the district heating network can be balanced without affecting the perceived indoor comfort of end customers.

Additionally, a new user-centred approach was demonstrated, concerning the effects of energy conservation, peak shaving and temperature shifts on an end-user level. To achieve consumer engagement, motivation, behaviour change and acceptance, higher granulation is required from the property level down to the end-user in the individual households in a property. Chalmers has therefore developed two smartphone applications for the smart energy system, aiming at the end-user. The tools have been technically implemented in the demonstrators in Sweden. The first, the ERO Energy Organizer application Fig. 4, includes electricity, heating and also the water consumption in the home. It applies a feedback strategy so that the end-user can choose a personal threshold for individual energy consumption to influence the potential impact of its energy consumption behaviour on the energy system. Data on users’ consumption behaviour for planned energy consumption activities and habits can thus be mapped and analyzed for more demand-oriented delivery.

Fig. 4

ERO energy organizer application

The other smartphone application is the MKB Thermal Comfort Diary application Fig. 5, which includes the perceived comfort from the user perspective related to indoor temperature conditions at home in general but also especially during power control from the heating plants.

Fig. 5

MKB thermal comfort dairy application

A feedback strategy includes making daily diary entries about their indoor temperature experiences and the perceived control of the indoor climate and thus is raising awareness. This will help us better understand the future demand for renewable energy by knowing how end-users perceive their indoor temperature conditions at home and their own ability to control it, and to understand in which way they feel affected by the heat control.

Energy monitoring in non-residential buildings

Two minimal requirements for a smart energy platform for building operation are the ability for collecting operation data from an existing building energy management system (BEMS), also known as monitoring, and to send control actions from the platform to an actuator within a building energy system. To examine these two basic prerequisites for a functioning communication between platform and BEMS, the three different field tests in residential buildings of very different kind and sizes in Sweden were complemented by one field test in a large office building located in Aachen, Germany.

The BES for the demonstration building is equipped with a hybrid energy system comprising a combined heat and power (CHP) system, two condensing boilers and a heat pump (HP). The automation and field layer use the Building Automation and Control Networks (BACnet) as the primary communication protocol. Generally, this building automation network delivers about 12 700 data objects provided by hundreds of sensors and actuators. Having full access to the BAS, we integrate a gateway into the network, running an extended version of the open-source framework OpenMUC (FI for Solar Energy Systems ISE) as middleware software. To enable the communication between BAS and gateway we deploy an existing OpenMUC-driver for BACnet that based on BACnet4J (BACnet4J) and apply minor modifications to improve the compatibility with different device vendors as well as the performance on a larger network. It enables the gateway to perform automatic device discovery and data collection from the BAS. After parsing the collected data objects to the IoT-JSON protocol defined by the FIWARE association, we automatically register the data objects as IoT devices in the platform via HTTP and then send the measurements via TLS-encrypted MQTT, where it can be persistently stored in the CrateDB and used by other third-party web-services. The Orion Context Broker offers the functionality for event-triggered notifications via HTTP which enables the implementation of an alarming system for monitoring critical measurements and sending alarms via SMS, E-Mail or other messenger systems. To examine the functionality for sending and receiving commands from a BAS without compromising the existing automation logic of the demonstration building, a closed-loop control in a software-in-the-loop setup was implemented. Implementing a simple PID controller in Python and connecting it to the platform we realise the control of a virtual room. For the latter, we use a functional mock-up (FMU), a thermal zone model from the open-source Modelica library AixLib (Müller et al. 2016) and again establish the data exchange with the platform via MQTT, registering the zone temperature sensor and an ideal zone heater as virtual devices. Starting the simulation, the FMU receives commands from the PID-Controller and conducts a fixed simulation time step. The sample-based controller connects to Orion via its RestAPI, where it retrieves virtual sensor measurements generated by the FMU and returns its calculated control signal to the simulated heater. By decreasing the sample rate of controller actions, we can send several commands per seconds before we experience latency effects, which mainly occur due to the computational time required for the room simulation. Nevertheless, concerning the thermal inertia of real BES, we are confident that the platform is capable of reliably transmitting control signals to a BAS within required time constraints.

Assessment of field test 2

We can conclude that FIWARE offers minimal functionalities for building energy monitoring in non-residential buildings and building control, at least when full access to the BEMS is granted. When testing the implementation and technical integration of new end-user-centred tools in FIWARE, such as ERO app that is shown in Fig 6, we revealed a couple of relevant limitations:

• The reference data model for buildings proposed by FIWARE has a relatively coarse granulation, i.e. the typical use cases for FIWARE are entities on a larger scale – as larger commercial buildings – than the scale required by residential buildings. In ERO scenarios, information about e.g. floors, areas, apartments, rooms, all the way down to appliances level is addressed. Since the smallest unit in FIWARE’s reference data model is a building, this was a huge gap and not obvious how to bridge it.

  Fig. 6

  

  Systems plan and technical overview developed for the field trial user tests in Sweden

• Security measures according to GDPR are lacking in FIWARE, as the use of controlling units in an individual household addresses privacy issues, which could not be envisioned when FIWARE was developed. User-centric applications require a fine-grained security layer with authentication, authorization, password management, session management, all of which FIWARE currently does only offer with limitations.

• Furthermore, a documented option for coupling FIWARE to existing well-established open-source identity- and access management tools as e.g. Keycloak is currently missing. Due to the prevailing uncertainty regarding security management in FIWARE at present, the device database and security in the ERO app were transferred to Tempiro API in the end.

• FIWARE is very useful for gathering data, but not (yet) designed to control smaller appliances in real-time, which is the use case that the ERO app demands.

Our indicative conclusions, however, are positive after all: Through a single installation of FIWARE, many different use cases can be linked together; since FIWARE enables the simultaneous collection of data from different sources, it can separate many information streams. Despite the hurdles we experienced, our results show clear advantages of such a standardized platform. The fact that the FIWARE GE are provided as dockerized micro-services makes the platform portable between underlying infrastructures, and horizontal scalability is given by running the replicates of the individual components. However, this set up requires deep expert knowledge in docker and clustered database handling to obtain the desired performance. At present, the most suitable applications are use-cases for enabling energy efficiency through connected services on the building level, e.g. via centralized load-shifting or building operation control through BEMS. But when it comes down to behavioural level, through engaging end-users, there are still some barriers to overcome for a smart energy future of both commercials as well as residential buildings.

For future work, if GDPR-safety features can be integrated and granulation can be improved, we see the potential for FIWARE to collect and control all energy-consuming activities, such as heating/electricity/water for an entire building, down to end-user level and including end-user engagement. However, at the current stage, the implemented concept of multi-tenancy requires further granulation. Additonally, the future involvement of smart ontologies as SAREF (ETSI TS 103 673 2020) or BRICK (Balaji et al. 2018; Balaji et al. 2016) may solve the current gap for more granular system structures. Ultimately this would mean that differences will become trivial across use-cases. Although not necessarily part of a reference architecture aiming to be a general framework for smart ecosystems, there is an urgent need to demonstrate the integration of more advanced and fine-grained ontologies in future work.

Field test 3: monitoring and control of electrical grid via PMUs

The focus of this use case is given by the hybrid solution that was adopted for the PMUs data integration, processing, and visualization. The grid monitoring using PMUs is a product referred to as a hybrid because the PMU data stream is integrated using openPDC (standard solution for PMU data aggregation) and elements of FIWARE CB technology. The logic and operation for FT3 can be analyzed in Fig. 7.

Fig. 7

Grid monitoring solution using PMUs data – interaction of components

The very high reporting rate synchronized measurements equipment (PMUs) were deployed in relevant points of the energy system in LV nodes, 20 kV and 110 kV lines, points where the generation shares an important part with intermittent, unpredictable renewable energy sources. Each PMU communicates with the servers (where openPDC are installed) using a special configuration with secured routers over 4G networks. Some details with field-installed PMUs can be observed in Fig. 8.

Fig. 8

PMUs installed in the Romanian grid to illustrate UC3

Sequentially, all the software products linked to FT3 will be presented in the following paragraphs.

First level. openPDC data aggregation

OpenPDC is the standard solution for PMU data integration and aggregation, validated by all the PMU providers. For this FT, to increase the flexibility of the platform, 2 openPDCs were installed on dedicated servers, each one in a different geographical position. The testing for hardware definition (definition of a new PMU, left side) and optimally data integration in the standard format (the data are integrated into openPDC, right side) is done using a dedicated openPDC software, as we can see in Fig. 9.

Fig. 9

Definition and testing of PMU integration in openPDC (definition of the PMU, right side, and visualization of data on the left side)

Second level. Selection and optimization of PMU data

The next step in the chain of PMU integration using FIWARE technology is the configuration of the variables that are sent to the visualization application (the last element in the chain of the solution proposed by FT3 of FISMEP). It should be noted that each PMU equipment saves in a different format (depending on the manufacturer) up to 50 variables that are aggregated in openPDC. Out of these, only 14 easily identifiable will be extracted from openPDC and sent to the final application (IoT agent 1). Within the solution proposed by FT3, at the same level with the data selection, the process of transferring the variables (IoT Agent 2) is configured in terms of destination of those data, namely the general MongoDB database and optimization of data transfer. For this level of integration, other tests are computed to successfully populate the general MongoDB database as for the number of data and the right format.

Third level. General MongoDB and Orion Context Broker

As mentioned before, all PMU data (coming from the s called “MongoDB General” as they are received from the field side (first level). When the data from all the equipment saved in this general database, it is time to transfer the data to the main element of this solution, to Orion Context Broker, the central element of any application based on Fiware technology. This stage (level of integration) is essential in the process of standardizing the acquisition of data from PMUs because the solution proposed involves the integration of several types of equipment with different construction characteristics (in terms of data integration), thus creating a high degree of flexibility in using the platform. The data received in MongoDB General have a unique identification element, so it is possible to interpret different data and integrate them into the associated standard CB format. The actions are carried out by a conversion algorithm (IoT Agent 3) and, at the same time, reducing the physical size of PMU data, by optimizing the format in which data are stored using time indices. The data integrated into Orion completes the process of acquisition and aggregation of information from all types of PMUs and all locations. The next and final step is data integration in the visualization application.

Fourth level. Data visualization

A user interface is dedicated to PMU data visualization as part of the API provided by the FISMEP UC3 solution. For interacting with the application (available at upbfismep.microderlab.pub.ro), on the right side will appear the menu (after pressing the magnifying button) in which the user is warned about the data that must be selected to view qualitatively the data from the PMU as shown in Fig. 10:

• Variable of interest to be displayed

  Fig. 10

  

  FISMEP UC3 application interface

• Location of a PMU

• Start date and time for the analysis

• End date and time for the analysis

Finally, by clicking on “Generate Graph”, the result will be displayed as in and the user can manipulate this graph in terms of zoom in, zoom out, hover over the graph indicating exactly the point on the graph etc. Another possibility in the interaction with the application is to visualize comparatively two variables associated with the same locations, or the same variable in different locations.

Assessment of field test 3

The main conclusion that can be drawn is the ability of the FIWARE technology to properly integrate PMU data, using a very high reporting rate (50 frames per second) and to optimize the process in terms of physical storage and interrogation. For a practical example, in terms of storage optimization, in 1 minute the openPDC will transfer 4.7 MB of data to MongoDB General but Orion will compress them to only 340 kB of physical memory. The FT3 FISMEP product operates in the context of big data analysis by integrating multiple PMUs from multiple openPDCs in different formats. The platform offers flexibility and versatility in defining and integrating new PMUs, a final unified way of storing the PMU data in Orion and big data visualization through the user interface. The next steps include optimization of Orion for working with even bigger data, new functionalities of the platform and interconnection of multiple “Mongo DB General” databases.

Results of monitoring in Romanian power grid

The monitoring of electric quantities coming from PMUs (Frequency, Voltages, Currents), magnitudes and angles are presented in Fig. 11. The software application was developed into the FISMEP project. The data coming from the PMUs, in a real-time way or by investigation of a recorded database, are used in power systems analyses. This technical measurement solution gives higher accuracy of the data, and as a consequence of the analyse. This power system analyses is focused on the calculation and identification of the parameters of the system (for example electric impedance of the elements of the network). Also, it is possible to be compared the measurements values and simulation models of the power network. At the same time, the visualization of the database from the power network, using PMUs, give us the possibility to analyse different unexpected faults in the network and to increase the availability of the network in operation.

Fig. 11

Monitoring of the voltages and frequency in Power Grid using software application

As we know, the processes in power system have a very high speed of evolution, which means a huge volume of the monitoring data of electric quantities.

The software application includes a component for visualisation of the electric quantities using the Grafana component of FIWARE, and the result is presented in Fig. 12.

Fig. 12

Monitoring of the currents and frequency in Power Grid using software application

Future services and applications

The API is the main part of the given ICT architecture. In which virtual infrastructure holds all API components and helps in scaling up the system according to the requirements of the services.

In the future, a list of additional components can be considered to behave precisely and efficiently such as resource API to coordinate resources, application API to make connection between interfaces and data from hardware infrastructure, protocol stack API to hold instances of standards and protocols and etc.

Conclusion

This paper has described the result of the FISMEP project in terms of developing a cloud-based and open-source ICT architecture that can be used for the smart energy system. It is powered by FIWARE that is a customizable and open-source IoT platform. A general list of functional and non-functional requirements for the system has been specified which can be taken in to account in any other system in the energy sector. Furthermore, the proposed ICT architecture has been demonstrated in the different field tests in the project.

In this research, FIWARE holds great potential for application in the investigated uses cases. However, due to its modular structure and its goal to provide an API for all possible becomes rather difficult to maintain and requires expert knowledge to operate in production.

The analysis has been done in the fields have shown that the availability of an open-source software platform will be a powerful enabler for further implementation of the smart solution in the European network particularly at the Distributed level where the need is nowadays higher. Furthermore, the compatibility with the FIWARE framework puts FISMEP at the centre of the most advanced technology for the implementation of the future Smart Districts and Cities.