Aarhus University Seal

Science and Technology


Introduction

In recent years, there has been an increasing awareness in society of the need to reinvent Europe’s electricity grid to meet the demands of 21st century customers. Having a smart grid, that integrates the power infrastructure with information and communication technologies (ICT) is considered vital to the continuous development and uptake of renewable energy sources (RES) such as solar and wind power as well as plug-in electric vehicles. The transformation of the existing power grid into a smart grid infrastructure will at the same time be addressing some of the biggest concerns of our time i.e., the ­fast-paced introduction of RES and the accelerating climate change.

From a business perspective, the intraday electricity market offers opportunities for risk reduction as well as increased profit by giving access to a wide selection of elements with different consumption and production mix, marginal costs, etc. Rather than investing in grid expansions, system operators (i.e., DSOs and TSOs) in some countries can pay, through market agreements, large electricity customers to reduce the consumption in concerned hours to avoid congestion in the grid is avoided. To realize the potential of providing flexibility, aggregators are needed to pool offers of reduced and shifted electricity demands into aggregated offers to the electricity market or to system operators.

Demand Response (DR) provides an opportunity for prosumer to play an active role in the operation of the electricity grid by reducing or shifting their electricity usage during peak periods in response to an external trigger signal. Prosumers that engage in DR offer flexibility for certain types of appliances and processes by trading off convenience in daily practices and comfort e.g., the indoor temperature range of a building. The realization of DR requires an ICT platform that provides management, aggregation, and scheduling of a large number of appliances with flexible consumption [7]. Furthermore, the aggregator service platform has the potential of providing DR to be traded both on the existing wholesale markets and on new retail markets for system operators.

Incentive-based or event-driven DR[1] can be invoked in response to a variety of trigger conditions, including environmental parameters (e.g., temperature); local or regional grid congestion; economics; or operational reliability requirements [8]. DR programs that foster an improved integration of renewable energy, aggregators can shift consumption to periods with lower CO2 intensity. Triggers from economics can for example be extrema in the wholesale electricity price. Other triggers can derive from reliability requirements such as the risk of a grid degradation caused by a major power plant tripping offline.

DR technology offers several benefits all over the power grid. Globally, DR programs can support a more efficient integration of Renewable Energy Sources (RES) in the grid and hereby contribute to a future low carbon economy. In this context, the European research project SEMIAH (Scalable Energy Management Infrastructure for Aggregation of Households) aims to develop a novel and open smart grid infrastructure for the implementation of automated DR in households. To validate this new infrastructure and for assessing the potential impacts, a large-scale simulation will be performed. In addition, the SEMIAH concepts will be validated with a total of 200 households running as a pilot in Norway and Switzerland.

SEMIAH S&T

Over the past few years, the SEMIAH project has developed a scalable infrastructure for residential DR. The infrastructure has been used to study and validate DR technically but also from a business perspective. In addition, the project has addressed security and privacy, which are among the biggest concerns in the uptake of DR services. In the following, we will present the SEMIAH infrastructure, which constitutes the key foreground of the project. This foreground has been described through a number of peer-reviewed publications available to the scientific community [1][2][3][4][5][6][11][15].

System model and architecture

Figure 1: SEMIAH layered system model

The system model of the SEMIAH infrastructure defines three distinct layers to provide abstractions for devices, information objects, and communications [12][3] as illustrated in Figure 1.

The Internet of Things (IoT) layer offers a generalization of field devices deployed in households. The SEMIAH Objects layer manages customized objects such as information objects. The SEMIAH Control layer has the role to manage SEMIAH objects according to actors’ requirements. For instance, this could be the actuation of appliances that are operated to provide flexibility for households.

The IoT layer addresses the problem of providing a uniform access to heterogeneous devices and appliances. The SEMIAH infrastructure has to collect measured values of electricity consumption and to control output values on appliances through sensors and actuators.

Appliances are addressed through a coherent semantics provided by the SEMIAH Objects layer. Ideally, semantics are defined at the appliance category level, i.e., there is a resource type per appliance category. The SEMIAH Objects layer disposes of a uniform method to access input and output parameters. This method must be independent of any appliance models, but also independent of appliance categories. An object model has been designed as part of the SEMIAH project [8].

The SEMIAH infrastructure allows system operators and electricity suppliers to activate flexibility to fulfil their specific objectives. The goal of the SEMIAH Control layer is to capture and serve user-specific requests. Typically, these relate to grid control through access to control centers, ancillary services or bidding on the energy market (stock exchange). The SEMIAH Control layer processes requests so that they can be forwarded to the SEMIAH Objects layer. The SEMIAH Control layer addresses SEMIAH Objects flexible elements. Hence, the SEMIAH Control layer can manage collections and/or individual processes. FlexibleElements require that an external entity interacts with them to concretely activate available flexibility in whole or in part. This is precisely the role of a Controller instance such as a virtual power plant (VPP). A VPP is a class, typically instantiated by a larger software component, which orchestrates FlexibleElement instances to address market objectives and/or grid control objectives.

