testing of numerical relays 1

[521AB]

After several and repeated bad experiences, I would like to draw your attention on this aspect regarding the "new" methods of testing numerical relays.
The testing engineer goes in front of the relay and gets the RIO file from the relay. It imports the RIO file from the test-set software. It performs the test. Everything is Ok. After several days, the same relay gives unwanted trip because nobody checked that one distance zone was set in forward when it was supposed to be set in reverse.

Similar situation: test engineer goes in front of the relay and reads all the settings from the manufacturer software tool. From the software tool it generates the RIO file which is imported in the test-set software. Everythink is Ok. After some days, the relay does not trip because the engineer tested the relay when it was in setting group 3, when it was supposed to be in setting group 2.

In another thread we are discussing of standardizing the settings (for instance by means of IEC 61850) so that, for instance, test set manufacturers can "suck" all the settings from the relays by themselves and do not even need the RIO file passage.
Is that really the meaning of a relay test? Is really this that we need?

 

[00123456]

Hi,
we are also doing relay testing by IMPORTING RIO files from DIGSI, CAP541, Z-GRAPH etc but, we did not faced problem what you are saying. RIO files are only used for steady state testing. Purpose of RIO creation is only to import relay characteristic what we have set in relays (Group1/2/3) so it can save testing time to draw the relay char. in testing software, but which group we have to be import that is to be decided by test engineer. Ultimately, these are all testing tools, but testing is dpends on testing engineer.

Normally, our practice is; after mai-operation of relay, we are doing steady state testing as well dynamic testing by using some power system models/EMTP/ATP programs so that we can under stand bhaviour of relays based on system faults.

For example; our one of the relay (i am not putting name of relay model) was mal-operated on CVT transient (capacitor inrush) in reverse zone, but after the mal-operation same relay we were tested by importing RIO files & it was showing correct operation in all zones. After that, we have created some of the transient files in PSCAD/EMTDC based on system operation & we found mal-operation of relay in some of the transient conditions. After discussion with relay OEM, we came to know it was a problem with filter circuity of relay which was not properly filtering harmonics during such type of faults (even sampling was also not good).

Another example is for non-operation of differential relay. Our one of the phase fault O/C relay operated on phase to phase fault (bushing fault) when operating time of phase O/C relay is 200ms & operating time of differential relay is 25ms. After that, we did some exercise & same fault waveform (recorded from DFR)replayed on both the relay & we were observed operating time of differential relay was 197ms & waveform was showing transient CT saturation. RIO is only used for steady state testing not more!!! but steady state testing is also required we cannot deneied it.

Thanks

 

[lz5pl]

Just my two cents to the discussion:
When using of more than one setting groups is not required (99% in my experience) I always disable non-used groups. If it is not possible due to specifics of the relay, before enegizing I copy the tested setting group to all other groups.
I always include in the test report hardcopy printout of relay settings file, signed by me and by the customer. This is just to keep me on safe side for future claims. Some operators are more curious than qualified and I had cases when I found during the analizes discrepancies between my test configuration and real situation.
Of course these measures doesn't help against relay mal-operation, but are useful at least to avoid some stupid problems with the customer.

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[davidbeach]

When using relays with multiple settings groups for applications where only one settings group is necessary, the best practice is to include logic to set the first setting group as active and then copy that setting group to all other settings groups. That way if the relay ever, somehow, winds up in a different group it will change back to the desired group, and if the group change doesn't work the relay will still have the proper settings.

 

[lz5pl]

if the relay ever, somehow, winds up in a different group it will change back to the desired group, and if the group change doesn't work the relay will still have the proper settings.
-------------
Sorry davidbeach, I cannot understand how is possible this change back to the first group to happen automatically. I just copy active group to all others.

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[davidbeach]

At least in the brands I've worked with, there are logic statements that can be used to select the active setting group. So all groups should include the logic to set group 1 (or group 0 for those that start at 0 rather than 1) as the active group. See your relay instruction manual.

 

[dpc]

Some relays provide for automatic reversion to a preferred setting group, but other do not.

Digital relays need to be fully tested just like any other relay. In addition, there are other problems related to digital relays that must be considered.

An electro-mechanical distance can easily be mis-wired to be looking the wrong direction. Unless it is tested with an appropriate three-phase test set, this can go undetected. I have seen it happen.

Electro-mechanical relays can be left with test switches in the wrong position or with shorting bars on the CT circuits.

Settings group selection offers tremendous flexibility, but comes at a price of increased complexity and new ways to screw up. That's a pretty typical tradeoff.

There have been a lot of good papers presented on digital relay testing at the Western Protective Relay conference over the past few years. You can probably get a listing from their website.

The digital relays present new issues related to testing, but they are here to stay so we just have to deal with it.

 

[521AB]

It is maybe me who brought you out of topics. The 2 examples that I have done, even if real cases happened to a lot of people, are just metaphor examples to put under questioning this, almost automatic, process:

relay --> RIO file export --> test device RIO file import --> test --> 99% always correct.

