Why raise such a question on this blog that is about standards like IEC 60870-5-104 and IEC 61850 …? These are two good questions. Let’s discuss them briefly.
The Solar Eclipse 2015 and its impact on the power transmission system is discussed these days. The crucial issue is the minute-to-minute power gradient that may exceed between minus 400 MW/minute and plus 700 MW/minute; the highest gradient occurs when the PV in-feed returns at the end of the phase. This gradient may be managed by the TSO or not – who knows. We know it at lunch time on March 20, 2015.
There are many recommendations on the web, how to get prepared: having water, food, … for up to 10 days or so … I hope we will not need these.
@Question 2:
There is a need for the TSOs (just four in Germany!) to relay on good measurements from all-over in the grid and secure control possibilities to manage power plant in-feeds and substations. I guess they have good communication systems they can trust. These systems have been developed over many decades. They are tested and run reliably. Still. But what happens in future where we will have hundreds or millions of technical systems (embedded controllers …) that contribute to the system view and management?? Is this an issue at all?
Yes, it is a crucial issue. Let me discuss the following real-life incident reported last week:
A gateway in a virtual power plant provides the measured load on the network connection point of a CHP (combined heat and power) system. Normally the CHP feeds power into the network. But all in a sudden the VPP/TSO received a signal telling them a jump of the load from 0 MW to 600 MW!! Should the control center responsible for that part of the grid act or not? Hm. If this would be a real jump then it would have to react.
(Un)Fortunately the 600 MW jump was just a jump in the Value communicated!! It was caused by an error in the gateway (RTU kind of device). Was this value plausible? No. Because the CHP could just feed-in – not draw that much power from the grid.
With IEC 61850 in place we could easily expose the limits of power production and load. The logical node MMXU could be used for the limits in which a value is valid:
Data Object TotW of class MV (measured value) - Total active power (total P)
could provide the actual value, quality, range and the limits in the details provided through the MV CDC:
| instMag.f | AnalogueValue coded as floating point |
| q | Quality |
| range | ENUMERATED normal|high|low|high-high|low-low (out of range would change quality value) |
| rangeC | RangeConfig:
hhLim
hLim
lLim
llLim
min
max |
min: the min (minimum) attribute shall represent the minimum process measurement for which values of i or f are considered within process limits. If the value is lower, q shall be set accordingly (validity = questionable, detailQual = outOfRange).
max: the max (maximum) attribute shall represent the maximum process measurement for which values of i or f are considered within process limits. If the value is higher, q shall be set accordingly (validity = questionable, detailQual = outOfRange).
In our case, the TotW for the CHP generator may be limited between 0 W (min) and 35 kW (max). A value of “minus 600” MW would have to be flagged as questionable and outOfRange !! Negative values and values higher than 35 kW would be flagged out of range!
The receiver (a control center) could check the limits of the values (either by reading the range configuration online by a service or getting it from the corresponding SCL file). It could figure out that the range is 0-35 kW. Even if the gateway (RTU) would send “minus 600” MW (load) … the CC could understand that this is a bad value – recommended not to use.
The meta-data of the measured value serve as a means to help interpreting the plausibility of a value communicated.
IEC 61850 models add very useful information to help (a bit) keeping the power flowing. There are many other physical issues to take into account … but information and information exchange plays a crucial role!
Posts
