Large scale UK power cuts

[scotia]

27/14/19

eh ?

Now I wonder what would happen if such a careless mis-type went out in a standards document.
And just in case there is anyone out there who is still struggling to make a diary entry at my published date, I think I should say that the relevant date I intended to display was 27th April 2019.

[sunnyjoe]

The best summary for the layman I have seen so far
https://energyfutureslab.blog/2019/08/2 ... ts-go-out/

[scotia]

The best summary for the layman I have seen so far
https://energyfutureslab.blog/2019/08/2 ... ts-go-out/

Thanks for the link - its certainly the clearest explanation I have seen.
Looking at the conclusions - Section 4 states that there will be technical lessons to be learned at Hornsea and Little Barford.
Hornsea have confessed to their fault, and apparently rectified it - but it was discovered in exceptional circumstances. I wonder how many other generation plants have hidden bugs which don't show up - except in exceptional circumstances. I recollect that a novel governor that I was testing failed on a full load reject - having worked satisfactorily in incremental steps up to (but not including!) the most extreme (and highly unusual) operating condition.
At Little Barford the frequency trips on the gas turbines seem to have been fooled by transients. Is this also a feature at gas turbines installed at other gas-fired power stations? Will there need to be a re-think of the trips at all such stations?.
And as proposed in section 8 of the conclusions - yes! False "Loss of Mains" prediction based on a rate of change in frequency on a disturbed waveform definitely needs attention. We should not casually expect several hundred MW of embedded generation to needlessly drop out in such a situation.
In section 8 of the proposals, it is suggested that there should be a public discussion on additional bills for holding additional reserve. I don't think this will work - there will simply be a public demand that the system never fails. (particularly if you were stuck on a train for many hours - even although it was not NG's fault!)

[sunnyjoe]

Hornsea have confessed to their fault, and apparently rectified it - but it was discovered in exceptional circumstances. I wonder how many other generation plants have hidden bugs which don't show up - except in exceptional circumstances. I recollect that a novel governor that I was testing failed on a full load reject - having worked satisfactorily in incremental steps up to (but not including!) the most extreme (and highly unusual) operating condition.

Let's not forget that Hornsea 1 is still under construction. Many generators behave in unexpected ways during or shortly after commissioning.

[dspp]

That's clearly an update to the previous Imperial post, written after the prelim NG report came out.

He is making the assumption that the embedded only dropped out due to RoCoF protections firing. The data does not exist in the public domain to support that, though I am not saying I am entirely disagreeing as it is the most likely hypothesis for most of the embedded dropouts. What is ironic about this is that some DNOs used to forcefully preference engineer and insist on RoCoF (by way of insisting on G59 even where non-RoCoF G83 devices would have sufficed).

There will be more good stuff to come. You can see that from the way the NG senior people were picking their words with exquisite care in the very first interviews. Ofgem ordinarily does not have the balls to go after even obvious misdemeanor, and ordinarily wouldn't make a decision except to fight its way out of a soggy cardboard box to get at its lunch packet, but on this occasion maybe they will be prodded into action by fear of loss of job(s). We will see.

regards, dspp

[sunnyjoe]

He is making the assumption that the embedded only dropped out due to RoCoF protections firing. The data does not exist in the public domain to support that, though I am not saying I am entirely disagreeing as it is the most likely hypothesis for most of the embedded dropouts. What is ironic about this is that some DNOs used to forcefully preference engineer and insist on RoCoF (by way of insisting on G59 even where non-RoCoF G83 devices would have sufficed).

I disagree.

Prof Green says "This voltage disturbance rippled out across the system resulting in sudden shift in angle of the voltage (the starting point of the AC voltage cycle measured against a reference point). That matters because “distributed” generators, like small wind and solar plant, use this as one way to detect “loss of mains” and about 500 MW of these small generators detected this as problem and disconnected creating the third loss." This is a reference to vector shift protection, not RoCoF. VS is known to be vulnerable to transmission switching and NG has banned its use in new installations and required that existing examples are replaced by other protection by 2022.

He also refers to RoCoF of 0.16Hz/s measured at the start of the incident, which is higher than the 0.125Hz/s trip setting historically used by many embedded generators, but without saying that this was a contributory factor in the 500MW of embedded generator trips. I believe it will have played some part in this.

[dspp]

He is making the assumption that the embedded only dropped out due to RoCoF protections firing. The data does not exist in the public domain to support that, though I am not saying I am entirely disagreeing as it is the most likely hypothesis for most of the embedded dropouts. What is ironic about this is that some DNOs used to forcefully preference engineer and insist on RoCoF (by way of insisting on G59 even where non-RoCoF G83 devices would have sufficed).

I disagree.

