How many GOOSE re-transmission messages should/shall a device transmit during a “data change” state and/or a “quiescent” state? The standard itself provides a table for those data change states. Should there be a similar table for the quiescent states?
With regard to GOOSE TimeAllowedToLive (TATL) - How many messages should a device retransmit before its GOOSE TATL times out regardless of whether it’s a “data change” or “quiescent” state?
Background to the problem encountered:
The GOOSE TATL is a feature that can be used to determine a device’s network availability. This heartbeat of such is defined in the standard (61850-8-1), clause 18.1.2.5 on page 68:
"Each message in the retransmission sequence carries a timeAllowedToLive parameter that informs the receiver the maximum time to wait for the next re-transmission. If a new message is not received within that time interval, the receiver shall assume that the association is lost."
Many protection & control hardwired systems require alternate or backup schemes & circuits to operate when certain components of that system become disabled. Under specific constraints, those alternate schemes may be required to immediately become active. 61850 systems are no different in fulfilling that type of requirement. The challenge is in determining when a device can’t perform it’s intended function with regard to it’s network availability.
The use of this GOOSE TATL can be a reliable tool in determining a device’s network ability. But if a device only publishes one message before its GOOSE TATL times out, it’s quite possible a receiving device will miss the message. And if the device that misses the message is part of that back-up scheme, it will immediately swap to the auxiliary logical circuits only to swap right back at the next message received.
Proposal
Having to add logical timers in those “one message” type circuits are just extra work for the system designer when the GOOSE TATL feature could be refined so that a receiving device gets more than one chance to get the message before the TATL times out. Also, if the responsiblity lies with the receiveing device, who's to say their method of tolerance on missed messages is too tight or too loose. A publishing device should issue more than 1 message before its GOOSE TimeAllowedToLive times out. Perhaps more than 2 message publications are better ...
Discussion
Created
Status
I Agree, no reason to send a GOOSE frame up to 'what you decide' times within a TAL, 1 should be the theoretical choice, 2 seems to be a maximum.
Think the issue in the REVERSE way: with a definite retransmission profile (curve) set the approrpiate TAL on the frame according to your requirements. The producer decides if it allows n frames to be lost or not, so the TAL has to be sufficient for n frames loose. I use n=1 frame loose tolerance (2 frame in a TAL). n=0 is not tolerant and involves a default immediately. Greater is n, more you are tolerant, but less you are accurate or reactive.
The main issue is that it is not possible to know why a frame is not arrived: network perturbation, producer failure, producer switching on backup (just a bit late), so it is impossible to do differenciated actions in the subscriber. We have to do vith that issue, and it is up to the producer to decide which TAL is for a given frame.
21 Dec 07
Not Applicable
I can't see any reason why the sender couldn't be set up to retransmit two times within TAL. As the standard states "the maximum time to wait". This doesn't prevent the sender to sent two messages within TAL. On the other hand, if TAL is set to a short time´, then the network would for sure be loaded.
Isn't this an issue that a vendor and user could take care of without making changes in 8-1?
19 Dec 07
Not Applicable
This issue is a subscriber/network infrastructure issue. Consider the proposal in terms of Substation LANs vs. Utility WAN usage. Obviously, the lower speed WAN links need to avoid congestion and therefore mandating a specific number of retransmissions within a TAL can't be mandated within 8-1 in a manner that addresses all possible topology and uses.
Additionally, consider a TAL of 4 msec, the request to retransmit 4 GOOSE messages within 4 msecs does nothing but load the network.
The GOOSE retransmission model was chosen to meet a 3 sigma probability of delivery within a 4 msec event horizon. Math proves that:
the probability of missing the original message, retransmitted, plus the expected message (e.g. 3 messages within 4 msecs) all of the messages is less than the probability of a Ethernet CRC error.