Industry Practice for Programming/Testing Protection Relays
Industry Practice for Programming/Testing Protection Relays
(OP)
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?
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?






RE: Industry Practice for Programming/Testing Protection Relays
RE: Industry Practice for Programming/Testing Protection Relays
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'.
RE: Industry Practice for Programming/Testing Protection Relays
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
RE: Industry Practice for Programming/Testing Protection Relays
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
RE: Industry Practice for Programming/Testing Protection Relays
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
RE: Industry Practice for Programming/Testing Protection Relays
He had some good reasons in saying this assertion.
RE: Industry Practice for Programming/Testing Protection Relays
RE: Industry Practice for Programming/Testing Protection Relays
RE: Industry Practice for Programming/Testing Protection Relays
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.
RE: Industry Practice for Programming/Testing Protection Relays
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.
RE: Industry Practice for Programming/Testing Protection Relays
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.