Prof Green says "This voltage disturbance rippled out across the system resulting in sudden shift in angle of the voltage (the starting point of the AC voltage cycle measured against a reference point). That matters because “distributed” generators, like small wind and solar plant, use this as one way to detect “loss of mains” and about 500 MW of these small generators detected this as problem and disconnected creating the third loss." This is a reference to vector shift protection, not RoCoF. VS is known to be vulnerable to transmission switching and NG has banned its use in new installations and required that existing examples are replaced by other protection by 2022.

He also refers to RoCoF of 0.16Hz/s measured at the start of the incident, which is higher than the 0.125Hz/s trip setting historically used by many embedded generators, but without saying that this was a contributory factor in the 500MW of embedded generator trips. I believe it will have played some part in this.

Fair points sunnyjoe. Hopefully the full report will give us more insight.

regards, dspp

[scotia]

So was it rocof or VS that was the villain in the disconnection of embedded generation? Prof Green seems to think that VS was the more serious candidate - but is there any on-line data (from scada systems?) that supports this? The displayed frequency curve is plotted to a scale that makes a determination of the maximum df/dt near impossible - but looking over it to the first bottom (after 20s), there seems to be a drop of about 1Hz - an average of 0.05Hz/s. Now the initial gradient is much steeper than the final gradient, so I was guessing that it could be up to 5 times this. But Prof Green presumably has a better source - he quotes 0.16Hz/s - which as dspp as said, would operate a lot of rocof. So even if VS is banned on new installations, higher values of rocof will also be required - and I suspect such settings will be beyond the range of many existing installations..
Apologies to all Snug participants - here we have three geeks sitting in a corner discussing obscure engineering points. However if any of you got stuck in a train for hours on end with no facilities, then maybe you feel we should ensure that it won't happen again - and you'll allow our wrangling to continue.

[jfgw]

Apologies to all Snug participants - here we have three geeks sitting in a corner discussing obscure engineering points.

I have been following this thread with absolute fascination, although I may have to read through it all again to fully understand it.

Julian F. G. W.

[Itsallaguess]

Apologies to all Snug participants - here we have three geeks sitting in a corner discussing obscure engineering points.

I have been following this thread with absolute fascination, although I may have to read through it all again to fully understand it.

You're not the only one Julian - I've also enjoyed having the company of others with much more experience and knowledge in this area, especially regarding such a rare but important incident.

You crack on lads - we're all ears....

Cheers,

Itsallaguess

[modellingman]

Apologies to all Snug participants - here we have three geeks sitting in a corner discussing obscure engineering points.

I have been following this thread with absolute fascination, although I may have to read through it all again to fully understand it.

Julian F. G. W.

Moi aussi.

[UncleEbenezer]

Apologies to all Snug participants - here we have three geeks sitting in a corner discussing obscure engineering points.

I have been following this thread with absolute fascination, although I may have to read through it all again to fully understand it.

Julian F. G. W.

Exactly. I'd much rather read something of substance that's a bit out of my depth than tedious trivia. On a topical issue like this, it's a privilege to be in the presence of folks with subject expertise.

[sunnyjoe]

So was it rocof or VS that was the villain in the disconnection of embedded generation? Prof Green seems to think that VS was the more serious candidate - but is there any on-line data (from scada systems?) that supports this?

The operators of those generators might have SCADA data or at least records of protection relay operation, but National Grid and the DNOs don't have access to this.

The displayed frequency curve is plotted to a scale that makes a determination of the maximum df/dt near impossible - but looking over it to the first bottom (after 20s), there seems to be a drop of about 1Hz - an average of 0.05Hz/s. Now the initial gradient is much steeper than the final gradient, so I was guessing that it could be up to 5 times this. But Prof Green presumably has a better source - he quotes 0.16Hz/s - which as dspp as said, would operate a lot of rocof. So even if VS is banned on new installations, higher values of rocof will also be required - and I suspect such settings will be beyond the range of many existing installations.

There is an ongoing project (started many years ago) to change RoCoF protection settings to 1Hz/s with a 500ms delay (0.5Hz/s for a minority of small synchronous generators). This started with the biggest embedded generators, but is now rolling out to all generators with G59/G99 protection. This should allow NG to operate the system with looser restrictions on RoCoF. At present they try to keep it at <0.1Hz/s but on completion of the RoCoF protection changes they could go to <0.3Hz/s and this will save a lot of money.

Recently VS removal was added to this project after NG was surprised to find that VS sometimes operated due to transmission switching events. Very undesirable.

More recently still the G59 first stage of over frequency trip at 50.5 Hz should also be disabled.

All changes should be complete by 31/8/22.

NG and the DNOs are putting together a scheme to pay some of the generators' costs for making relay setting adjustments or relay replacements. Details to be announced soon.

[scotia]

