By existence of duplicate GOOSE message, I intend that whenever a GOOSE message is simulated through a simulation tool without a simulation flag, the original IED publishing the GOOSE remains active in the network such that the GOOSE published by it is present in the network along with the simulated GOOSE, the subscriber IED (of almost all the manufacturers) is not able to discriminate between the GOOSE published by the original IED and the GOOSE published by a simulation tool and it responds to the simulated GOOSE leading to maloperation of the scheme which utilizes the GOOSE.
Why this is critical:
Consider a Case when a distance protection IED protecting a line, is publishing a GOOSE message to trip the circuit breaker through a switchgear controller which receives that GOOSE and trips the CB. To test the scheme when line is under shutdown, a utility engineer would not put the IEDs in test mode or use simulation flag during GOOSE simulation as actual tripping of CB needs to be verified. The practice would be to simulate the trip GOOSE with trip status, without simulation flag and check whether the Switchgear controller trips the breaker. In such a case, if by mistake a different trip GOOSE (which is used for a trip scheme elsewhere in the substation) is simulated in the network with trip status , it will lead to maloperation even though the simulated GOOSE will have a sequence number and state number than the original GOOSE which still would be present in the network.
More than a cyber security requirement, this detection is important to have a flexible and reliable testing mechanism.
As per standard the behaviour of subscriber on receipt of such duplicate GOOSE message is interpreted as a local issue of the subscriber. Instead it should be a mandatory requirement for every subscriber to detect a duplicate GOOSE having an out of order state and sequence number.
Proposal
Discussion
Created
Status
Given the statement (quote) "IED ... is not able to discriminate between the GOOSE published by the original IED and the GOOSE published by a simulation tool", the options for an IED to detect this may be limited.
The "duplication" of an operational GOOSE message by a simulation tool (without setting the simulation flag) is a wrong application of the tool that will almost always lead to issues in the system.
The TR IEC 61850-90-28 (Specification to validate received GOOSE and SV messages) does address this. Feasible measures are proposed there.
02 Jan 24
Discussion (red)
e
24 Dec 23
Discussion (red)
This problem cannot be solved completely by GOOSE subscriber behavior specification, as there are always situations where the sequence numbers decrease (e.g. IED restart) or the source IED changes (redundant publishers). It must be solved by organizational means (e.g. a testing / simulation device per default sets the SIM bit, the function to be tested uses test mode etc.), and for sure a test engineer always has a high responsibility on what he is doing. Thus it is outside the standard.
17 Aug 16
Discussion (red)
The issue is with a duplicate message , i.e a message without simulation flag set true in it, which is published in the network by a GOOSE publishing tool (thorugh an |IED's CID file), while the original IED publishing the GOOSE is still present in the network.
That means at a time, we have two GOOSE messages with different StNum & SqNum present in the network, both without simulation flag. In case we have the StVal of GOOSE different (one with StVal 1 & othetr with StVal 0) the subscriber responds to both the messages and the output of scheme using the GOOSE TOGGLES as per the value choosen by the subscriber.
Elaborating more on why this s a big concern for our Utility:
Consider a Case when a distance protection IED protecting the ckt 1 of a transmission line , is publishing a GOOSE message to trip the circuit breaker through a switchgear controller which receives that GOOSE and trips the CB. To test the scheme when line is under shutdown, a utility engineer would publish the trip GOOSE with trip status through a publishing tool, without simulation flag and check whether the Switchgear controller actually trips the breaker. In such a case, if by mistake a different CID file is chosen by mistake, (say that of CKt 2 of same line) and trip GOOSE is published in the network with trip status , it will lead to maloperation in the other ckt even though the duplicate published GOOSE will have a sequence number and state number than the original GOOSE (of ckt 2) which still would be present in the network. This mistake can happen as within the CID files of both ckt 1 & 2, all the data would be same. One may also argue that instead of publishing the Trip GOOSE through the GOOSE publishing tool, one should send the Sampled Value streams (of fault condition) to the IED which then would generate the correct Trip GOOSE, but this will restrict the flexibility of Testing Approach.
17 Aug 16
Discussion (red)
According to IEC 61850-7-2 Ed2, the GOOSE message parameter is specified by:
"The parameter Simulation shall indicate with the value TRUE that the message and therefore its value have been issued by a simulation unit. The GOOSE subscriber will report the value of the simulated message to its application instead of the “real” message depending on the setting of the receiving IED. The allowance for an IED to switch from acceptance of real messages to simulated messages is specified by a data object defined in IEC 61850-7-4."
The specification already implies that the GOOSE subscription uses the "simulation" message instead of the "real" message. It also means that a Subscriber that does not support simulation (from acceptance of real messages to simulated messages), does not accept the simulated messages - i.e. the traffic/presence of simulated messages does not modify the behavior of the suscriber that is solely subscribing the "real" message.
The UCA testing procedure already verify the behavior of the subscriber when both real and simulated messages are present on the network (sGos6).
Proposal:
Add an explicit statement to IEC 618507-2 Ed2.1.