Industry Practice for Programming/Testing Protection Relays 1

[mbk2k3]

Hey folks,

I had a question about what the industry standard practices are for things like commissioning and testing protection relays. Any good guides/recommendations out there?

I recently had a situation where a brand new switchgear lineup was commissioned and put in service (CTs, PTs, wiring, control circuits, etc all checked).
2 months in, we realised one of the instantaneous protection settings (50) was incorrect and needed to be adjusted. In this case, do we simply change the setting and have confidence that the relay will work as intended, or should we get test equiment to actually perform current injection testing to validate the setting?

I suspect it will come down to plant owner/commissioning team preferences, but it seems overkill to re-test every time we adjust a setting on brand new equipment. If it was 10+ year old equipment, I can understand re-testing....

Thoughts?

 

[HamburgerHelper]

I suppose the real questions are "how important is your process and are you ok with someone asking you why you didn't test the relays"? Relay testing 99.9% of the time doesn't fail on testing the functionality of the relay but on the wiring and logic in the settings. I have seen it tested and not tested for small changes. Some testing companies don't put much stock in testing individual elements in a microprocessor relay.

 

[ScottyUK]

Our site experienced a bad upload to a Alstom P143 feeder relay which corrupted many of the settings. The relay looked healthy from the front panel, but I have no idea how it would have behaved under fault conditions with those settings. I suspect we would have had a real mess to clear up.

A commissioning engineer had made a minor logic change to an alarm signal, but didn't re-prove the relay functions afterwards. I'd kinda assumed that the software would read back from the relay and do a comparison with what was sent to the relay, but apparently not. I guess it is possible that some rogue event took place which corrupted the settings after the commissioning engineer disconnected from the relay, but that's pushing the boundaries of what I'm prepared to accept as 'coincidence'.

 

[FreddyNurk]

When I was employed by a utility, the principles from the protection team were to verify all settings, after any change was made. It was sometimes quite an expensive exercise, depending on where the particular relay was and what else needed to happen to take it out of service to test it.

The ideal case was to test as much of the installation as commissioned as possible, so that things like CT wiring and breaker trip coil connections could also be verified, but a lot of the time the relay was tested first by itself, and then further testing was carried out onsite, as this reduced the onsite effort required.

It was also protection's perspective that changes to the relay configuration (e.g. communications settings) required a retest, and there were usually gaps in the ability to test the ancillary functions (such as communications) which meant that sometimes there was a bit of retesting going on.

For what its worth the argument seems more spurious that something like a setting dial on a Multilin SR737 would fail and provide an incorrect setting than the possibility of a corrupted setting on a newer relay occurring, but if the end result is protection that doesn't operate correctly then its a problem.

Overall though, its a risk based exercise, balancing the cost of testing against the risk of an incorrect relay setting not doing what it is supposed to. Regular testing and record keeping also allows for at least some means of working out if unauthorised setting changes happened, a factor that may or may not be relevant for your location.

EDMS Australia

 

[Marmite]

These are the procedures followed by a Utility Company I used to work for, in the case of settings changes:-
1) Ensure that there is not an abnormally high risk of faults on the protected plant. If there is, defer the job or arrange an outage.
2) The primary circuits are to be left in service (unless there is a planned outage for other reasons).
3) The setting changes are to be done with the relevant trip links removed.
4) No secondary injection or trip testing is to be carried out if the setting change is restricted to changes to non-logic elements with numerical settings (e.g. pickup, time multiplier, timer settings, reaches drop offs etc.).
5) Secondary injection, trip testing and functioning is to be undertaken where there is a change in function (i.e. the inputs and outputs have altered or the logic has been changed). In this case, only that part of the logic that has changed is to be tested.
6) Always confirm that the relay is selected to the correct Setting Group as a last check.

Regards
Marmite

 

[submonkey]

Hi mbk2k3,

The utility where I worked would always re-test (by secondary injection)
the full function of a relay after re-loading a setting file. If the wiring
was untouched, testing to links or a tripping (lockout) relay was sometimes
accepted depending on circumstance.

With modern relays, it is very easy to accidentally break something, or
change a setting with unexpected side effects. Also, there have been cases
where a setting file does not properly transfer.

I would either test the relay, or evaluate if the setting change can wait
until next maintenance. I would resist the temptation to fiddle without
proper re-testing.

Thanks,
Alan

 

[piterpol]

A well known and expertise specialist once said: "The best IED maintenance test is not to do it".
He had some good reasons in saying this assertion.

 

[davidbeach]

"not to do it" is not an option for relays subject to mandatory maintenance testing such as that required by PRC-005.

 

[jghrist]

Save the as-found settings and as-left settings. Do a compare to make sure that only the intended changes were made.

 

[dpc]

In the scenario you describe, I think jghrist has the right approach. Most problems in digital relays occur in the logic or configuration of the relay at least in my experience. Functional testing is important. I've experienced significant issues and a total substation outage related to failure of the certified and supposedly qualified testing company to leave the relay configuration "as found" after doing the mostly pointless current injection testing. On subsequent faults, the relay failed to trip the breaker, because the relay techs had reprogrammed the relay outputs for ease of testing, and failed to restore proper logic. So the relay saw the fault, tripped and nicely recorded the fault event, but the output contact connected to the breaker trip coil did not close. So that was fun.

I've done quite a few "hot" changes of relay settings without issue, although I always advised that an unintended operation could not be ruled out. In some cases we opened the trip circuit temporarily, but that creates issues as well.

 

[DTR2011]

The OP hasn't mentioned the brand of relays. If it is a SEL relay, one can use the SEL SW (5030), or directly set the element via a terminal SW (either within SEL 5030 or similar terminal emulator SW). In this case it is very easy to see that the setting has been made. The settings can be SHOwn and captured for records. In the terminal mode WYSIWYG.

Years ago I was on a project where the 25 function was to be added to an existing Distribution Protection Relay. New 51 pickups and time delays were added as well. I uploaded the provided settings file and attempted to test new 25 element. I could not get the sync check to operate. When viewing the settings from the HMI, I could see my 51P and TD settings were applied, thus thinking that there were no issues with the file / upload. A download and compare made it seem as if the settings were applied properly. In the end after menu diving way down to 25 function via the HMI, I discovered 25 had not been enabled. There was no terminal emulator mode available.

Our local utilities may request a pickup change, without a test. Logic changes require a test.

 

[davidbeach]

Ok, I use SEL relays so the rest is based on what can be done in that direction.

For a commissioned set of relays where a reach needs to be changed, I'd change the reach without any further testing. I'd download the settings as they exist in the relay. I'd use a terminal window to make that specific change without uploading a whole setting file. I'd then download the whole setting file and compare it against the first file downloaded. If there are any differences other than the change I intended to make I'd stop at that point and call for backup. If that was the only change shown, I'd be good with it and proceed to the other relay. Experience shows that approach works.