Impact of EnergyCollectives on grid operation EnergyCollective public event, June 1st, 2018 Oliver Gehrke Electrical Systems Operation and Management Center for Electric Power and Energy Technical University of Denmark
Handling grid impact What happens if a grid connected energy technology becomes too big to ignore? Textbook examples: Wind power in Denmark, PV in Germany Next to come: Electric vehicles, Energy collectives? penetration level "fit and forget" grid codes active control ignore regulate integrate
Handling grid impact What happens if a grid connected energy technology becomes too big to ignore? Textbook examples: Wind power in Denmark, PV in Germany Next to come: Electric vehicles, Energy collectives? penetration level "fit and forget" grid codes active control ignore regulate integrate
Impact on grid operation "What could possibly go wrong"? Local optimization in the EnergyCollective does not always have the same objectives as the energy system as a whole -> Higher overall effort in operating the energy system. Removing flexible resources from (public) markets for grid services -> Not enough flexibility available for infrastructure operators (TSO, DSO) Grid dimensioning does not take active coordination between consumers into account -> increased coincidence factor. Changed load/generation patterns -> difficulty predicting required capacity Customer billing is not per phase -> Balancing total kw may exacerbate the phase imbalance of the entire energy collective. Cybersecurity: Even if the application is secure, the infrastructure may still be vulnerable. Scenario: 10.000 EnergyCollectives taken over by botnet.
Grid services by energy collectives Imbalance mitigation: The EnergyCollective coordinates single- or two-phase production and consumption units in order to reduce the phase imbalance at the grid connection point. Congestion mitigation: The EnergyCollective (a) autonomously improves the coincidence factor by reducing consumption peaks, or (b) delivers "virtual capacity" to the DSO on request, e.g. through demand response. Volt/Var support: The EnergyCollective (a) autonomously supports the voltage at the connection point, or (b) delivers e.g. reactive power or load reduction upon request Frequency support: The EnergyCollective acts as an aggregator of flexible resources, e.g. to provide up- or downregulation services.
Multiple testing environments Field test "The real thing" with real users No flexibility in configuration, types of resources Limited scale Laboratory test Simulated user behaviour, realistic physical environment Flexibility in configuration, types of resources Limited scale Simulation study Simulated users and simplified physics High flexibility in configuration, types of resources Upscaling
Test environment: Field setup All houses have (plenty of) PV capacity, including the common house (almost 150kWp) Low energy houses with one central (shared) heat pump as backup. Star topology: All houses as well as the EV charging station are connected to the common house which serves as the point of common coupling Not representative for typical residential neighborhood grids Voltage issues etc. would be seen outside, rather than inside, of the network. "Reverse" congestion can be seen at the PCC in sunny, low-consumption situations.
Test environment: Field setup Not a large hardware budget and desire to be "minimally invasive" -> lightweight, reversible data collection setup. One intelligent node per building (embedded ARM, Linux) PV inverter communication through Modbus Meter readout through optical port (IEC 62056 mode C) Current generation of electricity meters only support 3-phase sum. Ongoing smart meter rollout by Radius Elnet -> optimistic that the coming meters will enable single phase readings.
Test environment: SYSLAB laboratory 16-busbar, 400V system with multiple connections to Risø's 10kV system Flexible topologies (up to 3km long feeder, radial network, meshed, islanded,...) 30+ energy resources (production, consumption, storage, vehicles) fully observable network (~2500 measurement channels, 1s resolution) very high degree of integrated automation (everything can be controlled from software)
Cosimulation environment Smart grid systems are multi-domain systems, but multi-domain simulation tools are not readily available. Simulation domains needed for EnergyCollective: At least electrical power system, trading system, heat domain, automation/control and (possibly) communication. Solution: Coupling of multiple domain specific simulators which exchange data in every simulation step (Cosimulation) Open-source platform developed in the H2020 ERIGrid project (with DTU CEE participation) using the FMI-CS standard and mosaik as an orchestrator. Required for EnergyCollective: Integration of PandaPower as an electrical power system simulator due to the need to simulate unbalanced 3-phase systems. Source: ERIGrid JRA2 cosimulation test
Field<->Lab Software platform on the EnergyCollective nodes is derived from DTU's laboratory software which has been running for 10+ years. Common software platform, data formats etc. allows for efficient exchange of e.g. control algorithms between the field and laboratory setups. Commonality greatly simplifies integrated experiments (e.g. "virtual energy collective" combining resources at Svalin and Risø).
Interaction with the DREM project EUDP project "DSO's role in the electricity market" (partner overlap: DTU and Radius) Models for resolution of future conflicts of interest between actors in the electricity sector: DSO, TSO, BRP, aggregators, asset owners Relevant to EnergyCollective: Service types, interaction models, EnergyCollectives as actors Traffic light approach in use in Belgium, Nederland, Germany, France, Italy in various forms. Also USEF approach. Loss of control. Black out Congestion managed by curtailment (cut off customers) Congestion managed by activation of flexibility assets. Market? Congestion managed by technical solutions (Step trafo, short-term overload, re-configuration of grid, battery) No congestion issues