Figure 2 shows an overview of the SEMIAH architecture infrastructure. The infrastructure uses a centralized approach where a back-end system, hosted by the aggregators, run the aggregation, scheduling and actuation of electricity loads in households. The infrastructure is characterized by a back-end system, a Home Energy Management Gateway (HEMG), and a Front-End Server (FES). The last two elements represent the front-end system of the SEMIAH infrastructure. It resembles a scalable infrastructure for residential DR built on a component-based architecture with the generic virtual power plant (GVPP) at the heart of the system.

Figure 2: SEMIAH architecture (logical view).


 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 3: System archtecture.

 

SEMIAH takes two demand response approaches in terms of scheduling, named real-time event-driven and day ahead. SEMIAH Intelligence uses the event-driven real-time scheduling algorithm and the GVPP benefits from a day-ahead method. The term generic is used here to justify that the SEMIAH infrastructure can be used with (any) VPP that adheres to the interface specifications of the infrastructure.


Front-end components

The SEMIAH front-end system consists of home appliances, and gateways that connect them together with the back-end system [10]. These components are introduced in the following.

  • Figure 3: Squid-link (gateway) hardwareHEMG hardware - The Squid.link gateway is a flexible solution for connecting networks based on different technologies.  It is a programmable Linux hub with Java and Open Services Gateway initiative (OSGi) support. Figure 3 shows the hardware specification of the gateway. ZigBee has been chosen as the preferred communication technology preferred for communication with sensors, actuators and gateways in the SEMIAH HAN.

  • Middleware service – SmartAMM is a middleware component that is capable of handling communication with several HEMGs (the number depends on the selection of network type), as well as a number of “back-end applications”. The server can be used for configuration/consolidation of the SmartAMM gateway deployments as well as delivery and reception of all types of data to and from the gateways.

  • Application software platform – OGEMA (Open Gateway Energy MAnagement) is an open software platform supports building automation and energy management. OGEMA features an object-oriented data model for internal representation of physical devices, controllable loads, generators, sensors, actors, business related data (e.g. prices), etc. Data are persistently stored in an internal HEMG database. Applications (Apps) implement functionality based on data modification events or timer events. Drivers are special Apps that provide a connection between internal and external data resources. OGEMA features a comprehensive Application Programming Interface (API) that encapsulates basic services, e.g. data administration, timing, web server, and a RESTful server for machine-to-machine communication. The OGEMA platform has been ported to the Squid-link as part of the SEMIAH project to host demand response control applications. An OGEMA version for non-commercial use can be obtained at http://www.ogema.org/

  • Messaging cloud – Cloud.iO is a lightweight framework based on field-proven protocols and open source components developed for the IoT. It offers an infrastructure to monitor and control a huge number of I/O devices on a central cloud platform. Cloud.iO can provide both, real-time monitoring and control data and historic data storage in a single place. Cloud.iO lets the application domain define its data model freely. Cloud.iO enables external applications to subscribe to monitored data and to define control set points. Hence, Cloud.iO let applications communicate with field sensors and actuators in a syntactically and semantically homogeneous ways. In this context, the service operator is the entity using Cloud.iO for a specific application (like SEMIAH).

  • Front-End Server (FES) – The FES is a Software as a Service (SaaS) infrastructure. It stores the current and historical state of the front-end system: time series of measurement results, history of set points’ updates, connection and disconnection of gateways. The FES is the basis for provisioning of front-end devices, system administration, prosumer GUI and database and analytics (DB&A). Provisioning methods for integrating and deploying gateways, including rules to identify faulty behaviour of the SEMIAH system. Alarms are then forwarded to the appropriate persons (prosumer, DSO). Rules to detect faulty behaviour have been derived and they are implemented in a Telco provisioning system is used to send alarms to appropriate parties and initialize the devices. The FES stores all data required for system operation monitoring and analysis. Using the web based GUI (see Figure 4); appropriate data can be presented to system administrators and prosumers. A system administrator portal allowing monitoring all parameters is set up. As set points changes and load curves are recorded, power-shifting operations can be analysed and qualified. Hence, the FES is a component external to the DR tool chain, enabling an assessment of the performance of that chain. The Front-end server holds the database and analytics service and provides an interface to access them [16].

Figure 4: Example of user GUI

