×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

Isolation of GOOSE messaging

Isolation of GOOSE messaging

Isolation of GOOSE messaging

(OP)
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.

RE: Isolation of GOOSE messaging

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.

RE: Isolation of GOOSE messaging

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.

RE: Isolation of GOOSE messaging

(OP)
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.

RE: Isolation of GOOSE messaging

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).

RE: Isolation of GOOSE messaging

(OP)
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.

RE: Isolation of GOOSE messaging

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 smile

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.


Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources