Constraint Breaches History

## Introduction This dataset records all curtailment events experienced by curtailable-connection customers. ## About Curtailment When a generation customer requests a firm connection under a congested part of our network, there may be a requirement to reinforce the network to accommodate the connection. The reinforcement works take time to complete which increases the lead time to connect for the customer. Furthermore, the customer may need to contribute to the cost of the reinforcement works. UK Power Networks offers curtailable-connections as an alternative solution for our customers. It allows customers to connect to the distribution network as soon as possible rather than waiting, and potentially paying, for network reinforcement. This is possible because under a curtailable connection, the customer agrees that their access to the network can be controlled when congestion is high. These fast-tracked curtailable-connections can transition to firm connections once the reinforcement activity has taken place. Curtailable connections have enabled faster and cheaper connection of renewable energy generation to the distribution network owned and operated by UK Power Networks. The Distribution System Operator (DSO) team has developed the Distributed Energy Resource Management System (DERMS) that monitors curtailable-connection generators as well as associated constraints on the network. When a constraint reaches a critical threshold, an export access reduction signal may be sent to generators associated with that constraint so that the network can be kept safe, secure, and reliable. This dataset contains a record of curtailment actions we have taken and the resultant access reduction experienced by our curtailment-connections customers. Access reduction is calculated as the MW access reduction from maximum × duration of access reduction in hours (MW×h). The dataset categorises curtailment actions into 2 categories: * Constraint-driven curtailment: when a constraint is breached, we aggregate the access reduction of all customers associated with that constraint. A constraint breach occurs when the network load exceeds the safe limit. * * Non-constraint driven curtailment: this covers all curtailment which is not directly related to a constraint breach on the network. It includes customer comms failures, non-compliance trips (where the customer has not complied with a curtailment instruction), planned outages and unplanned outages Each row in the dataset details the start and end times, durations and customer access reduction associated with a curtailment actions. We also provide the associated grid supply point (GSP) and nominal voltage to provide greater aggregation capabilities. By virtue of being able to track curtailment across our network in granular detail, we have managed to significantly reduce curtailment of our curtailable-connections customers. ## Methodological Approach * A Remote Terminal Unit (RTU) is installed at each curtailable-connection site providing live telemetry data into the DERMS. It measures communications status, generator output and mode of operation. * RTUs are also installed at constraint locations (physical parts of the network, e.g., transformers, cables which may become overloaded under certain conditions). These are identified through planning power load studies. These RTUs monitor current at the constraint and communications status. * The DERMS design integrates network topology information. This maps constraints to associated curtailable connections under different network running conditions, including the sensitivity of the constraints to each curtailable connection. In general, a 1MW reduction in generation of a customer will cause <1MW reduction at the constraint. Each constraint is registered to a GSP. * DERMS monitors constraints against the associated breach limit. When a constraint limit is breached, DERMS calculates the amount of access reduction required from curtailable connections linked to the constraint to alleviate the breach. This calculation factors in the real-time level of generation of each customer and the sensitivity of the constraint to each generator. * Access reduction is issued to each curtailable-connection via the RTU until the constraint limit breach is mitigated. * Multiple constraints can apply to a curtailable-connection and constraint breaches can occur simultaneously. * Where multiple constraint breaches act upon a single curtailable-connection, we apportion the access reduction of that connection to the constraint breaches depending on the relative magnitude of the breaches. * Where customer curtailment occurs without any associated constraint breach, we categorise the curtailment as non-constraint driven. * Future developments will include the reason for non-constraint driven curtailment. ## Quality Control Statement The dataset is derived from data recorded by RTUs located at customer sites and constraint locations across our network. UKPN’s Ops Telecoms team monitors and maintains these RTUs to ensure they are providing accurate customer/network data. An alarms system notifies the team of communications failures which are attended to by our engineers as quickly as possible. RTUs can store telemetry data for prolonged periods during communications outages and then transmit data once communications are reinstated. These measures ensure we have a continuous stream of accurate data with minimal gaps. On the rare instances where there are issues with the raw data received from DERMS, we employ simple data cleaning algorithms such as forward filling. RTU measurements of access reduction update on change or every 30-mins in absence of change. We also minimise postprocessing of RTU data (e.g. we do not time average data). Using the raw data allows us to ascertain event start and end times of curtailment actions exactly and accurately determine access reductions experienced by our customers. ## Assurance Statement The dataset is generated and updated by a script which is scheduled to run daily. The script was developed by the DSO Data Science team in conjunction with the DSO Network Access team, the DSO Operations team and the UKPN Ops Telecoms team to ensure correct interpretation of the RTU data streams. The underlying script logic has been cross-referenced with the developers and maintainers of the DERMS scheme to ensure that the data reflects how DERMS operates. The outputs of the script were independently checked by the DSO Network Access team for accuracy of the curtailment event timings and access reduction prior to first publication on the Open Data Portal (ODP). The DSO Operations team conduct an ongoing review of the data as it is updated daily to verify that the operational expectations are reflected in the data. The Data Science team have implemented automated logging which notifies the team of any issues when the script runs. This allows the Data Science to investigate and debug any errors/warnings as soon as they happen. ## Other Download dataset information: [Metadata (JSON)] Definitions of key terms related to this dataset can be found in the Open Data Portal Glossary: [https://ukpowernetworks.opendatasoft.com/pages/glossary/] To view this data please register and login.