Unless the relay is BROKEN, the test will almost always passed, but you miss for instance that the relay was supposed to be in another setting group, or that somebody has changed the direction of one protection function (by mistake).

In my opinion the process should be "humanized", I mean there must be one moment where the human must think. For instance: the RIO file is NOT generated by the relay or by the relay software tool. It is generated by the test device itself, and the settings are manually entered by the engineer, and he uses for this task, the setting document that must be available in the company (pdf file or paper.. something that cannot be changed).

This is what I meant... any comment?

 

[dpc]

You cannot really test a new relay installation by playing back RIO files into the relay. You must inject current and apply potentials just as is done with e-m relays. The playback feature is very useful in determining why a relay did what it did or to troubleshoot a relay firmware problem. But it does not tell you if the relay is wired up correctly. You also must test or simulate all of the discrete inputs that could effect the relay response.

But you really do NOT want to require that relay settings be entered manually every time. This will create many more problems than would be solved.

Configuration and testing of digital relays will be MUCH more time-consuming than for a single-function e-m relay because of the myriad of options and features.

I agree that a hard-copy versions of the latest settings should always be available. Any time I send a settings file I always send a .pdf of the setting report. It sometimes happens that the relay tech has an older version of the software and can't open my settings file, so a printout is a necessity. Good record-keeping and document/file control is also important.

 

[oldfieldguy]

dpc brings up an excellent point. It is imperative that the initial installation of the relay be carefully tested during commissioning.

I have a long list of horrors found. some, fortunately, were found during commissioning. Others were found during forensic investigations, usually with an engineer asking why his system protection did not perform correctly during a fault.

It is fortunate that the new microprocessor based relays can store huge amounts of data as to what happened during a fault. However, if CT's and VT's are incorrectly connected or settings are incorrect, it is not unusual for that data to show why the relay THOUGHT it was supposed to operate when it shouldn't have.

For every incident I've seen where a relay misoperated due to an internal defect, I've seen a couple of dozen where one failed to operate or operated incorrectly because of incorrect CT/VT inputs or incorrect settings.

What makes these exercises really interesting is that some of these problems go undetected for years after the system is installed, just waiting for the right combination of parameters to come along.

old field guy

 

[lz5pl]

From my experience with digital distance relays (ABB - REL521, Siemens - most of versions, Areva - P44x) I cannot remember such option as automatic reversion to preferred setting group - but it seems to be a good idea.
Of course all of them have the possibility to change the active group either via menu, either via binary input activation or via system interface.

I don't see why not to use .rio file from relay or from the software. Even if something wrong happens during the uploading of this file in test set and testing of it by current/voltage injection, at least the test engineer must review test results and check them against the expected values before to sign the test record sheets. Otherwise we as engineers will be not necessary

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[521AB]

That's the point..
the technical competence in relay protection field is drastically decreasing. (I think mainly because a new "numerical" engineer preferes other business, as too many electromechanical relays are still installed, and they certainly do not attract a new guy..) and the amount of people that are just exporting and importing the RIO file are always more and more.
Of course, the technology should always be used with the common sense, but this also what we used to say in the 80's, when "copy" and "paste" was invented. Result? How many specifications are today just the result of a "copy" and "paste" that nobody knows what is written and nobody reads?
This is the discussion I wanted to trigger. The process should require the human head, somewhere.

Regarding CT and Vt wrongly connected: the test set IS a VT and CT simulator. If correclly used (but you have to know it), you should be able to detect ALL the wrong connections. At least you are teorethically able to say: something is not correct: either the secondary connections to the relay are wrong, or the test set is wrong.

 

[dpc]

A relay on the bench connected to a test set is not going to give you any information regarding the correctness of the CT/PT connections in the field. I have inspected several relay installations where the relay had a nice new calibration/testing sticker on the front, but was completely unable to trip its breaker because the CT terminal blocks inside the circuit breaker were shorted - in one case for about 20 years. Or the trip circuit was not functional.

The only way to verify this is to inject **primary** current to at least verify that the CT is seeing current and you know the correct CT. This probably needs to be done only during initial commissioning or if CTs are replaced. You can then inject secondary current from the test switches into the relay for relay testing.

You can interrogate the relay to check the current after the system is energized, and you should do this, but it's advisable to also check beforehand.

This brings up a related point - many CT/VT wiring errors can be detected after the relay is in service by simply looking at the current and voltage data (including phase angle) that is readily accessible from the relay's front display. A quick check of this data can show most CT/PT wiring issues.

It also a good idea to install test switches for all digital relays. Many do not have drawout cases and cannot be easily field tested without proper test switches.

 

[lz5pl]

Primary current injecting is a mandatory part of commissioning tests. I do it as late as possible, when possible - in the days just before the energizing. And after that it is forbidden for everybody to touch terminal blocks (well, not so strictly, but good control after each intervention to the terminals blocks). This way I am sure that CT-ratio is OK and also the integrity of secondary circuits is also OK.

Next point - after energizing it is also part of the standard "on-load test" procedure to check and note in the Energizing Report amplitude and phase angle values of all applicable parameters. Some of manufacturers, like Siemens and VAMP has also the option to visualize vector diagram of measured values. I take screenshot of it and simply paste it in the report too.