Figure 4: Example of user GUI.

Aggregator intelligence (back-end system)

The back-end of the SEMIAH infrastructure consists of a set of distributed services interconnected over the internet using open standards communication protocols in particular secure HTTP over TCP. Data exchange between back-end services is accomplished by exchange of XML messages. The distributed nature of the back-end allows system parts to have independent product life cycles.

The SEMIAH Intelligence aims to schedule the load requests received from the (HEMGs) along with the received DSO grid constraints and forward the scheduling decisions to the GVPP. The Scalable Aggregation of Load Schedulable Appliances (SALSA) algorithm orchestrates the SEMIAH intelligence. It offers an event-based automated demand response utilizing a buffering system to locate diverse load requests of appliances in different buffers, which accelerates the SALSA’s responding function [15].

Figure 5: Conceptual view of the SEMIAH intelligence and its connections.

Figure 5: Conceptual view of the SEMIAH intelligence and its connections. 

The buffering system, shown in Figure 5, is composed of four buffers named immediately wait (iw), immediately start (is), decided to operate (do), and decided to wait (dw). It stores the load requests, coming from the GVPP, into the immediate wait buffer. These buffered load requests are forwarded to SALSA to be scheduled. The immediately start buffer is specialized for load requests of non-shiftable appliances while the last two buffers are designed for those load requests which are sent from shiftable appliances. A load request is moved to decide to operate buffer if the SALSA decides to operate the corresponding appliance at that time interval. Otherwise, the load request will be moved to decide to wait buffer. At the next time interval, the buffering system removes the load requests in decided to wait buffer and appends them to immediately wait buffer. The SALSA will decide about appended load requests and newly arrived load requests simultaneously. At each time interval, the SEMIAH intelligence sends the schedules to the GVPP based on load requests located in the decided to operate the buffer.

The “DSO Grid Constraints” is a service for configuring grid constraints for a collection of households belonging to a SEMIAH aggregator. The interface is used by DSOs to define boundaries for the operation of the scheduling of power consumption for the Collection. This interface complies with the operating regimes as defined by Universal Smart Energy Framework (USEF).

Currently, the service supports the soft and hard ECTs. As the electricity demand increases the DSO moves gradually from the normal operation schemes to the capacity management regime. This demarcation point is marked by the soft ECT and triggers the SEMIAH scheduler to start shifting electricity loads to the future. At the same times the regulating electricity markets start planning a significant role providing peak load reduction and power balancing between electricity supply and demand through market mechanisms. Should the DSO not be able to successfully manage capacity, there is a risk of hitting the second demarcation point in which the regime of graceful degradation kicks in. This is marked by the hard ECT. When crossing this boundary, the DSO may take action to curtail loads regarding any service-level agreement promises just to secure the grid supply and to regain control of the network.

Controllable Appliances

In SEMIAH, appliances are classified based on some smart features. First, appliances have been classified according to the shiftability feature [11]. Shiftability is to give permission to the demand response system to shift load requests of shiftable appliances to another time interval. On the other hand, load requests of some appliances, such as the refrigerator, cannot be shifted. Thus, those appliances become members of non-shiftable appliances. Second, the shiftable appliances can be divided into two groups based on the interruptibility feature. The electric vehicle is an example of this feature, where the demand response system can both shift and interrupt the duty cycle of charging the electric vehicle. Nevertheless, those appliances which are shiftable but uninterruptible are called uninterruptible appliances (e.g., the dish washer).

Much research in demand response has been devoted to the global control of a population of local thermostatically controlled loads (TCLs), especially by modifying the temperature setpoints of programmable communicating thermostats (PCTs) [6]. It is now well known that shifting simultaneously and instantaneously the thermostat temperature setpoints of a homogeneous population of TCLs induces oscillations. To avoid this, closed loop control solutions have been proposed. However, these require real-time communication from local loads to central controller. Research from the SEMIAH project shows how exactly simple hysteresis band shift introduces synchronization in a population of homogeneous TCLs and proposes a modification of the simple hysteresis band shift to avoid oscillations by circumventing thermostat synchronization. The algorithm’s success is proved theoretically for a homogeneous TCL set. The improvement brought by the algorithm in a moderately heterogeneous case is shown by simulation.

Virtual power plant

The back-end system of SEMIAH is based on the virtual power plant IWES.vpp. In the SEMIAH demand response infrastructure, IWES.vpp has been used as an instantiation of the GVPP. Figure 6 shows a structural view of IWES.vpp.

Figure 6: IWES.vpp structural viewFigure 6: IWES.vpp structural view.   

IWES.vpp is a software solution for intelligent integration of producer, consumer and energy storages into the energy market. It offers continuous monitoring, administration and controlling for the power plant portfolio based on a client-server-application. It can be integrated into an existing infrastructure. Customer specific modules can easily be added to meet new requirements.

The key capabilities of IWES.vpp are as follows:

  • Real-time capability – accurate detection of measurements within seconds from decentralised energy resources
  • Forecast capability – Integration of energy and price forecasts from different forecast providers
  • Resource planning capability – Automated calculation of schedules for all connected power plants. Additional provisioning of manual controlling capabilities
  • Integration – Integration with existing IT infrastructure or stand-alone
  • Power plant connection – Simple and dynamic integration of power plant to the virtual power plant based on relevant SCADA protocols (IEC61400-25, IEC61850 and OPC XML-DA.)

The Flexibility Forecast is a Prediction Provider that is needed for identifying the devices’ energy shifting potential into times where the energy consumption of these devices is more profitable. The flexibility forecast module is implemented in Python and runs on a virtual machine. The core components include a database component, Grib-Reader component, a REST framework a forecaster and a task-scheduler component.

As a database, we use a MongoDB NoSQL database, where all raw data and pre-processed data are stored. The Grib-Reader component decodes the incoming WMO FM-92 GRIB messages received from the European Centre for Medium-Range Weather Forecasts (ECMWF). After decoding, it stores all weather-forecasts into the database. Django is used as a REST framework. This component provides interfaces for the communication with OGEMA and GVPP. The forecast component is based on the open source machine learning library scikit-learn. This component generates the flexibility forecast model.  Based on this model a flexibility forecast is then created every 15 minutes. Each forecast result is stored into the database. Finally, the Task-Scheduler component handles the temporal execution of the Grib-Reader and forecast component.

Tools and Simulators

The following tools are used to simulate the residential homes’ behaviour and the load profiles of their appliances. The tools and simulator as well as their practical applicability has been published in [4] and [5].

GridSim is an open source simulator. It aims at providing a tool to simulate the load flow on a grid, and offers also the possibility to simulate physical models such as houses or heat-pumps, to evaluate the flexibility and model demand-side management. It can also model the complex interactions between energy carriers. GridSim should be used as an open toolbox to quickly design the simulator adapted to specific needs.

The simulator allows to define the topology of an energy system (electrical grid, generation, consumption and storage elements, elements transforming energy from a form to another form) as well as dynamic environment parameters (for example, temperature or solar radiation over time at a given point). An energy system is simulated over a given time period (simulation period, typically one year) with a given unit time step (typically one second). Any energy system parameter can be recorded over the simulation period.

BehavSim is coded in Python and has a GUI consisting of a toolbar with buttons dedicated to the different appliances to simulate. When the user selects an appliance by clicking a button, a message dialogue appears asking the user to provide a simulation name, the number of daily curves to generate and the relevant stochastic parameters of the appliance. The stochastic parameters depend on the type of appliance. The parameters are the probability to start the appliance, the expected value of the start time, and the standard deviation of the start time. By using this information, a normal distribution is calculated to determine the start time, if the appliance has to start. BehavSim creates a directory for the simulation. This directory contains a CSV file with the different stochastic parameters and each daily curve is saved in a CSV file together with a time vector. These CSV files will then be pushed to a time series database.

bSOL is an energy planning tool (energy and power, heating and cooling). It evaluates the influence of the variation of different building parameters. Furthermore, it simulates the annual energy needs for heating and cooling. In addition, it estimates the internal thermal comfort. For the simulation, bSol is used to generate the building properties (C, K) and the thermal gains (solar irradiation and the presence of people).

The software provides the user with a simulation of the consumed heating energy over a typical year (hour by hour) to guarantee a minimal temperature in the building, based on a thermal model of the building and average weather statistics (outdoors temperature and sunshine).  bSol is a commercial product and requires a licenses.

To scale up the simulations to 200 000 residential household and beyond, a controller module is needed to orchestrate the interplay of the simulator tools introduced above [11] . This is illustrated in Figure 7 where arrows indicate the flow of data and control information.

The controller model is called SemSim and it is combining the three simulators. bSol and BehavSim can generate all static data (data that cannot be modified during a run of simulation), these data are read by Gridsim to manage electrical and thermal simulations. Gridsim can also receive dynamic influence from other software (typically external controllers) to modify the behavior of the controlled devices (i.e. heaters and boilers) in order to change the global consumption.

Figure 8 and Figure 9 show results from a simulation with aggregation of 500 Swiss households. In Figure 8, no external control is enforced and the heating systems are governed by the temperature set points of the local controller. Figure 9 presents the scenario where the heating system is cut off during a two-hour period.

Figure 8: Global consumption of 500 households (only local controller)Figure 8: Global consumption of 500 households (only local controller)  
Figure 9: Global consumption of 500 households with a global controller cutting of heating systems between 8:00 and 10:00Figure 9: Global consumption of 500 households (with local controller)   

To study the scalability of the simulator, experiments on a computer cluster were performed. The cluster consisted of 24 CPUs with 1 core at 2.6 GHz, 40 GB SDD HDD, and 32 GB RAM. The simulation of 500 households on the computer cluster takes 190 seconds by using a time resolution of 5 minutes [11]. in the simulation. Obviously, the time of simulations depends on the number of households. It has been demonstrated in the SEMIAH project that it possible to simulate 20 000 household on the cluster and since the simulation can be reduced to an embarrassing parallel problem in computer science a sequential operation of such simulation would be able to scale further. In such, the time needed to simulate 500 000 households for 7 days with a time step of 5 minutes is about 50 hours.

Pilots and experiments

This section introduces the SEMIAH pilot and some results from DR experiments done with selected pilot installations.

Pilot areas

The pilot installed in Valais/Wallis, Switzerland was planned for 100 households. The distribution of the households covers the two Swiss electricity providers, which are the members of consortium (EnAlpin and SEIC-Teledis). Most of the installations use a heat-pump for heating and the others use electrical heating systems. The temperature is measured both inside and outside buildings, when space heating is involved. The householders of the Swiss pilot are all clients of EnAlpin or SEIC-Teledis. These clients are volunteers and were found through communication around the SEMIAH project. Finally, due to a lack of participants a total of 89 households were installed, 50 installed by SEIC-Teledis and 39 installed by EnAlpin.

The location of the Norwegian Pilot was initially Sirdal, which is a winter holiday resort with several well-equipped and power demanding holiday houses. Sirdal was chosen by Agder Energi Nett as a pilot area due to lack of transformer capacity on very cold days, and because the power consumption is very high a couple of hours a year. These consumption peaks make the area suited for DR. However, in 2016 a new transformer was installed in the area, meaning that the capacity is no longer an issue. This makes the customer relationship management easier. Therefore, the main pilot area was moved from Sirdal to Nedenes and Hisøy, which are small residential areas between Arendal and Grimstad. The areas have a high share of private households, and the transformer has been shown to occasionally be overloaded during the cold winter season. Both these factors make the area suitable for testing DR.

All the householders in the Norwegian pilot are clients of Agder Energi Nett and uses electricity for both water heating and room heating. Two recruitment processes were done to ensure 100 pilot customers, where 50 customers were recruited in late June 2016 and additional 50 were recruited in late August 2016. The software used in Norway is the same as in Switzerland; the only difference is that the Norwegian pilot used mainly GPRS-communication.

In our endeavors of establishing and operating the two pilots a large number of difficulties were encountered and a big effort was required to remedy many of the obstacles. Consequently, we include a set of ‘lessons learned’ from the project in the Discussion section below.

Security Demonstrator

 

The security and privacy functional requirements of SEMIAH was described in deliverable D8.1, and the project implemented a strict separation policy between customer data and research data in the pilots. In addition, the customers had to give informed consent to participate in the research project so that they knew that data from their houses could be used for research purposes. The project does not keep the any connection between users and data in the research data set so that subsequent reidentification of the persons participating in the study will not be possible based on the research dataset.

Figure 10: One of the SEMIAH security demonstrators














Figure 10: One of the SEMIAH security demonstrators

The security demonstrator was implemented at two of the Norwegian pilot participants. The objective of this demonstrator was to verify the security and privacy components of SEMIAH. The security demonstrator was set up in a separate test network to allow for security testing of the HEMG and ZigBee devices, as well as for demonstrating that the intrusion detection system used in the HEMG was able to detect attacks. The security tester had access to the security demonstrators via the security server, which was set up as a cloud service with restricted access so that only the security testers could access it. The privacy and security testing activities, documented in D8.1 and D8.2, ensured that the necessary privacy and security enforcement mechanisms were built into SEMIAH, from the start and also ensured that the other work packages had a strong focus on developing secure services. For example were the most serious vulnerabilities detected during the initial security testing fixed in the second security test. The security server furthermore ran the anonymiser service, which was used to demonstrate policy-based anonymisation in SEMIAH, which was a successful research track that gave several good publications. The security demonstrator was also useful for identifying the root cause of the 3G connectivity problems experienced in the Norwegian pilot.

Results from the pilot testing

To validate and demonstrate residential DR with the SEMIAH infrastructure as set of experiments were carried out by using the Swiss pilot infrastructure. Figure 11, Figure 12, and Figure 13 show the load curves during a set of experiments involving a selection of 6 pilot households.

Figure 11: All 1h cut aggregated (5 cuts, 6 households).

Figure 12: All 2h cut aggregated (4 cuts, 6 households).

Figure 13: All 4h cut aggregated (2 cuts, 6 households).

 

The results from the experiment are summarized in Table 1. During the period of the experiment the temperature of the households were monitored. The largest temperature change was observed to be 0.32° after a 4 hour cut period of one of the pilot households.

Table 1: Heating cuts characteristics

Duration  [hours]

Number of  (cuts x houses)

Power before (1 hour)

[kW]

Power during

[kW]

Decrease

[%]

Power after
(1 hour)

[Kw]

Increase

[%]

Average cut per house

[W]

1

5x6

48.5

20.7

57

55.6

15

920

2

4x6

24.5

13.9

43

45.7

87

440

4

2x6

15.4

5.6

64

21.5

39

820

In summary, we find that about 50% of the load curve can be decreased by cutting off power control for time periods op to 4 hours. We find no noticeable drop of temperature (<0.5°) and influence on client comfort was reported.

Discussion

LV impact assessment

Instability due to the feedback loop introduced between demand and DR triggers such as wholesale market prices is a conceivable risk resulting from the possible impact of a DR on the power grid [3]. It has been shown that application of real-time pricing to consumers leads to increased volatility [18] and also that DR programs based on aggregation are better in terms of stability than ones based on prices to end users [19]. Loss of diversity arises when the volume of participation in a given DR program increases and hence leads to a second risk. Load diversity is an important dimensioning factor for power grids. It is based on the observation that consumption patterns vary across electricity users. Moreover, the rebound effect arising for coordinated load shifting has two detrimental effects on the power grid. It leads to rapid voltage fluctuations potentially beyond acceptable values, and increases cable and transformer loading potentially beyond their maximum values. It is particularly strong in the case of thermostatically-controllable appliances such as Heating Ventilation and Air Conditionings (HVACs), heat pumps, or water heaters [20].

An impact assessment of demand response on the low voltage grid was carried out as part of the SEMIAH project [17]. The expected risks for low-voltage grids from the deployment of distributed power generation and demand-response schemes are summarised on Table 2. These risks are listed as undesirable, observable events and qualified by their possible root causes and consequences. The probability of occurrence and the severity of the consequences are each quantified between 0 and 1. The assessment has been based on the analysis of the two locations: Skarpnes in Norway and Visp in Switzerland.

Table 2: Risk analysis for the deployment of DR schemes in low-voltage networks (from SEMIAH D7.1 [17]).

Event

Root cause

Probability

Consequences

Severity

Risk value

Relevant for SEMIAH

Current levels above rating of transformers or lines

Rebound effect at the end of demand-response events, loss of diversity

0.9

Increased losses, tripping of protection, faster ageing of transformers

0.6

0.54

Yes

Reverse power flows

Active power injection from DG

0.6

Tripping of protection devices, exceeding operating limits of OLTC

0.8

0.48

Yes

Rapid fluctuations of total power demand

Feedback loop between demand and wholesale market price (real-time pricing)

0.7

System instability, increased reliance on peaking generation capacity

0.6

0.42

No

Overvoltage

Active power injection from DG, grid dimensioning

0.8

Malfunction/damage to end-user appliances

0.5

0.40

Yes

Current levels above rating of lines or transformers

Active and reactive power injection from DG

0.4

Increased losses, tripping of protection, faster ageing of transformers

0.6

0.24

Yes

Phase unbalance above 2%

Non-coordinated single-phase connection of PV systems; reactive power control by PV inverters

0.7

Over-current, heating, and reduced torque in three-phase induction motors

0.3

0.21

No

Rapid voltage fluctuations larger than 3% of nominal value

Variations in PV production due to passing clouds

0.5

Tripping of relays and sensitive electronic equipment, stalling of induction motors

0.4

0.20

Yes

Harmonic distortion in excess of standard limits

Switching of power electronics converters (PV inverters, variable frequency drives), possible network resonance

0.5

Increased losses, mechanical vibrations in rotating machines, interference with PLC

0.4

0.20

No

Rapid voltage fluctuations larger than 3% of nominal value

Simultaneous switching at the beginning or end of demand-response event

0.5

Tripping of relays and sensitive electronic equipment, stalling of induction motors

0.4

0.20

Yes

Unintentional islanding

Fault at MV or HV levels and stable balance between local production and consumption

0.1

Danger to operators dealing with fault; need for resynchronisation after fault clearing

1.0

0.10

No

Slow voltage variations

Variations in active power injection from DG

0.9

Faster ageing of voltage regulation devices, and transients due to their operation

0.1

0.09

Yes

Lessons learned

The most notable lessons learned from the SEMIAH project can be summarized as follows:

  • Residential demand response – An aggregated demand response from residential households is feasible and an infrastructure to support this can be developed.
  • Flexible appliances – Electrical heating appliances and boilers are very suitable appliances for residential demand response. Consumption from these appliances can be shifted several hours into the future without any remarkable degradation of user comfort i.e., indoor temperature. However, the magnitude of the response depends on the season as more flexibility can be achieved during wintertime. Electrical space heating and boilers are widely deployed in countries such as Switzerland and Norway but rarer in countries such as Denmark were heating is provided by district heating networks.
  • Legacy installation – As the electrical meters in the Norwegian pilot area were scheduled to be changed to new AMS meters, one had based the Develco Products meter reader on measuring light emitted from the meter blinking diode. However, as the change of electrical meters was postponed in the area, no such blinking diode was to be found on the old meters. Therefore, several of the meter-readers were not installable. In the Swiss pilot, the home installations differed a lot and much effort was allocated to customization of installations.
  • Connectivity problems – The signal reception from ZigBee devices in the HAN proved difficult because of wireless signal impairments in households. Boilers are typically located in basements floors and fuse cabinets in second floor, there will be a considerable amount of dampening of ZigBee-signals in the walls and floors themselves. To have remote access to the gateway in the Swiss pilot, and installed the control algorithm, a VPN was installed. The version installed on the gateway was an unstable version of Open VPN due to new needed features but this version crashes sometimes and the gateway needed to be restarted. Simple calls to the participants to disconnect and reconnect the gateway resolved the problem. However, it becomes however a tedious job when it must be done regularly.
  • ICT installations – Getting the HEMG up and running and connected to the GPRS also proved challenging. Cellular services in the area are not suitable or stable; hence, the gateways needed extensive placement "investigation" in each household. It furthermore, stresses the need for ICT competence in DSO companies desiring to deploy DR services.
  • Customer installations – In Norway, not all customers had read the documentation for participation in the project. Consequently, some had boilers that were fixed to the electrical installation of the household; hence, no smart plug implementation was possible. In the Swiss pilot, it was concluded that the instructions given to the installation crew turned up to be inaccurate, resulting in some cases of misplaced sensors. The reduced measurement accuracy ended up to be problematic for the back-end system, which could not ensure an optimal control of these households. This reduced the number of household that can be controlled by the back-end. Also for the Swiss pilot the delay on the implementation of the provisioning implied a huge difficulty on the supervision of the households.
  • Hardware failures – The Norwegian pilot also experienced Squid-link power loss because the output power of the power supply to the Squid-link was too low. The DIN-Relay at the Norwegian super-user had a failure in mid-October, reasons for the failure is unknown. However, the relay was removed and the super-user feedback was reduced. In addition, the project experiences two occasions of AAA batteries that powered temperature sensors exploding and in one occasion a smart plug was melting due to overload. The cause for the failure of the Smart Plug was a 3-kW boiler with long periods of ON-time. As the boilers in the Norwegian pilot have a power output in the range 2kW-3kW, all smart plugs were removed as of mid-January.
  • Data quality – For the Swiss pilot a number of problems was discovered when studying the data from the acquisition program. 14 households (16% of the installed households) have problems with the meter readers, which always sent null values to the database. The suspected cause was a malfunctioning sensor. About half of the installed devices have an RSSI sent to the database lower than -80 dBm, which is about the limit for a stable connection. This problem is due to the position of the gateway and sensor in the household but it was obviously not always possible to change the position of the sensors or to add wireless relays in the HAN. This strong attenuation effect had a large impact on battery life. Some of the batteries had to be replaced after only six months. The RSSI issue also implies a lack of data during several periods. Several households have missing data, probably due to temporary connection loss, while 14 out of the 40 households are completely missing boiler consumption data on at least one of the three phases. Five of the installation boiler-only are mainly heated by a heat pump whereas the sensors of the electrical consumption are installed on the auxiliary electrical heating system. The given values, stored in the database cannot be used to determine the behaviour of the boiler consumption.   

References

[1]      R. H. Jacobsen, A. G. Azar and E. S. M. Ebeid, "Design of an Event-Driven Residential Demand Response Infrastructure," 2016 Euromicro Conference on Digital System Design (DSD), Limassol, 2016, pp. 38-45.

[2]      A. G. Azar, E. Ebeid and R. H. Jacobsen, "A Formal Framework for Modeling Smart Grid Applications: Demand Response Case Study," 2016 Euromicro Conference on Digital System Design (DSD), Limassol, 2016, pp. 46-54.

[3]      R. H. Jacobsen, D. Gabioud, G. Basso, P. J. Alet, A. G. Azar and E. S. M. Ebeid, "SEMIAH: An Aggregator Framework for European Demand Response Programs," 2015 Euromicro Conference on Digital System Design, Funchal, 2015, pp. 470-477.

[4]      G. Maître, G. Basso, C. Steiner, D. Gabioud and P. Roduit, "Distributed Grid Storage by Ordinary House Heating Variations: A Swiss Case Study," 2015 Euromicro Conference on Digital System Design, Funchal, 2015, pp. 241-249.

[5]      G. Basso, P. Ferrez, D. Gabioud and P. Roduit, "An Extensible Simulator for Dynamic Control of Residential Area: Case Study on Heating Control," 2015 Euromicro Conference on Digital System Design, Funchal, 2015, pp. 486-493.

[6]      G. Maître, D. Gabioud and P. Roduit, "Local algorithm for the open loop control of thermostatically controlled loads," 2016 IEEE PES Innovative Smart Grid Technologies Conference Europe (ISGT-Europe), Ljubljana, 2016, pp. 1-6.

[7]      S. Karnouskos, “Demand Side Management via Prosumer Interactions in a Smart City Energy Marketplace,” in Innovative Smart Grid Technologies (ISGT Europe), 2011 2nd IEEE PES International Conference and Exhibition on, 2011, pp. 1–7.

[8]      Stefan Siegl, Jan Ringelstein, Dominique Gabioud, Alain Woeffray, “D4.2 – Data models”, SEMIAH technical report, revision 1, October 2015.

[9]      F. E. R. Commission, “2011 Assessment of Demand Response and Advanced Metering: Staff Report,” Tech. Rep., 7 Novmeber 2011. [Online]. Available: http://www.ferc.gov/legal/staff-reports/11-07-11-demand-response.pdf

[10]   E. Ebeid, A. G. Azar, and R. H. Jacobsen, S. Siegl, C. Stolz, J. Ringelstein, D. Gabioud,  and G. Basso, “D4.3 – Demand Response Prototype”, SEMIAH technical report, revision 1.8, March 2016.

[11]   A. G. Azar, R. H. Jacobsen and Q. Zhang, "Aggregated load scheduling for residential multi-class appliances: Peak demand reduction," 2015 12th International Conference on the European Energy Market (EEM), Lisbon, 2015, pp. 1-6.

[12]   G. Basso, P. Ferrez, and P. Roduit, “D5.2 – Large-scale simulator“, SEMIAH technical report, revision 4.1, 27 February 2017.

[13]   D. Gabioud,  E. László,  G. Basso, H. Unander, K. Werlen, N. Ullveit-Moe, R. H. Jacobsen, S. Funk, S. Siegel, T. Gjøsæter,  “D3.2 – System Requirements and Functional Specifications”, SEMIAH technical report, revision 1.02, 9 March 2017.

[14]   G. Basso, P. Ferrez, G. Maitre, P. Roduit, C. Levinsen, K.-R. Kastet, O. Elisa, A. Nazgul, “D7.2 – Pilot test and large scale pilot simulation and impact assessment report”, SEMIAH technical report, Maj 2017.

[15]   A.G. Azar and R.H. Jacobsen, “Appliance Scheduling Optimization for Demand Response”, International Journal on Advances in Intelligent Systems, vol. 9 no 1 & 2, 2016, pp. 50-64.

[16]   Nils Ulltveit-Moe and László Erdödi, “D4.4 – Database and Analytics Service”, SEMIAH Technical Report, revision 1.3, 2016.

[17]   Pierre-Jean Alet and Lionel Bally, “D7.1 – Low-voltage grid assessment”, SEMIAH Technical Report, revision 1.0, July 2015.

[18]   M. Roozbehani, M. A. Dahleh, and S. K. Mitter, “Volatility of Power Grids Under Real-Time Pricing,” IEEE Transactions on Power Systems, vol. 27, no. 4, pp. 1926–1940, 2012.

[19]   J. L. Mathieu, T. Haring, J. O. Ledyard, and G. Andersson, “Residential Demand Response Program Design: Engineering and Economic Perspectives,” in 2013 10th International Conference on the European Energy Market (EEM), 2013, pp. 1–8.

[20]   W. Zhang, K. Kalsi, J. Fuller, M. Elizondo, and D. Chassin, “Aggregate Model for Heterogeneous Thermostatically Controlled Loads with Demand Response,” in 2012 IEEE Power and Energy Society General Meeting, 2012, pp. 1–8.