I have heard some people refer to an event happening and the LAN network getting flooded with GOOSE messages to the point of saturation of the network bandwidth. Is this really true?
How many GOOSE per second?IEC 61850 8-1 Ed2 cl 8.1.2.5.1 and fig 8. “Additional reliability is achieved by re-transmitting the same data with gradually increasing SqNum and retransmission time”. Also Part 2 Glossary “This report is re-issued sequentially, typically after the first report, again at intervals of 2, 4, 8…60000 ms. (The first repetition delay value is an open value it may be either shorter or longer)”. According to IEC 61850-8-1Ed2 18.1.2.5.2, the minimum timeAllowedtoLive to start is 1 ms and can have a maximum value of 4294967295 ms (just under 50 days) According to IEC 61850-8-1Ed2, Fig 10, Key 2, it is suggested that the message re-transmit timer actually send at half the timeAllowedtoLive value. Taking the first retransmission set to, say, 5ms you would then get another retransmission at 15 ms after the event (+10 ms), then 35 ms (+20 ms), then 75 ms (+40 ms), then 155 ms (+80 ms), then 315 ms (+160 ms), then 635 ms (+320 ms) and the next would be 1275 ms after the event (+640 ms) being the 9th message in total. The next message would have a wait time of 1280 ms making the 10th message at 2.555 s and then a further 2.56 seconds till the 11th message at 5.115 seconds after the event. Even if the first retransmission time is set to 1 ms then you would only get the 12th message occurring at 1024 ms after the event. A 'flood' of 200 messages from one IED in 1 second is simply not possible. How many GOOSE from one IED due to one 'event'?The question is then how many GOOSE fast re-transmits would be initiated by one substation event? Well this is a good question based on how good is the GOOSE configuration policy of the utility/systems integrator. One event can cause a new StNum GOOSE from one IED with a certain Dataset. The SqNum would reset to 0 The IED may even have multiple GOOSE with a different Datasets - but that different Dataset would not have any of the same data elements as the first GOOSE - that would be pointless since any IED can subscribe to any GOOSE so it is not necessary to have the same data in two different GOOSE unless there was some bandwidth/processing problem with the subscribing IEDs.that needed sophisticated combinations of data in one GOOSE. As far as the individual IED is concerned there is likely to be only one GOOSE which goes through the restart of the fast re-transmission sequence for any particular event. Even if there is multiple GOOSE from that IED, there certainly is not going to be thousands of different GOOSE from that IED as a result (unless there has been really poor GOOSE policies used). This is not an uncontrolled "flood". It is engineered and hence can be managed to make sure it doesn't cause a problem on the network. How many IEDs send GOOSE as a result of one event?A CB status of close to open may give cause to the No1 and No2 (X and Y, Main and Backup) systems each to send a new StNum GOOSE from each CB Interface IED. Similarly a protection operation in one bay would result in a GOOSE from each of the protection function No1 and No2 IEDS. For multiple IEDs to initiate a new StNum GOOSE, they each have to have the same cause (same input conditions) and it would be specifically designed to do so. It is possible that one event has multiple symptoms giving rise to two or more IEDs sending a new StNum GOOSE each in their own right eg CB opening gives rise to XCBR.pos changing from 1 to 0 and MMXU.PhV changing from 400 kV to zero. However again this is by design of the System. One GOOSE being received by one IED may then lead to that IED issuing its own new GOOSE StNum as a result of its function but that is what you'd expect. None of these conditions is a "flood". Are 40 messages considered a "flood"?The permitted value of timeAllowedtoLive (the interval before the next retransmission) is a MAXIMUM value of 4,294,967,295 mS. If the timeAllowedtoLive = 1000 mS, it will take over 30 seconds to publish 40 messages as demonstrated in these tables: | Expand |
|---|
| title | Click here to expand detailed table of retransmissions for 1 s max time to live... |
|---|
| | | | | Maximum timeAllowedtoLive = 1000 ms |
|---|
Message
number |
|---|
| | 1st retransmit 1 ms | | 1st retransmit 5 ms |
|---|
|
|---|
| Interval
til next
retransmit
(ms) | Time
after
event
(ms) |
|---|
|
| Interval
til next
retransmit
(ms) | Time
after
event
(ms) |
|---|
1 | | 1 | 1 |
| | | | | | | | 1 | | | | | | | | | | | | | | | | | |
|
If the timeAllowedtoLive = 4,294,967,295 ms (i.e. the maximum), it will take over 447 days (first retransmit 1 ms) or 559 days (first retransmit 5 ms) to publish 40 messages | Expand |
|---|
| title | Click here to expand detailed table of retransmissions for maximum setting of max time to live... |
|---|
| | |
|---|
|
| Maximum timeAllowedtoLive = 4,294,967,295 ms |
|---|
| |
| 1st retransmit 5 ms |
|---|
Message
number |
|---|
| Interval
| Interval till next
retransmit | Time after
event |
|---|
| Interval till next
retransmit | Time after
event |
|---|
| | | | | | | | | | | | | 40 | | 75 | | 5 | | | | | | | | | | | 1, | | | |
| 10,240 | 10.2 s | 20,475 | 20.5 s | 13 |
| |
| 40,960 | 41 s | 81,915 | 1.4 min | 15 |
| |
| 81,920 | 1.4 min | 163,835 | 2.7 min | 16 |
|
| 32,768 | 32.8 s | 65,535 | 1.1 min |
|
| 163,840 | 2.7 min | 327,675 | 5.5 min | 17 |
|
| 65,536 | 1.1 min | 131,071 | 2.2 min |
|
| 327,680 | 5.5 min | 655,355 | 10.9 min | 18 |
|
| 131,072 | 2.2 min | 262,143 | 4.4 min |
|
| 655,360 | 10.9 min | 1,310,715 | 21.8 min | 19 |
|
| 262,144 | 4.4 min | 524,287 | 8.7 min |
|
| 1,310,720 | 21.8 min | 2,621,435 | 43.7 min | 20 |
|
| 524,288 | 8.7 min | 1,048,575 | 17.5 min |
|
| 2,621,440 | 43.7 min | 5,242,875 | 1.5 hr | 21 |
|
| 1,048,576 | 17.5 min | 2,097,151 | 35 min |
|
| 5,242,880 | 1.5 hr | 10,485,755 | 2.9 hr | 22 |
|
| 2,097,152 | 35 min | 4,194,303 | 1.2 hr |
|
| 10,485,760 | 2.9 hr | 20,971,515 | 5.8 hr | 23 |
|
| 4,194,304 | 1.2 hr | 8,388,607 | 2.3 hr |
|
| 20,971,520 | 5.8 hr | 41,943,035 | 11.7 hr | 24 |
|
| 8,388,608 | 2.3 hr | 16,777,215 | 4.7 hr |
|
| 41,943,040 | 11.7 hr | 83,886,075 | 23.3 hr | 25 |
|
| 16,777,216 | 4.7 hr | 33,554,431 | 9.3 hr |
|
| 83,886,080 | 23.3 hr | 167,772,155 | 1.9 day | 26 |
|
| 33,554,432 | 9.3 hr | 67,108,863 | 18.6 hr |
|
| 167,772,160 | 1.9 day | 335,544,315 | 3.9 day | 27 |
|
| 67,108,864 | 18.6 hr | 134,217,727 | 1.6 day |
|
| 335,544,320 | 3.9 day | 671,088,635 | 7.8 day | 28 |
|
| 134,217,728 | 1.6 day | 268,435,455 | 3.1 day |
|
| 671,088,640 | 7.8 day | 1,342,177,275 | 15.5 day | 29 |
|
| 268,435,456 | 3.1 day | 536,870,911 | 6.2 day |
|
| 1,342,177,280 | 15.5 day | 2,684,354,555 | 31.1 day | 30 |
|
| 536,870,912 | 6.2 day | 1,073,741,823 | 12.4 day |
|
| 2,684,354,560 | 31.1 day | 5,368,709,115 | 62.1 day | 31 |
|
| 1,073,741,824 | 12.4 day | 2,147,483,647 | 24.9 day |
|
| 4,294,967,295 | 49.7 day | 9,663,676,410 | 111.8 day | 32 |
|
| 2,147,483,648 | 24.9 day | 4,294,967,295 | 49.7 day |
|
| 4,294,967,295 | 49.7 day | 13,958,643,705 | 161.6 day | 33 |
|
| 4,294,967,295 | 49.7 day | 8,589,934,590 | 99.4 day |
|
| 4,294,967,295 | 49.7 day | 18,253,611,000 | 211.3 day | 34 |
|
| 4,294,967,295 | 49.7 day | 12,884,901,885 | 149.1 day |
|
| 4,294,967,295 | 49.7 day | 22,548,578,295 | 261 day | 35 |
|
| 4,294,967,295 | 49.7 day | 17,179,869,180 | 198.8 day |
|
| 4,294,967,295 | 49.7 day | 26,843,545,590 | 310.7 day | 36 |
|
| 4,294,967,295 | 49.7 day | 21,474,836,475 | 248.6 day |
|
| 4,294,967,295 | 49.7 day | 31,138,512,885 | 360.4 day | 37 |
|
| 4,294,967,295 | 49.7 day | 25,769,803,770 | 298.3 day |
|
| 4,294,967,295 | 49.7 day | 35,433,480,180 | 410.1 day | 38 |
| 4
| 4,294,967,295 | 49.7 day | 30,064,771,065 | 348 day |
| 4,294,967,295 | 49.7 day | 39,728,447,475 | 459.8 day | 39 |
|
| 4,294,967,295 | 49.7 day | 34,359,738,360 | 397.7 day |
|
| 4,294,967,295 | 49.7 day | 44,023,414,770 | 509.5 day | 40 |
|
| 4,294,967,295 | 49.7 day | 38,654,705,655 | 447.4 day |
|
| 4,294,967,295 | 49.7 day | 48,318,382,065 | 559.2 day |
|
BandwidthThe last issue is then to deal with the actual bandwidth requirements of the LAN and the IEDs. The maximum size Ethernet frame is 1542 Bytes i.e. 12336 bits, hence even a 100 Mbit/s link can handle AT LEAST 8106 messages per second, and hence MANY times that if each message is say only a few hundred bytes as even larger size GOOSE with "dozens" of elements are likely to be - I mean there is potentially a lot of individual Data Attributes that could be put into a Dataset but realistically there are only a few that need to be included in a GOOSE Dataset .. especially if there has been good design principles such as using PTRC as a grouping of trip initiation Logical Nodes! I would be interested to get an email from you with the largest size GOOSE message you have seen and the reason why: rgh AT rodhughesconsulting DOT com
Clearly GOOSE does not "flood"...... unless the Systems Integrator designs in very poor mechanisms. |