There is an ongoing project (started many years ago) to change RoCoF protection settings to 1Hz/s with a 500ms delay (0.5Hz/s for a minority of small synchronous generators). This started with the biggest embedded generators, but is now rolling out to all generators with G59/G99 protection. This should allow NG to operate the system with looser restrictions on RoCoF. At present they try to keep it at <0.1Hz/s but on completion of the RoCoF protection changes they could go to <0.3Hz/s and this will save a lot of money.
Recently VS removal was added to this project after NG was surprised to find that VS sometimes operated due to transmission switching events. Very undesirable.
More recently still the G59 first stage of over frequency trip at 50.5 Hz should also be disabled.
All changes should be complete by 31/8/22.

Many thanks for providing this clear update. I have been reading up on the subject, and have been intrigued by the debate as to how the time delay needs to be calculated, and the possible instability of the ROCOF technique employed in certain currently installed equipment when there is a significant vector shift. Hence the safety margin (to avoid unnecessary trips) of allowing the operation of the grid (only) up to 0.3Hz/s - and not to the full 1Hz/s.
The management of the Grid is certainly a lot more complex than it was back in my time when embedded generation didn't exist.

[dspp]

As a slight aside you will have seen the calc I did to get an average of 5kW for the typical 'domestic' embedded generation in post viewtopic.php?f=29&t=18963&start=20 [#245968 Postby dspp » August 21st, 2019, 10:29 am]

That post did not go into the average size of the non-domestic solar farms. I have just had a bit of time to estimate that.

Given 13 GW of total solar, of which about 4.9 GW is small scale <50kW aka 'domestic', leaving about 8 GW of big stuff.

Using Ofgem's accredited generation station database at https://www.renewablesandchp.ofgem.gov. ... Category=0 we can see 923 solar installs totalling 5.8 GW . That is a reasonable proxy for the 8 GW total.

There are 923 installations on the list, so about 6.2 MW per installation. It would be fairly reasonable to put maintained SCADA to all those connecting back to NG ESO and the various DNOs. Provided of course that someone pays

If you go to the STA at https://www.solar-trade.org.uk/wp-conte ... 3.2019.pdf they have a reasonable concern about data fragmentation. There is a good FOI response at https://www.whatdotheyknow.com/request/ ... sthrough=1 which sets out the existing databases.

regards, dspp

[TheMotorcycleBoy]

Alas, I've not really had enough time to continue reading this thread. I'd only today made been aware (by this thread, so thanks), that it seems the incident was a consequence of lightning strikes.

Given this, it seems amazing that we have reliable OH transmissions of electricity at all. My mind boggles as to the effect of lightning on grid infrastructure, knowing from personal experience, back in the days of when we had our home broadband delivered on metal phone-lines, and how our BT HomeHub was destroyed by a lightning strikes in our vicinity.

Wondered about the effect of lightning on the TX lines and the python bodies. I'd first assumed that the atmospheric field would see the pylon as being tall and grounded as being the best target - presumably keeping the energy away from the phases. But I guess that at various points in the cycle of each phase, then those phase lines may themselves become "more attractive routes to ground" for the wild sparks. I did a little googling, in a light hearted attempt to find answers (i.e. what gets struck, the pythons or phases). I didn't quite find the answer, and I'm a little too busy to continue searching, but did find a short Quora post discussing some of the outcomes of such an event:

https://www.quora.com/What-happens-if-l ... ssion-line

Matt

[madhatter]

Wondered about the effect of lightning on the TX lines and the python bodies.

Apparently the pythons don’t care for it at all. Hate it, in fact.

[TheMotorcycleBoy]

Wondered about the effect of lightning on the TX lines and the python bodies.

Apparently the pythons don’t care for it at all. Hate it, in fact.

Arrghh!! Did I really misspell that?

EDIT: I do use the python programming language a tad at work......it must have been some kind of weird Freudian Slip.



So does the lightning go through the PYLONS or the transmission lines?

[dspp]

Wondered about the effect of lightning on the TX lines and the python bodies.

Apparently the pythons don’t care for it at all. Hate it, in fact.

Arrghh!! Did I really misspell that?

EDIT: I do use the python programming language a tad at work......it must have been some kind of weird Freudian Slip.



So does the lightning go through the PYLONS or the transmission lines?

I depends where the hit is, and what route to earth it takes - it can do either. When it goes wrong bad things happen and I make more sales

- dspp

[scotia]

Lightning strikes followed by a protection breaker being opened, then by an automatic reclosure when any arc has been quenched is fairly common - but it can surprise the unwary. Many years ago I was carrying out tests on a grid connected 20MW hydro turbine up a remote glen in mid winter. I had a young assistant, whom I was watching with an eagle eye. The tests were successfully completed, and I ensured that my equipment was disconnected from the turbine, which had been closed down. I then instructed my assistant to back up the logged data, and I now was sufficiently relaxed to chat to the plant operators, when there was a bang, and the lights went out. I screamed the name of my assistant, but barely had the echo died down when the lights came back on - it had been a lightning strike on the transmission line from the power station. My assistant often cast it up to me - "you thought I was to blame - you didn't trust me!". I should also add that the lightning strike had no effect on the trains in Scotland, or England!