Isolation of GOOSE messaging

[veritas]

Don't know if this is the right forum but here goes.

I have an existing substation with indoor switchgear. Single bus, one incomer, 5 outgoing feeders. Circuit breaker fail is implemented using IEC 61850 GOOSE messaging. A new feeder is to be added, same relay (Siemens) to be used, i.e. 6 outgoing feeders. New feeder relay has been cut into the 61850 network already.

My concern revolves around the testing of the new scheme. The complete substation cannot be taken out of service to test the relay. It will be taken off-line for a few hours to prove the CBF of the new feeder and CBF inputs from the other feeders to the new feeder.

Whilst new relay is being tested rest of sub is energised. The new scheme sends its local breaker status to other relays for interlocking purposes. I have disabled the CBF in the new relay for the duration of the test, by disabling the CBF function in the device configuration.

However, I would like to know what is the best way of disabling GOOSE messages from one relay to another when wishing to test? I am no expert in this field and would like to hear how others do it. How can I prevent the new relay sending it's 52a status to the other relays (do not want to interfere with live interlocks)? Previously there used to be links one could just open. I guess now it has to be done in software in one form or another.

Hope I make sense.

 

[davidbeach]

I don't have any 61850 specific answers, but any time we do transfer trip we have an input to the relay that enables the transfer trip; that input goes through a test switch. Open the test switch and the relay doesn't transmit trip signals and ignores any it receives.

Probably too late for this installation, but your breaker failure scheme seems rather misguided. All it needed was a bus lockout relay to trip and block close of all the breakers on the bus. Each relay would have a test switch between the BF output and the lockout; and there'd be a test switch between the lockout and each relay. Easy and readily testable.

Now you're in a situation where you have to modify your settings between testing and operation. That's something to try to avoid if at all possible.

 

[DiscoP]

The best option depends on a a couple of factors. Some relays have a Test Mode available. If the relay is in test mode, this is mentioned with each GOOSE published, and the others relays will react to this message.

Edition 1 and 2 of the standard achieve this by different methods. We have found that the method of putting the relay into test mode varies between manufacturers, and also not all relays behave the same while in test mode.

We use an opto input as a virtual isolation. When the input is off, the isolation is applied and the input status is published as a GGIO, then we create logic at the receive end to implement the isolation in programmable logic (eg CBF and not GGIO = Trip).

But if something like this has not been engineered in to the design, Test Mode is likely to be the only option available.

 

[veritas]

There is a Test Mode in the relays being used. It sets a test bit so that any GOOSE messages transmitted is accompanied by the test bit. The recipient device recognises the test bit and does not react to the GOOSE message received. However, the relay manual takes great pains to spell out that this mode should never be used when the relay is 'in service'.

The idea of a BI wired to a switch to result in a GGIO (virtual isolation) to accompany the GOOSE is not a bad idea but a few concerns:

1. When sending a CBF trip to all the other relays, with the CBF trip being accompanied by a GGIO then would a time delay not be useful to ensure that if the CBF trip signal arrives first, a time delay in the recipient allows the recipient relay to check that the GGIO was not received as well? I would probably add this timer in the logic somewhere (if needed).

2. When one adds in a new relay with this virtual isolation, surely you would not try something like CBF bus-strip testing for the first time on a 'live' system? unless maybe all the recipient relays were proven to operate correctly to the CBF + GGIO prior to their going 'live'?

But not a bad idea I'd say. Worth keeping in mind. Thanks for that.

 

[DiscoP]

The GGIO and CBF signals are contained in the same dataset/GOOSE control block. So the state of both elements are each published in the same message - you can't really receive one without the other.

Adding a new relay would be an interesting project. Test equipment can replicate the other relays so it would be possible to test each relay in isolation.

We tested each relay disconnected from the network, and used the test set to replicated the CBF/GGIO signals from all other relays to prove all of the logic and 61850 engineering.

In theory if each relay is tested OK, complete end to end testing is not needed, but in practice we normally like to see the complete scheme operate !

We have a duplicated system, so we can test one whole live system with all trip links opened (so long as single protection is acceptable for short duration).

However if you only have a single scheme that cannot be removed from service - you may need to trust the results from the test set (noting we didn't find a discrepancy in results).

 

[veritas]

DiscoP

I guess my preference is for complete end to end testing as well. I need to verify in the recipient relay that the GOOSE message was received and effected the desired result. Difficult to do when equipment in service. I a not a 61850 fundi at all and am learning each day. Big problem I currently have is to isolate I/O which GOOSE need. For example, I'm sending the cb status from CB-A to CB-A.

If CB-A is in service, then how do I generate a CB-A open state to send to CB-B using GOOSE? Was easy enough to do with conventional hardwired system and a few strategically placed links but a bit more challenging when using GOOSE (I think).

Alternative is to test bus-section CB fail on a bus-section by isolating all the trip links. But then the bus-section is solid and you'd near to be sure that you're suitably covered by upstream (back-up) protection.

 

[DiscoP]

Yes it is more challenging without the links, but there are ways.

You can inject GOOSE using test sets like Omicron and Doble, and you can sense GOOSE as well.

It all depends on how the original scheme was designed as to what you can do.

I'm not a 61850 person either, and I frustrated the 61850 people on this project with my insistence on testing and isolation, but we got there - well I think we did

We've found that one of the relays has a firmware bug, so we need to update and test a lot of relays in a live substation, so this will be a good test on how good the designs are.