This helps to be sure and to document that at least during the energizing relay have been properly connected.

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[subtech]

Where I a currently employed, it is agreed among relay techs (and our supervisor/engineer)for one tech or engineer/tech team to do the checkout/testing of any new installation, and upon completion make way for a second team to do a second round of testing and review.
The first team is not allowed back on site until the second team has completed their checkout. This has saved us from a surprising number of errors.
Settings revisions to an existing system are handled similarly. A tech or engineer does the initial settings change and checkout. When completed, a second tech or engineer/tech team reviews and tests again the work done by the first.
I don't know exactly who it is, but someone high up the ladder in my company has found out that the the added time and expense of sending the second team is well founded.

Also, we are forbidden to use software that "sucks" the settings from a relay and then re-installs them later.
One instance of losing service to a large critical installation brought use of that "time saving feature"
to a screaching halt!
In a sentence, we;
Checkout, review and apply settings, test, then repeat.

 

[Gestur]

Meassure the current/voltage, and include a chart recorder in your test equipent or use TFR files, include this data with the test report and many problems can be avioded.

I also meassure that there is voltage over the trip contact.

 

[lz5pl]

subtech, your company system seems really bullet-proof, but if I use it I will never get a contract! According to me it should be used for some very important installations, like nuclear power stations, but for simple projects like substations I never have seen repeat testing of relays. In most cases it would be matter not only of price but also of time. Typically commission engineers are called at site when the energizing is scheduled "for yesterday" - at least in the projects I had energized (about 50 - from 6 up to 400kV).
Probably you are working for a really big and respected company, if thay can afford themself such system!

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[subtech]

Hello lz5pl
We aren't bulletproof, but we are trying to be.
Actually, the company I work for is small.
But you are right, we are respected and I'm proud of that.
We exercise the same care and professionalism for all jobs.
Even simple substations.

 

[JBinCA]

regarding the current points of the discussion:

Subtech's method is not a bad way to go - when the economics will permit it. Unfortunately, I agree with lz5pl that the economics seldom permit it.

Fundamentally, we're talking about "human engineering" here - how can be build a process that manimizes the cahnces for human error and maximizes the chance for a successful installation.

Full Disclosure- I'm a Field Engineer, and relay testing is on of the services I sell. For what it's worth, If I were a Plant Engineer tomorrow, I'd advocate more strict testing than i typically do today.

Here's what I recommend:

1. Writting the settings file and testing the relay are one job. If you work with multiple relays and manufacturers, the tremendous variation and myriad approaches employed to perform the same function drive this. You can spend much less time learning / checking and double checking your settings if you start with your intuitive understanding of the set-up of the relay and then prove or disprove that understanding by test.

2. Test EVERYTHING that is required for the application and can be tested.

3. Do NOT make changes to the relay settings in order to make testing easier / faster. Most relays, in most applications, can be sucessfully tested without changes to the settings file made in the process. For example, instaed of turning off ground / neutral protection to inject current in one of the phases (and therefore leaving open the possibility of inadvertently leaving it off), inject the current in one phase and out the other two (in parallel). This means there is no 3Io, and therefore the neutral / ground element won't actuate.

4. Do a quick metering check and / or primary injection test when possible. Just enough to proves Instrument XFMRs and wiring. Garbage in = Garbage out.

5. Testing is only valid if the entire test was done without making changes.

6. Stroke the field devices. Do an I/O check as would be done in comissioning a PLC. Trip and close breakers, test lockout relays, test alarms, etc.

These are not hard and fast rules, but rather best practices.

Specifically regarding the OP:

The properly applied and executed set of field tests is the catch all to the entire process. If you can primary inject, and then fully test the utilized relay functions, procurement errors, wiring errors, settings file errors, grounding errors, equipment failure / DOAs, and application errors can be found. Test as much as possible, simulate as little as possible.

Regarding the Settings groups and auto-revert function - the bottom line is that there is tremendous variation among the different manufacturers, and even among the different relays of the same manufacturer. The only rule is that there are no rules.

Full Disclosure- I'm a Field Engineer, and relay testing is on of the services I sell. For what it's worth, If I were a Plant Engineer tomorrow, I'd advocate even more strict testing than I typically do today. The industry is dumbing down and thinning out due to price pressures, that makes start-up and commissioning even more crucial.

Regards,

JB



Best Regards

 

[lz5pl]

JBinCA, basically I follow the same procedure in testing. Only one difference - I make changes in configuration and/or settings, as temporary disabling of some functions not to disturb testing of others. But I keep original setting file unchanged and after complete testing I download it again back to the relay. When possible, I also prefer not to change anything, but for some complex relays it is not possible.

And of course, the main principle for me is: NEVER ASSUME! Think and read the manuals for every case when I doubt about the meaning of some parameter.

I am not surprised to find that most of colleagues have similar approach in testing - the law of Ohm is valid everywhere! That is why I am engineer, not a journalist or something similar

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant