The present invention relates to systems and methods for configuring a demand response (DR) service in an energy distribution network and for coordinating such a service across different pools of DR-capable energy assets.

Electricity suppliers and grid operators implement a variety of energy management techniques at industrial sites or residences, as well as in the distribution grid and transmission grid. Grid operators find it increasingly challenging to manage aspects of their respective energy grids such as balancing electricity supply with demand and responding to frequency shifts in the electrical grid.

In general, a grid operator may mandate behaviour of (or provide financial incentives for) energy producers or energy consumers in order to ensure a stable and responsive electrical grid. For example, a grid operator may buy regulation capacity from industrial consumers and/or producers of power. A consumer or producer offering such a service will receive the mandate to reduce or increase their power consumption when required by the grid operator in order to maintain stability and quality of the grid. There may be a specific requirement that a reduction or increase in power consumption must be stable for a relatively long period of time, or that any such reduction or increase occurs rapidly. Importantly, a grid operator desires to manage assets that consume or supply electrical energy (e.g. electrical loads or generators) at the portfolio level rather than at the individual asset level.

A fast response time can be particularly important for an electricity grid operator. A grid operator is expected to keep the frequency of the power offered on the grid stable (typically 60 Hz in the United States and 50 Hz in Europe), but it can be challenging to keep the grid frequency within an allowable margin. For example, if a power plant is shut down unexpectedly, a large amount of power is suddenly unavailable (demand exceeds supply) and the frequency on the grid will decrease. Similarly, the frequency on the grid will drop if large industrial loads come online and supply is slow to meet that demand. If the frequency of the grid decreases, the frequency can be brought to its reference level by reducing power consumption on the grid or by increasing the supply (or a combination of both). However, it can be challenging to mandate a reduction in power consumption from among a diverse collection of industrial or residential consumers. Perhaps more importantly, it can also be very difficult to achieve a reduction in power consumption as quickly as a grid operator seeks to achieve it - typically on the order of seconds (or even faster), rather than on the order of minutes. A centralized management system may not be able to detect the deviation, schedule a reduction in power, and deliver the schedules to the industrial loads reliably in that short amount of time. The reverse can happen as well. When supply is larger than demand, as happens for instance in case of under-forecast of renewable power production, the frequency can rise above its reference level (50 Hz or 60Hz). This can be offset either by decreasing the power production or by increasing the power consumption (or a combination of both).

Prior art techniques include using a simple binary switch at a load that will switch off the entire load when the switch detects that the frequency of the power has dropped to a certain level (e.g., the load is switched off when the frequency drops to 49.9 Hz). However, this is a static technique in which the switch is an isolated hardware device that is locked into always switching off the load at a particular frequency; such a device might rigidly switch off the load in such a fashion for many months or years without taking other information into account. This technique also works unilaterally, in the sense that it does not allow the local operational managers to refuse requests for power activation based on operational or business constraints. Moreover, this technique is performed at the load level and does not benefit from any portfolio optimization.

More recently, techniques have been developed that utilize portfolio optimization to improve response by using a combination of energy consuming and/or energy producing assets to implement a combined demand response.

WO 2015/059544, the disclosure of which is herein incorporated by reference, describes an energy management system that allows a grid operator to manage a portfolio of energy loads at the aggregate portfolio level, while responding rapidly and reliably to changes in grid characteristics. A hybrid approach is used in which a central site, based upon a mandate by a grid operator to reduce (or increase) power according to frequency deviations within a frequency band, determines the optimal frequency triggers at which each load within a portfolio should reduce (or increase) power. Symbolically, loads are "stacked" within this frequency band in order to optimize the global droop response of the portfolio so that optimal reliable power is delivered to the portfolio in the case of a grid frequency deviation. These triggers (and corresponding individual load power reductions) are periodically dispatched from the central site (in response to changes in the loads’ and grid's behaviour) to the individual loads. When a frequency deviation occurs, each load is able to independently (i.e., without interaction with the world outside of the industrial site) and quickly reduce its power consumption according to the triggers and corresponding power reductions it has previously received. Each trigger signals the load to reduce or increase power according to the state of the grid as locally measured. This approach reduces the reliance upon the central site to detect a frequency deviation and then to dispatch power reductions in real time.

In practice (regardless of the particular aggregation approach used), demand response implemented at the aggregated portfolio level may involve large numbers of assets distributed across the network. A change in grid frequency or other event triggering activation of a demand response service may result in the simultaneous activation of numerous assets on the grid, each asset changing its energy flow to or from the grid at approximately the same time. This can cause parts of the grid to become overloaded, for example if many activated assets are located in the same region of the grid. Thus, known aggregation techniques do not necessarily scale to large grids with large numbers of demand response capable assets. Furthermore, the available assets may be managed and controlled by different operators / service providers, each of which may provide their own asset pool for use in DR services, further complicating effective coordination of an appropriate demand response strategy.

Embodiments of the invention seek to address or at least alleviate this problem.

Accordingly, in a first aspect of the invention, there is provided a method of configuring a demand response service in an energy distribution network, the demand response service comprising on-demand adjustment of energy flow between energy assets and the distribution network, the method comprising: receiving a plurality of configuration options, each configuration option defining a demand response capability and associated with a pool of assets available for providing the demand response capability; identifying a set of assets for implementing the demand response service based on: the configuration options; locations of available assets associated with the configuration options; and network constraints relating to the locations of the available assets; and outputting configuration information for configuring the identified set of assets to implement the demand response service.

Identifying the set of assets may comprise selecting assets corresponding to one or more of the configuration options, such that utilisation of the selected assets to provide the demand response service complies with the network constraints.

The identifying step preferably comprises selecting or identifying one or more asset configurations in dependence on the network constraints, each asset configuration comprising or specifying a set of assets for implementing the demand response service, each asset configuration optionally further selected in accordance with one or more of the configuration options. Thus, an asset configuration is preferably a specific selection of assets that can be used to implement the demand response service. The specific selection of assets is preferably drawn from one or more of the pools of assets associated with the configuration options.

Selecting an asset configuration in dependence on network constraints preferably comprises determining whether provision of the demand response service using a given set of assets would violate one or more network constraints, the identifying step preferably comprising selecting an asset configuration that does not violate the network constraints.

One or more asset configurations may be generated in an iterative search process. The method may comprise, iteratively: identifying an asset to be added to an asset configuration, such that provision of a demand response service using the asset configuration including the identified asset meets the network constraints, and adding the selected asset to the asset configuration; until the asset configuration meets one or more requirements for the demand response service, the requirements optionally comprising a total demand response capacity to be provided. The requirements may additional comprise compliance with asset selection criteria specified by one or more of the configuration options. Thus, an asset configuration may be generated by iteratively adding assets to the configuration, each asset added only if the resulting configuration complies with the constraints, until a complete configuration suitable for providing the demand response service is obtained (e.g. meeting the required total demand response capacity and/or other requirements).

The method may comprise evaluating a plurality of asset configurations based on an optimisation metric, and preferably selecting a given asset configuration that optimises the optimisation metric (e.g. in comparison to other configurations considered). This may, for example, be done as part of an iterative search process. For example, the method may comprise iteratively generating and evaluating asset configurations until a termination criterion is met, preferably wherein each successive asset configuration is selected to have an improved optimisation metric compared to a preceding asset configuration and/or wherein an asset configuration not having an improved optimisation metric is discarded. Note an “improved” optimisation metric may correspond to a higher or lower metric value depending on the representation of the metric and hence whether higher or lower metric values are preferred for the solution. For example, for a cost metric a lower metric value is typically preferred and so the search process would seek configurations with lower optimisation metric values. Similarly, the “optimal” solution may be the configuration with the highest or lowest metric value depending on the metric used. It should further be noted that optimisation as used herein does not necessarily imply that a globally optimal solution is sought or found, but rather the best solution within applicable constraints and processing limitations (e.g. where the search is limited in processing time/iterations).

The optimisation metric may be based on one or more of: one or more performance metrics, one or more environmental impact metrics; and one or more cost metrics (e.g. financial cost). The environmental impact metric may relate to emissions caused by use of the selected assets to implement the demand response service, e.g. a CO ₂ emissions or carbon footprint measure).

Each configuration option preferably specifies: a demand response service level, and asset selection criteria determining assets required for providing the demand response service level, wherein the identifying step preferably comprises selecting assets corresponding to one or more configuration options in dependence on their respective demand response service levels and/or asset selection criteria. The demand response service level may specify a demand response capacity, optionally a power capacity (e.g. a consumption or supply capacity), that can be provided by a given group of assets from the pool of assets associated with the configuration option, the group of assets preferably determined by the asset selection criteria.

The identifying step preferably comprises selecting assets from one or more selected configuration options in accordance with their respective asset selection criteria. The asset selection criteria for a configuration option preferably specify a number of assets required for implementing the demand response service level, optionally by specifying a number of assets required for each of a plurality of distinct asset types. Thus, asset selection criteria may specify numbers of assets of one or more specified asset types that should be selected from the asset pool associated with a configuration option to provide the demand response service level specified by the configuration option.

The method may comprise receiving one or more configuration options from each of a plurality of asset operators (e.g. aggregators or flexibility service providers) each pertaining to demand response capabilities made available by assets managed by the respective operators, and wherein the outputting step preferably comprises transmitting configuration information for selected assets corresponding to a given configuration option to the corresponding operator.

The method may comprise receiving asset information specifying locations of available assets, preferably wherein asset location information is received from each of the plurality of asset operators for assets managed by the respective operators. The network constraints may define one or more of: limits on energy flow, optionally power limits, at locations of the distribution network; limits on demand response capacity that may be activated at locations of the distribution network; and limits on numbers of assets that may be configured for the demand response service in one or more network regions.

The identifying step preferably comprise evaluating a given asset configuration by determining whether implementation of the demand response service using a selected set of assets causes energy flow, or activation of demand response capacity, at a location of the distribution network exceeding a limit specified for the location by the network constraints.

Evaluation of compliance of an asset configuration with network constraints is preferably dependent on an expected baseload in the energy network, the baseload preferably corresponding to energy flows in the network when the demand response service is not being provided. The baseload may e.g. be predicted based on past energy flow measurements.

The method may further comprise receiving network constraint information specifying the network constraints, optionally from an operator of the distribution grid.

The network constraint information may comprise a network model specifying constraints applicable at a plurality of network locations, and preferably wherein the locations of assets are specified in relation to the network model. The network model may comprise a topological network model, preferably a connection graph (e.g. a tree), the constraints defined in respect of nodes and/or edges of the graph. For example, constraints may comprise constraints on energy flows through particular nodes, e.g. limiting consumption by all energy consumers connected in a tree graph below the particular node.

Alternatively or additionally, the network constraint information may specify constraints applicable to one or more geographical regions, and preferably wherein the locations of assets are specified as geographical locations. Constraints may specify, for a given geographical area, one or more of: a maximum number of assets that may be activated for demand response in the area, a maximum demand capacity per activated asset, and a maximum total demand capacity that may be activated in the area; the geographical area optionally defined as a circular region of particular dimensions (e.g. particular radius/diameter).

The identifying step preferably comprises identifying a set of assets achieving a predetermined, or maximum, demand response capacity and/or a predetermined, or minimum, cost, without violating network constraints.

Outputting configuration information preferably comprises transmitting the configuration information to one or more operators or asset management systems for configuring selected assets for the demand response service, wherein the configuration information is preferably transmitted to respective asset management systems of respective asset operators associated with selected configuration options, wherein the configuration information preferably comprises asset selection information specifying the assets selected for implementing the demand response service.

The method may further comprise configuring the identified assets (or a set of those assets) by the or each operator / asset management system, or configuring one or more asset controllers associated with a set of the identified assets to implement the demand response service, preferably wherein assets or asset controllers implement demand response in response to a remote control signal or in response to locally measured grid conditions, preferably based on frequency set points or response curves configured for the assets or asset controllers. The method may further comprise operating the assets in accordance with the configured demand response service, e.g. to respond to a frequency fluctuation in the grid.

In a further aspect of the invention, there is provided a computer system or apparatus having means, optionally comprising one or more processors with associated memory, for performing any method as set out herein. In a further aspect, the invention provides a (tangible) computer-readable medium comprising software code adapted, when executed on one or more data processing devices, to perform any method as set out herein.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus and computer program aspects, and vice versa.

Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which:-

Figures 1A-1C illustrate approaches to controlling power assets in an electricity distribution grid, including a centralized real-time control approach (Fig. 1A), a hybrid control approach (Fig. IB), and a distributed self-organising control approach (Fig. 1C);

Figure 2 illustrates a process for determining an asset configuration for a demand response service;

Figure 3 illustrates a system including a demand response coordinator for coordinating a demand response service across multiple asset pools;

Figure 4 illustrates a coordination process performed by the system;

Figure 5 illustrates a topological network model specifying grid constraints; Figure 6 illustrates the application of geographically defined grid constraints; Figure 7A illustrates a search process for identifying an asset configuration meeting constraints;

Figure 7B illustrates a process for implementing a demand response service; and

Figure 8 illustrates a computer system for implementing the demand response coordinator. Overview

On-demand adjustment of power flow (supply or consumption) between an asset and the transmission or distribution grid is referred to as “demand response”. Embodiments of the invention provide a coordination system that allows configuration of a demand response service involving multiple assets that may be distributed widely across the grid and may be drawn from different pools operated by different operators or service providers.

Demand response services may be provided for a variety of reasons. In one example, demand response is performed in order to affect grid frequency, for example to respond to and counteract fluctuations of the transmission frequency on the grid, which is also referred to herein as frequency control response.

Note that the provision of operating reserves to counter frequency fluctuations is also known as frequency containment reserve (FCR); in contrast, the term “frequency control response” as used here refers to the control actions that exploit that reserve by modifying power supply/consumption of assets.

The following provides background on frequency control, and example embodiments will be described in the context of implementing a frequency control demand response service. However, the invention is not limited to that context and can be used in other demand response applications and more generally in any context where regulation of supply or consumption capacity is performed.

Fluctuations in the AC (alternating current) transmission frequency on an electricity distribution/transmission grid can be countered by adjusting power consumption from the grid or power supply into the grid. Specifically, an increase in grid frequency above the standard expected value (e.g. 50 Hz in Europe), also referred to herein as the reference or nominal frequency value, can be countered by increasing consumption or reducing supply, whilst a decrease in grid frequency can be countered by decreasing consumption or increasing supply. In some cases providers that have suitable energy consuming or energy supplying assets connected to the grid can contract with the grid operator (e.g. a Transmission System Operator or TSO) to provide demand response by adjusting supply or consumption of one or more assets to counter a frequency fluctuation. An energy consuming asset may e.g. be an industrial load such as a factory or machine, an electrical vehicle charging point, a domestic electricity supply point or domestic load, an energy storage device partially or fully discharged that requires recharging, or the like. An energy providing asset may, for example, be a generator (e.g. a petrol generator, wind turbine, solar panel etc.) or an energy storage device such as a battery. Multiple individual consuming and/or supplying devices may operate together as a single asset (e.g. turbines in a windfarm, various machines and systems in a factory). In some cases, an asset may be able to both supply energy to, and consume energy from the grid (e.g. a factory with onsite generator consuming excess demand from the grid and supplying excess generating capacity to the grid at different times, or a battery able to store power drawn from the grid and supply the stored power back to the grid at a later time).

Frequency control generally requires a provider to provide a power output that responds linearly with the frequency deviation from second to second. This can be done at asset level, or at pool level using an aggregation technology. The frequency control response service needs to be provided within the constraints of the assets participating in the service.

When providing the service at pool level, the system can leverage the fact that a combination of assets can provide a better response relative to the sum of all the individual responses. Examples include:

• Assets each configured to respond to deviations in different parts of the frequency spectrum. For example, a first asset may respond by adjusting its output when the frequency falls in a first frequency band, whilst a second asset may respond in a second frequency band. The assets may work cumulatively, e.g. as the frequency deviates further from the nominal value, additional assets activate their frequency control response. • Fast assets compensating for slow assets not able to meet the relevant ramp constraints. For example, a battery may be able to respond quickly (but may have limited output capacity), whilst a generator may take longer to start up and reach the required output level, but may then have higher output capacity. In such a situation a fast asset may be configured to respond during an initial period while a second, slower asset, ramps up its output. The response speed of a slow asset may be characterised by a delay in responding and/or by a slow ramp rate.

• Continuous assets compensating for the discrete behaviour of discrete assets, for example binary assets. A binary asset is an asset which is either on or off - i.e. it supplies (or consumes) at a fixed level when active (on), and supplies (or consumes) nothing when inactive (off). Other discrete assets may provide multiple distinct power levels (in addition to an off state). A continuous asset is an asset that is able to vary its supply output or consumption gradually (e.g. linearly) in response to a control signal and/or in response to the required frequency adjustment or locally measured frequency deviation. Thus, in one example, a continuous asset may be controlled to make up for any shortfall in the response (e.g. power output) delivered by a discrete asset.

• Assets compensating for each other when one or the other becomes partially or completely unavailable. For example, some assets may only be available to perform a demand response during particular time windows (e.g. a solar generator only being available during the day and depending on weather; an industrial generator only available when not in use to support an industrial facility).

In a concrete example of aggregated frequency control response, a fast energy device such as a battery (typically energy constrained) and a slow energy load such as an industrial oven (typically not energy constrained) are both used to respond to frequency deviations. Typically, such a slow industrial load cannot fully provide frequency control service compliant with the requirements set forth by the TSO and it needs a partner, such as a battery, that can compensate for its low ramp rate. In exchange, the slow load compensates for the throughput (number of cycles) and limited energy content of the battery. A typical aim when aggregating assets is generally to provide a response that is as linear as possible. Thus efficient aggregation can be viewed as a combination of a combinatorial and continuous optimisation problem.

The way in which aggregation of assets is achieved depends on the approach used for controlling and coordinating assets in the grid. A number of control approaches might be considered, some of which are illustrated in Figures 1 A - 1C.

Figure 1A illustrates a real-time centralised control approach using external set point control. In this approach, power set points are calculated at a position remote from (e.g. outside the geographical perimeter of) the asset. In an example, a battery may provide frequency control response where the set points are calculated at a distant server or at a different asset. In example shown in Figure 1A, a controller 102 performs centralized control by sending control signals from the central controller (e.g. a server) to all or some of the assets connected to electricity distribution grid 100. In this example, two assets “A” 104 and “B” 106 within grid 100 are depicted as receiving control data from central controller 102. The control data determines the power input/output level required from the asset (the “set point” e.g. measured in MW) and may be specified in absolute terms or in relative terms as in increase or decrease in a current power level. As a result, the set point for the asset (e.g. a battery) is not defined locally to the asset (where “locally” may e.g. mean below the grid connection point of the asset).

The controller performs real-time control (e.g. updating set points at a particular update frequency and/or in response to changes in measured grid frequency). The control data may be based on a single centrally measured grid frequency (shown as “f ’ in the Figures), for example measured locally to the controller or at some other central location, on the assumption that the frequency is substantially the same across the grid. Alternatively an asset could send its local frequency measurement upstream towards the controller calculating the set point, with the controller computing the set point and sending it back to the asset. While a central controller is shown, in practice the controller could be located anywhere; for example a particular asset may host a computing node for implementing the control function and provide control data to other assets.

The controller may control all assets or only a subset depending on requirements. The total set of available assets considered are generally those available for performing demand response and/or frequency control response (referred to as the asset pool). These may, for example, include assets provided by providers having agreements to implement demand control with the grid operator and/or assets provided by the grid operator themselves. The grid will typically contain many more assets not capable of or available for demand control.

The central controller may apply asset aggregation as needed, as described previously, e.g. configuring a fast and slow asset in real-time based on the measured grid frequency to provide complementary frequency control responses.

Figure IB illustrates a hybrid control approach, as described further in previously mentioned patent publication WO 2015/059544.

In this approach, the central controller 102 receives contract terms from the grid operator defining a particular portfolio response function that defines the amount of flexible power to be provided as a function of a signal that can be measured locally on the grid (e.g. a frequency band, a response time, and how much power the overall portfolio of loads should shed should the frequency drop to the lowest point of that band). Based upon those terms, the central unit calculates a control configuration in the form of a set of local control parameters for each asset in the portfolio used to configure the processing unit of each asset. These control parameters describe a local response function for an asset that defines the amount of power to be provided (or similarly consumed) by each of the individual assets as a response to a locally measured change in the grid frequency. The configured response may, for example, indicate a frequency range during which an asset should provide a response and/or the level of response to be provided.

The configurations (control parameters) are sent to each asset and each asset is then able to manage its power in real time based upon a frequency deviation that it detects locally. Thus, the grid operator does not control the loads in real time as in the centralized control example above. A typical example of such a local response function describes a linear relation between the grid frequency deviation and the amount of provided flexible power (though non-linear response functions are also possible, e.g. a simple binary asset providing a simple on/off response based on a frequency threshold).

In the Figure IB example, assets A and B are configured ahead of time with a respective response function 108, 110. Each asset then implements the pre-configured response locally based on the locally measured grid frequency (fl, f2) and the respective response function. For example, each asset detects the current grid frequency and its own power consumption; if the frequency at the asset reaches the asset’s trigger point (or is within its configured frequency sub-band), a frequency control response is activated and the asset immediately and independently uses its response function to alter its power consumption/supply.

The configured response function may be updated from time to time as needed by the central controller.

As described previously, the central controller may coordinate responses by different assets and apply asset aggregation as needed. For example, assets may be configured based on their respective capabilities to respond within different frequency bands (individually or cumulatively), such that the combined response achieves the desired (close to) linear response to the frequency deviation. Furthermore, complementary assets (e.g. fast and slow assets) may be configured to use complementary response functions, so that the required aggregate response is achieved, without the individual assets necessarily being aware of each other’s frequency control response contribution.

Figure 1C illustrates a distributed self-organising control approach. In this approach, assets communicate directly with each other via a communications network and exchange information about their respective capabilities, e.g. in the form of an operating model describing an asset’s response characteristics (e.g. whether an asset is a binary or continuous asset, power output/consumption capabilities, ramp rate etc.) The exchanged models allow an asset to know how another asset will respond to frequency changes (e.g. whether an asset has a slow response).

The assets then determine and negotiate appropriate aggregation groups autonomously based on the exchanged information (e.g. pairing a fast and a slow asset having complementary demand response capabilities into an aggregation group). Each asset can then perform real-time control based on its local measured grid frequency, taking into account the expected response of the other aggregated asset(s) in the group to a frequency deviation based on the exchanged models.

Exchanging models between assets obviates the necessity for a central entity to directly control the loads and sources, and the need for exchanging real-time data between loads/sources, thus providing resilience against communication failure or information loss.

Aggregated groups of assets (loads / energy sources) are formed through peer-to-peer interactions and based upon the particular demand-response service to be provided. Assets exchange models with one another, and, after executing a model to determine what a potential partner can provide with respect to the particular demand response service, the receiving asset decides whether or not to form an aggregation group with the potential partner. Aggregated groups may also be formed based upon historical data that is learned over the course of time with other loads and sources. An asset in an aggregation group may then depend upon the model of a partner asset in a group in order to calculate its own control policy.

The process involves a negotiation phase, during which assets communicate amongst themselves in order to form one or more aggregation groups. In this step, an asset is generally looking for another asset or assets with which it can cooperate in order to provide an improved frequency control response. Advantageously, communication between the devices is peer-to-peer and does not need to go through a central entity, thus providing resiliency against communication failure.

The model of an asset can thus be used in the decision making and control policy of the other asset. During operation, each asset follows its own local control policy taking into account the model or models received from other devices with which it has agreed to form an aggregation group, resulting in a coordinated, combined response to frequency fluctuations in the grid.

Communications and control

In the above control arrangements, assets may communicate with each other and/or a central controller via any suitable communications means, including wired and/or wireless networks, using any appropriate communications technology and media, including e.g. narrow-band IoT (Internet of Things), ADSL, fibre networks, 4G or other cellular, or Ethernet. Networks may encompass private networks and dedicated connections, as well as public networks such as the Internet. Communication with and between the energy assets may be performed via and/or under control of a central entity such as the central controller, or by using peer-to-peer communication directly between assets.

In the various approaches described above, assets are discussed as providing processing functions (e.g. implementing frequency control response in response to centralised real-time control as per Fig. 1A, monitoring local frequency and implementing frequency control response using a preconfigured response function stored at the asset as per Fig. IB, or peer-to-peer negotiation and model-based control as per Fig. 1C). Such processing functions may be implemented using a device agent, which is software that executes on local computing hardware in close proximity to the asset to be controlled. In one example, this local controller may comprise an embedded controller integrated into the asset. In another example a locally connected controller may be provided. Such a controller may also independently control multiple assets, e.g. via separate device agents running on the controller. For example, a set of batteries could be controlled by a single network-connected control computer, maintaining separate control parameters (e.g. response functions) and/or device agents for each. In the Figure 1C scenario, the device agent implements the peer-to-peer negotiation, frequency data broadcast etc. The device agent may execute upon a general-purpose computer or on specialized computing hardware, for example using a “FlexTract” controller available from Centrica Business Solutions Belgium N.V. of Antwerp, Belgium. Thus, where an asset is referenced herein this may generally be taken to include the energy supply or energy consuming device(s) themselves together with any integrated or associated control hardware.

External grid sensors connect to the electrical grid and sense variables such as grid frequency, voltage or power quality, and send this information to the device agent on the local computing hardware. The local controller is also connected to the communications network for communication with other assets and/or a central controller (if used).

Coordinating demand response services across multiple aggregators

While the above description illustrates basic principles of aggregated demand response in relation to small numbers of assets, in practice much larger numbers of assets may be involved and these may be distributed widely over the network. For example, while aggregation of two complementary assets (e.g. a fast asset and a slow asset) may provide the required response characteristics, multiple assets of each type may be required to achieve the required capacity (e.g. in terms of total MW consumption increase that is to be achieved). Furthermore, the assets in question are not necessarily owned and operated by the entity requiring the demand response service, e.g. the grid operator. In practice, asset pools provided by multiple different providers (referred to herein as “aggregators” and also sometimes known as flexibility service providers, FSPs) may be available and may include different asset types, asset numbers and capabilities. The grid operator is thus faced with the problem of identifying which assets to use, from the available asset pools/aggregators, to implement the required demand response service.

Furthermore, a given aggregator may have their own requirements as to the particular mix of assets needed to ensure reliable provision of the demand response (e.g. based on its knowledge of asset performance characteristics such as availability, response time, ramp rate etc.)

As a concrete example, assume an aggregator wants to deliver an FCR service to a TSO with a portfolio of assets, including a fleet of electric vehicles (EVs), heat pumps and hot water heating tanks. In this example, the assets are not capable of delivering the required services on their own, due to:

• Lack of availability, e.g. EV’s and hot water heaters are not always available, this unavailability is stochastic.

• Hot water heaters and most EV’s can deliver a service in mainly one direction, i.e. increase consumption.

• Heat pumps are not fast enough to deliver the service, i.e. their response time is too slow.

Aggregators compensate for this by:

• Lack of availability: Monitor the availability of the assets and activate those assets that are available. Heterogeneity of availability may be necessary to ensure constant availability with a minimum number of assets. Depending on the availability statistics a certain amount of power can be sold to the TSO. For example with 100 hot water tanks that are available 90% of the time, 90% of the total tank power can be used.

• Response time: A slow response of a heat pump is compensated for by the fast response of an electric vehicle; the heat pump is used for long activations when the EV battery is being charged.

Another consideration for aggregators is the number of assets required to provide a given level of demand response (e.g. a particular power capacity). Note that the number of assets does not necessarily scale linearly with required consumption level. For example, for a fleet of electric vehicles dispersed over the grid, assume that an aggregator wanting to deliver, for example, 100 kW of DR capacity, determines that it requires 100 water heating tanks that it can freely use. On the other hand, to deliver 200 kW only 180 tanks may be required.

This relationship is typically non-linear due to sqrt(N) behaviour, for the following reasons. Each asset can be viewed as a random variable that has a certain average power and follows a normal distribution in terms of being available, e.g. due to utilisation/connectivity issues etc. Given the aim to guarantee a certain DR power capacity being available, an available power level may be modelled based on both the average available power and the standard deviation of that power (e.g. average power - 3 * the standard deviation of that power). The same can be applied at an aggregated level. With a simplifying assumption that there is no correlation in the intrinsic driver of uncertainty (in practice there will typically be some correlation), this means that the standard deviation at aggregated level scales with the individual standard deviation and inversely with sqrt(N). As a result, in one model the power that can be offered as a function of the number of assets (N) scales as

N x average mean power — Ns /N

The specific relationship typically depends on the characteristics of the assets. Thus, depending on the asset types, appropriate numbers of the different assets may need to be selected (e.g. to deliver 100 kW with an EV/heat pump portfolio, 100 heat pumps and 100 EVs may be required to provide the required aggregate performance, whereas using only assets of one or the other type may not be sufficient). Note the specific numbers (e.g. capacities, asset numbers etc.) in the examples presented herein are merely illustrative.

The aggregator may generally not know the precise usage pattern of available assets in advance, only usage statistics, and thus should select a sufficient number of assets to ensure the required capacity will be available. Thus, allowing for redundancy in view of availability statistics, the aggregator may need to reserve a larger number of assets to ensure the full capacity will be available.

The system described herein aims to provide a demand response (DR) coordinator able to configure a demand response service across a set of assets drawn from distinct aggregator asset pools, taking the above requirements into account.

At the same time, the system preferably also considers the effects of the DR service being configured on the grid itself. Using large pools of assets for DR services such as FCR can result in severe synchronization of consumption, i.e. all assets can be activated when the grid frequency or TSO signal mandates this. This can result in a grid failure as typical grids are not designed for this. The presently described system therefore checks that the DR solutions fall within grid constraints, taking account of the fact that the overall DR service may involve contributions from various different aggregators’ asset pools.

The basic approach is summarised in Figure 2 and involves three main stages.

In the first stage, the DR coordinator receives a DR service request in step 202 (e.g. requesting a specific total DR capacity). The DR coordinator then obtains information from the aggregators and grid operators to allow a suitable asset configuration to be identified. This involves:

• In step 204, receiving a set of DR configuration options from aggregators, specifying DR capabilities offered by the aggregators

• In step 206, receiving asset information from the aggregators specifying the available assets and relevant information such as their types, locations, and rated power

• In step 208, receiving grid constraints from the grid operator, e.g. in the form of a network model of the grid

In the second stage (step 210) the DR coordinator optimizes across the DR capacity offered by the different aggregators to identify a particular asset configuration (i.e. a specific set of assets) for the DR service (using assets from one or more aggregators in accordance with the aggregators’ DR configuration options).

In the third stage (step 212), the selected assets are configured to implement the DR service.

Note that the examples herein are generally described in relation to an FCR service but the system may be applied to other types of demand response service (e.g. FRR and other balancing mechanisms). Furthermore, while generally discussed in terms of assets increasing energy demand (consumption), i.e. increasing energy flow to assets from the grid, the techniques are equally applicable to DR services involving increase in energy supply from the assets (i.e. increasing energy flow from assets to the grid), e.g. by increasing generation. A system implementing the DR coordinator is illustrated in overview in Figure 3. The system includes an electricity distribution network (referred to herein as the “grid”) 300. A number of assets 304 are available in the grid to provide demand response functionality. The assets are distributed across the grid and operated by multiple different aggregators 306, e.g. “Aggregator A” and “Aggregator B”. An aggregator may be any entity, e.g. a service provider company or other organisation, that is able to make energy assets available for used in an aggregated demand response service.

Each aggregator submits one or more DR configuration options, indicating sets of assets and associated demand response capabilities, to a DR coordinator 308. A DR configuration option represents an offer to provide a certain demand response capability using a certain set of assets. The DR coordinator 308 is a computer system running an optimisation module 310 for identifying DR configuration options that are suitable for meeting requirements of a demand response service that is to be configured. The DR coordinator also receives grid information including grid constraints from grid operators (e.g. distribution system operators, DSO), possibly along with other information such as demand forecasts, equipment deployment schedules etc.

The DR coordinator may operate under the control of another entity, which may or may not be separate from the DSO / grid operator and/or the aggregators.

The DR coordinator 308 evaluates the configuration options offered by the aggregators against grid constraints, in view of a required demand response service that is to be provided, and identifies which DR configuration options from which aggregators can fulfil the requirements within the grid constraints. The DR coordinator communicates with the aggregators to select and configure the necessary assets to implement the DR service. The aggregators then configure the selected assets for the DR service.

Figure 4 illustrates the process in more detail. In step 402, Aggregator A sends one or more DR configuration options to the DR coordinator. Aggregator B similarly sends its available DR options in step 404. In step 406, a requester (e.g. a system operator) sends a DR service request specifying a required DR service. In step 408, a grid operator sends grid constraint information (GC) for the distribution grid (or for the part of the grid under its control). Note that particular participating entities are shown purely for illustrative purposes and in practice there may be any number of entities taking part in the coordination scheme. For example, there may be any number of aggregators providing DR-capable assets, any number of requesting SOs requesting flexibility / DR services, and any number of grid operators providing grid constraints pertaining to different parts of the grid. It should further be noted that the order in which the information is supplied to the DR coordinator may differ from that shown.

In step 410, the DR coordinator performs a search and optimization process to identify an aggregation configuration (specifying a set of assets to use) that meets the grid constraints received from the grid operator and the requirements of the DR service request. In step 412 the aggregators are then notified of the outcome. Specifically, each aggregator is informed as to which (if any) offered DR configuration options have been selected, and which specific assets of those made available by an aggregator are to be used in providing the DR service. The requester and grid operator may also be informed of the aggregation configuration chosen by the DR coordinator in this step.

In step 414, 416, each aggregator then configures its portfolio of assets to implement the aggregator’s contribution to the DR service as specified by the asset configuration found by the DR coordinator.

DR configuration options

Each participating aggregator provides to the DR coordinator one or more DR configuration options to define the DR capabilities the aggregator can offer.

Each DR configuration option indicates how much power can be offered as a function of the number of assets (possibly of different types). The information included in each DR configuration option may include one or more of:

• DR capacity, typically power (e.g. specified in MW), the aggregator is able to provide for a specific DR service such as FCR / FRR/ balancing mechanism. Note this could be a power consumption capacity (e.g. via battery storage or other demand increase) or a power supply capacity (e.g. via charged battery reserves or generator capacity), depending on the nature of the DR service

• asset selection criteria defining the assets needed to provide the specified DR capacity, e.g. specifying numbers of assets of one or more particular asset types (where multiple asset types are involved, a number of each asset type may be specified separately)

• performance and/or cost characteristics associated with providing the specified DR capacity using the corresponding selection of assets

DR implementation by the DR coordinator may be based on the capacity and asset selection criteria, or alternatively, performance and/or cost characteristics may be used as an additional optimisation criterion. Cost may refer to financial cost, e.g. a cost charged by the aggregator to the DR implementer, and this could include a price for availability (e.g. €/MW/h) and/or a utilization price (e.g. €/MWh). Performance characteristics may relate to the impact or efficiency of a particular asset selection, e.g. a metric indicative of environmental impact could be used. Such a metric may be indicative of carbon emissions, NOx emissions and/or emissions of other harmful substances, non-renewable fuel consumption (e.g. for petrol generators) and the like. This allows the DR coordinator to search for asset configurations that achieve a desired DR service whilst minimising or reducing environmental impact.

It is up to the aggregator to offer one or more DR configuration options that they believe they can match technically taking into account uncertainty and technical limitations of assets.

In a typical scenario, an aggregator will not just offer one DR configuration option but a set of alternative DR options. The DR coordinator can then select a particular one of these if it meets the service requirements and grid constraints.

Table 1 illustrates an example of a set of DR configuration options offered by an aggregator.

Table 1

Here “PBid” indicates the total amount of DR capacity offered (measured here as electrical power, in MW), and price indicates a cost (in this case cost for availability but a utilisation cost may also be specified). The final two rows indicate the numbers of assets of two different types Type A and Type B required to provide the total capacity. These could be assets with complementary performance characteristics, e.g. slow and fast assets, as in the various examples previously described. Purely by way of example, Type A could be hot water heaters and Type B could be residential batteries.

The specified asset numbers indicate the numbers of assets of each type that need to be selected by the DR coordinator in order for the particular configuration option to be chosen. As mentioned above, these asset numbers typically do not scale linearly with total DR capacity, leading to potential efficiencies at higher capacities.

The DR configuration options may be manually configured by an operator, e.g. based on knowledge of the available assets and their characteristics. However, in preferred embodiments, the DR configuration options may be determined based on data (e.g. performance data) obtained from the assets, under guidance of an operator or even automatically.

In this approach, each aggregator collects information on available assets and determines the DR configuration options it can offer. To do so, the aggregator calculates how much flexibility it can offer for the DR service with a certain degree of certainty (e.g. meeting a specified certainty measure the aggregator is confident can be achieved, e.g. 99.9999%). To evaluate this, the aggregator establishes the set of available assets in its pool and their availability, and possibly also other performance characteristics (e.g. response timings), to calculate how much power can be offered to the transmission system operator. This information may be known from measured or rated performance of available assets, and/or based on prior explicit configuration. In one approach, asset performance may be simulated and asset aggregations may be evaluated, as described in co-pending UK patent application no. 1915518.3, which is incorporated herein by reference.

Such an algorithm may use a data-calibrated mathematical model obtained from recent data collected from all assets (e.g. using a neural network that forecasts the availability of the asset). To ensure accuracy, evaluation of available assets may be performed a short time (e.g. 5 minutes) before the DR configuration options are sent to the DR coordinator. This may involve obtaining recent data from assets to update a model of the assets and using a VPP (virtual power plant) algorithm to calculate the power that can safely be offered as a function of the number of assets participating, in this case specifically low/medium voltage connected assets such as hot water heaters, residential batteries, etc.

The output of this calculation is a set of DR configuration options as indicated by way of example in the table above.

As indicated by the example in the table, the capacity that can be offered as function of the number of assets is not necessarily a linear curve but typically depends on the availability, pool configuration, etc. Table 1 above provides an example but it should be understood that the actual relationship between capacity and number of assets may follow a different pattern to that illustrated.

In preferred embodiments, the configuration options are calculated dynamically based upon the most recent data observed (e.g. performance and availability data for available assets). The DR coordinator may set a submission time by which DR configurations options need to be received, in which case calculation of the configuration options at each aggregator may be timed so that up-to-date information is available in time to be submitted. The DR coordinator may rerun the optimization process periodically, based on periodically updated DR configuration options submitted by the aggregators. The repeat interval may be as low as a few minutes (or even shorter if required) or up to a few days, depending on the configuration.

In addition to the DR configuration options, each aggregator also provides information about the assets being made available, including the locations of the assets. This information is used by the DR coordinator to check possible asset selections against grid constraints as discussed in more detail below. Other asset information such as asset identifiers, asset types and performance characteristics may also be provided.

Grid constraints

Grid constraints are typically determined by the relevant grid operator (e.g. DSO). This is the system operator responsible for the secure operation of the grid to which the DR-capable assets are connected. The system operator supplies the constraint information to the DR coordinator. The constraints limit how the DR-capable assets can be used (in aggregate) to provide a DR service.

Grid constraints may be specified by way of a grid model. A variety of grid representations may be used for this model, of which the following are examples:

• Detailed physical / topological representation: This is a detailed topological model (e.g. connection graph) of the grid, that allows accurate calculation of the currents and voltages in a grid as a function of active and reactive power injected/consumed at different grid connection points. The model provides a set of constraints on these current/voltages etc. For example, the model may comprise a connection graph with impedance values for each edge.

• Simplified topological representation of the grid: A simplified grid representation may use a connection tree/graph with different power ratings for each node defining corresponding constraints. This may typically be a linearization of the detailed model described above. • Geographical grid representation: In this approach, the grid constraints are expressed in relation to geographical locations of assets (e.g. as local/regional constraints) without explicit topological modelling of the network.

Figure 5 illustrates an example of a simplified topological model specifying grid constraints as power ratings at each node. The rating for a node indicates that the sum of all active power underneath the node needs to remain within the specified power rating, (e.g. expressed as x kW/MW). The Figure 5 example shows two transformer network nodes 502 and 504 (e.g. electricity substations), along with a street-level connection point 506. The total consumption downstream of transformer 502 is shown as limited to a total of 3 MW, the consumption downstream of transformer 504 is limited to 2MW, and the total consumption below connection point 506 is limited to 1MW.

Street-level connection point 506 provides a branching point for connection to e.g. residential / commercial properties, which may provide a range of DR-capable assets (“A”), such as residential batteries. These may not be represented explicitly in the model, but a total supply constraint of 1MW applies to all of those assets and other consumers in that part of the grid. Here it is assumed that the constraint applies to the total consumption, including regular consumption (e.g. by non-DR assets) as well as additional consumption by DR assets during DR events. Thus, if the total energy flows including regular/expected baseline consumption through a grid location and the total DR capacity of all available DR-capable assets connected at that location of the grid exceeds the 1MW limit, then the constraint would be violated (and grid failure could occur if all assets were activated simultaneously to implement DR).

Note that these examples assume a DR service involving increasing energy consumption on the grid (by activating inactive assets, or increasing power draw by already active assets), and the constraints specify limits on downstream power flow. However, the constraint model may also be adapted to deal with DR response involving on-demand reduction in consumption, or on-demand power generation (resulting in increased energy flow into the grid). As mentioned previously, the aggregator provides asset location information together with the offered DR configuration options. The location information is specified in relation to the network model used, to enable the DR coordinator to evaluate the constraints. Thus, in an example using a topological model, the location of each asset is preferably specified in relation to the network topology of the network model, by specifying the connection point (e.g. bus/node) in the model at which (or below which) the asset is connected. In this example, assets “A” would be identified as connected at connection point 506 (irrespective of any topological details between the connection point and assets that are not represented in the model). This allows the DR coordinator to relate the potential DR capacity provided by each asset to the grid constraint applicable at the grid location of the asset.

As mentioned above, the evaluation of potential DR capacity activation against grid constraints should preferably take account of the baseline energy flows in the grid. This information can be obtained in a number of ways. In one approach, the DSO that calculates the grid constraints uses local smart meters to measure energy flow in the grid in order to forecast the baseload. To provide a more accurate forecast, DR activations may be subtracted from the measured flows. Alternatively or additionally, the aggregators can provide a forecast of the baseline that is extrapolated to the assets not participating in the DR coordination (e.g. lights, domestic appliances such as televisions etc.)

To account for baseload in constraint evaluation, the expected baseload can be subtracted from the actual grid constraints to compute the final constraints applicable to DR activations, with DR capacities for particular assets evaluated against those adjusted constraints (e.g. if at a network location there is a headroom of 2 MW physically with 1 MW of baseload, only 1 MW remains available for the DR service configured by the DR coordinator). The following discussion assumes that the constraints have been determined accounting for expected baseload and are thus specific to DR capacity. However, alternatively, the DR capacities of the assets can be added to the baseload to determine total consumption which could then be evaluated against the unadjusted grid constraints. Thus, to evaluate a possible DR asset configuration involving a particular set of assets, the system sums the DR capacity of the assets in each grid region governed by a constraint and compares this to the constraint applicable for the grid region (after accounting for expected baseload). Compliance is determined if the total capacity of the particular set of assets does not exceed the constraint; otherwise a constraint violation is identified.

As an alternative, a geographical constraint model is illustrated in Figure 6. The model is based on constraints that are determined based on geographical locations of assets and distances between assets. This approach allows constraints to be specified in a way which approximates the real situation but which does not require a detailed topological network model.

For example, in Belgium a circle rule is applied, dictating that in each circle with a radius of 100 meters only 10 assets can be activated with a max power of 5 kW each. In an alternative approach (or additionally), a total power limit for the circular area could be specified. Generalising that approach, the parameters of the constraints (circle radius, maximum number of assets, capacity limit per asset and/or per circular region etc.) could be made to vary based on the characteristics of the grid, operating requirements etc. and may be dynamic (e.g. varying spatially and/or temporally). For example, the constraint parameters could be different in different regions of the grid or at different times.

As a further variation, the constraints could combine geographical constraints and topology-based (network model based) constraints.

To apply the constraints to a given set of assets (selected from one or more aggregators), the DR coordinator calculates all circles in scope of the corresponding size (i.e. all circles containing assets made available for the DR service by the aggregators) and compares the number of assets, individual capacity, and/or total asset capacity of selected assets to the DR constraints (e.g. max kW/circle) to determine whether the constraints are violated in any geographical area. A technique for computing the circles for which constraints are evaluated can be found in J Engels et al. “Grid-Constrained Distributed Optimization for Frequency Control with Low- Voltage Flexibility”, arXiv:1903.04282vl, which is incorporated herein by reference in its entirety.

Figure 6 depicts a geographical region with assets of two aggregators marked. Circles depict regions of potential selected assets to be evaluated against constraints. Assets of two different types are shown with “plus” and “box” symbols respectively. Assets are associated with two different aggregators, distinguished by solid and dashed lines respectively. Assets outside circles are out of scope, i.e. not being considered in the current evaluation (e.g. because they were not included in the relevant DR configuration options being evaluated).

To calculate the network representation and the corresponding constraints, the system operator can use a static approach based on their understanding of the grid configuration and forecasts of static local load and production that is not in scope of the coordination mechanism (e.g. regular consumption from household appliances etc.) Alternatively, a system operator could use dynamically measured energy flow data (consumption and supply), using the most recent observations from the grid to calibrate a model of the grid.

In the geographical model (e.g. based on a circle rule) asset locations are specified geographically (rather than topologically as in the previous example), for example by being specified as longitude/latitude coordinates.

Regardless of the representation used, the model of the grid and associated constraints may be recomputed and updated periodically and/or in response to grid configuration changes, e.g. addition/removal/upgrade of assets, connections, grid equipment (e.g. transformers/substations) etc. The DR coordinator requires the network/constraint model before computing the final asset configuration, though this can be received after the submission of the DR configuration options from the aggregator, allowing an updated model based on most recently measured grid performance data to be used. Operation of the DR coordinator

The DR coordinator analyses the DR configuration options supplied by the aggregators, and the grid model and constraints supplied by the system operators, to determine an asset configuration - i.e. a specific set of selected assets - that meets both the requirements of the DR service to be provided and the grid constraints.

In a preferred embodiment, this is implemented using an optimization algorithm that seeks to maximize an objective within the grid constraints. This objective may, for example, be based on the total volume that can be offered (e.g. expressed as total DR capacity in MW) or alternatively cost (financial or other) may be considered (e.g. the objective may be based on price x volume). As an example of a non-fmancial cost measure, optimisation may be based (at least partially) on an environmental impact measure, such as an emissions measure (e.g. emissions of carbon, NOx and/or other substances).

In a preferred embodiment, the objective for the optimization algorithm is to identify, for a required total DR capacity, the lowest cost solution for delivering that capacity (within grid constraints).

The algorithm effectively solves a numerical optimization problem where different solutions can be pruned to find an acceptable result, and allows determination of a selection of assets from various aggregators that enables the optimal use of the grid within its operational constraints.

The optimization identifies specific assets to be used for the DR service from the assets made available by the aggregators not only within the grid constraints but also complying with the asset selection criteria specified in the DR configuration options. As described above, each DR configuration option specifies numbers and types of assets that the DR coordinator should select (from that aggregator’s available pool) to obtain a certain DR capacity from the aggregator (and this may be further broken down into different asset types). Thus, the output of the optimization includes: • a selection of one or more DR configuration options from one or more of the aggregators

• for each selected DR configuration option, an indication of the specific assets of that aggregator that should be used to implement the DR configuration option.

The assets selected match the asset selection criteria, specifically the asset numbers (possibly of various types), specified in the DR configuration option. Thus, when choosing a DR configuration option requiring 100 Type A assets and 50 Type B assets to achieve a given DR capacity, the DR coordinator identifies that exact number of assets of each type from that aggregator’s pool for use in the DR service, as required by the DR configuration option. However, those assets may be selected from a larger pool of assets made available by the aggregator, with the specific asset selection being guided by the optimization process, which searches for an overall solution (across all aggregators’ asset pools) that complies with grid constraints.

By specifying not only the selected DR configuration options for different aggregators, but also the specific assets, the system thereby ensures compliance with the grid constraints (e.g. avoiding overloading the grid in a particular area through simultaneous activation of multiple DR assets).

Purely as a simplified example, when seeking to implement a 3 MW DR service, there may be various combinations of DR configuration options available to the DR coordinator, such as

• A 2MW option from Aggregator A and a 1 MW option from Aggregator B

• A lMW option from Aggregator A and a 2MW option from Aggregator B

• lMW options from each of Aggregators A, B, C

• etc.

Which option is chosen will depend on the locations of the different aggregators’ assets, the grid constraints at those locations, how many assets need to be selected, etc. For example, DR configuration options from two aggregators whose assets are located in different areas of the grid may be less likely to violate constraints when selected together (and thus may be more likely to be chosen) than DR options of aggregators whose assets are all in the same region.

Where there are multiple possible solutions the optimization algorithm may additionally optimize in relation to criteria other than constraint compliance, such as environmental performance, cost etc.

Various implementations of the optimization algorithm are possible. For example, a branch and bound solver may be used.

One particular example algorithm is described below, with reference to Figure 7A.

The algorithm seeks to find the lowest cost solution for a certain required total DR capacity whilst meeting grid constraints. Any appropriate cost metric may be used to control the search, including performance, environmental, financial, or a combination. The process starts in step 702 with obtaining the required information, such as

• the DR configuration options offered by the aggregators and associated cost information;

• asset types and locations of assets made available by the aggregators;

• grid constraints.

In step 704, a tree structure representing a possible solution is defined in which each node represents an asset and whether this is to be used in the solution (e.g. as a binary yes/no indication).

The tree is then built, beginning at a starting location (which may be selected randomly or in any other appropriate way). This involves, at each step, identifying an asset that can be added without violating the network constraints (step 706) and growing the tree by adding the selected asset as a new node (step 708).

Growing of the tree is repeated until a feasible solution is found (test 710). A feasible solution is one that meets the relevant requirements, such as achieving the required total DR capacity and meeting any asset selection criteria specified by the aggregators in the configuration options.

As the search (706-710) progresses, if a feasible solution cannot be found within applicable constraints, or if it becomes clear that the current solution will not be able to improve on the best solution previously found (e.g. because the cost of the current solution already exceeds the cost of the previous best solution), the search backtracks to an earlier node in the tree structure and tries an alternative solution by making different asset selection decisions, thus creating new branches in the tree (note the algorithm may simply backtrack up one level in the tree, or alternatively more complex criteria may determine backtracking behavior). Thus, each path in the resulting tree starting at the root and leading to a leaf represents a set of assets considered for the current solution, with each node corresponding to a new asset added to the solution. Note that instead of adding a single asset at a time, a set of multiple new assets can be added in a single step to form a node in the tree. Search continues in this way (backtracking as needed to try alternative solutions) until a feasible solution is found.

In the decision logic that decides which assets are added to the tree (in the current branch), in addition to the network constraints, the asset selection criteria encoded in the DR configuration options are preferably also considered. For example, if the criteria for a given DR configuration option are not yet met (e.g. a particular number of assets of a particular type required to be selected from a particular aggregator), then assets are chosen to be added accordingly. The asset selection criteria thus represent an additional constraint in the search, in addition to the network constraints.

In step 712, the process determines whether to search for an additional solution. If yes, then the process 704-710 is repeated, but with the added the constraint (714) that the next solution is required to be lower cost than the best solution found so far. Thus, if during the growing of the tree (loop 706-710) the solution becomes more expensive than the best found so far, the process backtracks to search for an alternative solution.

If in step 712 it is determined that the search for additional solutions should not be repeated, the process ends, and the best (lowest cost) solution identified so far is provided as the output of the optimizer. The determination at 712 may be based e.g. on computational budget, with the search repeated until the computational budget is spent. For example, this could be a maximum compute time, or maximum number of iterations. Other termination criteria could alternatively be used; for example, the search could be terminated once the cost of the lowest-cost solution falls below some threshold, or if there is no reduction (or only minimal reduction) in cost over a given number of iterations. The process also halts if during any iteration the system is unable to identify any additional feasible solution.

Other approaches to optimization could be employed. For example, one approach could involve generating one or more initial asset configurations (e.g. randomly, based on the configuration options and/or total required capacity) and iteratively refining these in a search process in accordance with grid constraints (e.g. by making adjustments to asset selections that result in constraint violations).

The output of the optimization stage is one particular asset configuration, specifying a set of assets of one or more aggregators that together are able to provide the required DR service at the required service level (e.g. total power capacity) whilst complying with the aggregator’s asset selection criteria and the grid constraints.

Asset capacity from aggregators may be provided over a large geographical area, even a whole country. But merging all information in one optimization problem may become computationally challenging. Furthermore it may not always be realistic to assume all system providers will share their grid information, nor will they have the same representation of their grid. In some embodiments, the optimization problem is therefore decomposed into sub-problems, each representing a local grid region. Distributed optimization techniques can be applied where each local DR region solves its part of the problem and consensus between a set of regions is obtained by getting a consensus on coupling vectors such as the power flow through certain nodes. This then effectively results in a network of local DR markets. Deployment of the DR service

Once the DR coordinator has completed the optimization process and has identified the final asset configuration by selecting the DR configuration options and associated assets to be used, the process proceeds to the deployment stage. This involves transmission of a confirmation of the identified aggregation solution to the DR service requester, confirming that the request can be fulfilled and that a set of assets has been identified that can be used to provide the required service.

Additionally, the DR coordinator also sends relevant information to the aggregators whose assets are being used, identifying to each aggregator the configuration option(s) that were selected, and the specific assets chosen to implement those options.

Each aggregator can then provide the service to the system operator by using the assets that have been selected. To do so, the aggregator sends the necessary configuration information (e.g. set points/response curves) to the assets (or their associated asset controllers).

An example process performed by each aggregator is illustrated in Figure 7B.

In step 720, the aggregator receives from the DR coordinator a list of the assets selected by the DR coordinator that can be used by the aggregator to provide the DR service (i.e. those that can implement the required service without violating constraints). For delivery, the aggregator may typically not need to use all assets at any given time. Thus, in step 722 the aggregator checks the status of assets to determine availability and selects assets that are available to provide the required DR capacity. For example, where the aggregator needs n assets to deliver the DR service and has m (>«) assets allocated by the coordinator (e.g. based on the understanding that up to m-n assets can become unavailable), during delivery the aggregator will select n assets from the m allocated assets (step 724). Typically, the aggregator chooses the assets that are available at the time the DR service is activated; in case more assets are available than required (e.g. if all assets are available), the aggregator may select based on any suitable criteria (e.g. reliability, operational cost etc.) In step 726, the aggregator then determines the control actions for each selected asset and controls the asset accordingly to implement the DR service.

In a variation of the above approach, the coordinator sends back to the aggregator a set of assets with specific constraints restricting the aggregator’s options when choosing the assets to be used, such as:

• you can use assets 1-2-3-4-5-6-7-8-9-10 to deliver the service (only 8 are needed);

• but out of assets 1-2-3 you can only activate two at any given moment

In this case, when delivering the service, the aggregator will select any combination in the configured set without violating the constraint s) imposed by the DR coordinator. Again, where the aggregator has freedom to select assets, availability and cost can be used to guide the selection.

Control of the assets may occur directly or via an intermediate asset control system (e.g. controller 102 of Figures 1A/1B). Control may use any appropriate control method including those based on the Figure 1A-1C processes and may e.g. involve sending set points or response curves to the assets. Once configured, the assets then operate in accordance with the configured DR service, e.g. by responding to frequency fluctuations detected locally or centrally, based on central control or locally configured set points / response functions.

In addition, each aggregator rearranges their total pool of assets to reserve selected assets for the DR service being configured. Other assets may remain available and can be offered as part of future DR configuration options submitted to the DR coordinator, for example when servicing future DR service requests.

Computer system implementation

Figure 8 illustrates the hardware and software architecture of components of the described system, in an example embodiment. A central server 800 is provided to act as the DR coordinator 308 for performing the described optimisation process to identify a configuration of assets for implementing a DR service. The server includes one or more processors 802 together with volatile / random access memory 804 for storing temporary data and software code being executed.

A network interface 806 (e.g. a wired or wireless interface) is provided for communication with other system components including the asset management systems 816 of the aggregators (for obtaining DR configuration options and asset information) and grid management systems 818 of the grid operators (for obtaining grid models and constraints) over one or more communications networks 814, which may include e.g. Local and/or Wide Area Networks, including the Internet.

Persistent storage 808 (e.g. in the form of hard disk storage, optical storage and the like) persistently stores software for performing described functions, including a coordinator module 810 for performing the DR coordinator function, including the optimisation algorithm for finding an asset configuration. The persistent storage additionally stores the information 812 used by the optimisation algorithm, such as the DR configuration options received from the aggregators and the grid models and constraints received from the grid operators. The persistent storage also includes other server software and data (not shown), such as a server operating system.

The server will include other conventional hardware and software components as known to those skilled in the art, and the components are interconnected by one or more buses (such as memory and I/O buses).

While a specific architecture is shown by way of example, any appropriate hardware/software architecture may be employed.

Furthermore, functional components indicated as separate may be combined and vice versa. For example, the functions of server 800 may in practice be implemented by multiple separate server devices (e.g. a server cluster). In another example, the functions of the central server could be integrated into another component, such as a grid operator’s grid management system. It will be understood that the present invention has been described above purely by way of example, and modification of detail can be made within the scope of the invention.