Measurements of power flow (Watts in export or import) are very crucial for Load Frequency Controller … wrong (i.e., “frozen”!) measurements have caused almost a big blackout in Europe in January 2019.
What happened: the measurement of power of the lines between two transmission systems (Germany – Austria) were frozen when the export value of 723 MW from Germany to Austria was measured (which was a result of 34 GW wind power generation in Germany). Later the wind power generation decreased to 4 GW … and the measurement (as input to the controller) many hours later still used the input value of 723 MW !!! In such a meshed power network it is unlikely that such a value is constant …
Oops … something went absolutely wrong!
Report by exception (on a value change as used for the above measurement) is great … as long as there are changes figured out and reported. A frozen value does not cause a change and thus no new value will be reported … No receiver should expect that the export power is constant (723 MW) for days!! The sensors may have worked fine … but the software and communication failed … on both sides (sender and receiver). A receiver should not trust that the software and communication is working fine all time.
Here are some measures to monitor the communication (by the receiver) to figure out if the communication is OK:
https://www.entsoe.eu/news/2019/05/28/entso-e-technical-report-on-the-january-2019-significant-frequency-deviations-in-continental-europe/
This reminds me on the Boeing 737 MAX disaster … maybe a programmer left the vendor of the load frequency controller and hired with Boeing … I am kidding.
How many programmer or people that configure power control systems and communication systems that lack experience with complex systems like a plane or a power system. Where are the “grey-hair” experts that would tell you in minutes how to … ? They may enjoy the beach with warm water and sun shine – relax and spend the pension for ...
It is not sufficient to have no ideas – one should also be unable to implement them.
I expect that more of these problems will hit the street once we have far more control, monitoring and communication in the smart(er) grids of medium and low voltage. Note that the problem in January 2019 occurred at transmission level!! … where more resources (higher budgets) are available (in the past).
Have a great weekend – with power.
What happened: the measurement of power of the lines between two transmission systems (Germany – Austria) were frozen when the export value of 723 MW from Germany to Austria was measured (which was a result of 34 GW wind power generation in Germany). Later the wind power generation decreased to 4 GW … and the measurement (as input to the controller) many hours later still used the input value of 723 MW !!! In such a meshed power network it is unlikely that such a value is constant …
Oops … something went absolutely wrong!
Report by exception (on a value change as used for the above measurement) is great … as long as there are changes figured out and reported. A frozen value does not cause a change and thus no new value will be reported … No receiver should expect that the export power is constant (723 MW) for days!! The sensors may have worked fine … but the software and communication failed … on both sides (sender and receiver). A receiver should not trust that the software and communication is working fine all time.
Here are some measures to monitor the communication (by the receiver) to figure out if the communication is OK:
- Ping (in case of TCP/IP) (if no response after some time: raise flag)
- TCP Keep-alive (if no keep-alive message in t bigger keep-alive: raise flag)
- Polling by receiver (if no response after some time: raise flag)
- Periodic reporting (if no report in t greater period: raise flag)
- In case of no message received in a configured time period (in case of using IEC 61850 Reporting) the receiver should check if the report control block is enabled and is using the correct configuration values like trigger option, …
- Check if the sequence of received values are plausible
- Use redundant systems (comm, …)
- …
https://www.entsoe.eu/news/2019/05/28/entso-e-technical-report-on-the-january-2019-significant-frequency-deviations-in-continental-europe/
This reminds me on the Boeing 737 MAX disaster … maybe a programmer left the vendor of the load frequency controller and hired with Boeing … I am kidding.
How many programmer or people that configure power control systems and communication systems that lack experience with complex systems like a plane or a power system. Where are the “grey-hair” experts that would tell you in minutes how to … ? They may enjoy the beach with warm water and sun shine – relax and spend the pension for ...
It is not sufficient to have no ideas – one should also be unable to implement them.
I expect that more of these problems will hit the street once we have far more control, monitoring and communication in the smart(er) grids of medium and low voltage. Note that the problem in January 2019 occurred at transmission level!! … where more resources (higher budgets) are available (in the past).
Have a great weekend – with power.
Posts
1 comment:
Hi.
While I totally agree that the software should be designed to handle such problems, I would like to comment on the ENTSOe report.
Indeed, it points out that the main cause for frequency deviation are deterministic frequency deviation, ie deviation caused by the change of market offers very round hour.
So even if the system can be hardened, the root cause to address is the architecture of the market, especially the block offers which created severe variations every hour.
Post a Comment