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?

 

[JBinCA]

lz5pl's reply reminded me of something.

If settings must be changed during the process of testing, most relays have a "compare" function that will give you a list of the differences between the settings in the relay and the settings in the file. This should be used prior to reloading the file to ensure that the only differences are those that were intentionally created during testing.

In the case of relays that lack this function, or where the function is non-intuitive (as is the case, regrettably, with a few of my company's relays), it's a good idea to become familiar with working with the relay files in text form. SEL, GE Multilin, and Basler's multifunction relays all save their settings in a text based format (as, I understand, do others). This means that the job of comparing relay settings files is really a job of comparing text files. Excel can be made to show differences by putting the settings of two relays in adjacent columns and using an equation in a third that looks for differences.

I recommend Beyond Compare, available at:

http://www.scootersoftware.com/moreinfo.php

$30 USD and you'll never regret it if you get in the habit of comparing text files - even occasionally.

By the way, when lz5pl says that he keeps the originial file unchanged, that is a key point. It's a point that seems self evident, but there are some best practices here as well. Most of the programs used to create/edit settings files make their changes to a working copy of the file and will only save to the permanent copy when you tell them to (This is what you would expect, and follows what most windows based programs do). Others, however, save changes as they are made to the permanent file. This means you could inadvertantly be overwritting your file unless you take precautions against doing so.

You need to have a copy of the file somewhere that the program is unaware of and that you only go back to when you need to verify that things haven't changes since that file's creation.

Best Regards,

JB

 

[DTR2011]

Gentlemen-

First I must say that this is a very well discussed post. It is good to see that many people still consider the art and science of relay testing / power systems commissioning important. With that said, I will offer my $0.02...

Although it is desirable to test a digital relay without changing the settings, I can offer a few instances where this may be required. I am not endorsing this practice only pointing out the difficulties.

You are testing a generator digital relay. You are to test the 46 (Neg Seq O/C) element. Your test set has 3 currents and diff keeps tripping (which is mapped to the same output). It could just as easily be U/V.

You are interested in the pick-up (start) of the relay element and the relay does not have a dedicated 'start' contact.

We've probably all seen this and have adapted our own methods for testing. If you are fortunate enough to have a modern test set with multiple sources, that makes like easier, however, depending on the SW application, the calculation of the additional 'mirror' currents which would prevent the diff element from operating are tedious to calculate and that is assuming that the relay manual even gives a procedure.

On that note, how many relay manuals, as part of their own procedure recommend changing the settings to some system default.

Years ago, when I was green, I would have followed these procedures in the book, due to being overwhelmed by the new technolohy and my lack of experience. But, I was taught in relay school 101 to always follow the relay manual.

As far as the RIO files, one has to be careful in this area. I think we have all heard horror stories about 'automated SW' that sucks in settings, changes the relay logic and is supposed to place the settings back. I'd be careful with this approach for many reasons. A slightly better approach would be that the settings file is fed to both the relay test SW and the relay. The basic element test results and the expected tripping logic would confirm that both are in harmony. The difficulty in this approach is that there are so many different versions of IEDs these days and with each comes several different firmware versions. I do endorse the compare functions of the IED SW as a double check.

I think a good thing mentioned here is that the tester has the have a fundamental understanding of what the heck they are doing. I seen a lot of emphasis on pre-developed templates that are supposed to be the 1-button solution for testing a complex relay. #1 this can never be a 100% solution and #2 this really does nothing to help our industry that is in desperate need of good power engineers.

I remember testing a 161kV panel that had electro-mechanical distance, reclosing and pilot wire a few years back. The level of complexity in the schematics alone was far more difficult than the relays. In contrast, a modern DC circuit for an IED is very straightforward. The user must understand the internal logic of the relay much better and that my friends can only come through an organic process called relay testing.

Good Day.

 

[slavagar]

Dear Colleagues.
I would like continue with this post.
Test of numerical relays today it is very important point.
But I also see some different between first commissioning
of numerical relay and maintenance test of numerical relay,
We recommend to customer maintenance test once in 5-6 years,in 10 years full relay test. If numerical relay connect to some SCADA system maintenance in 6-7 years.
What do you think about it, what is your experience.
Thanks

 

[521AB]

I would like to thank all of you for your participation here, but I think you went too much out of topic. I recognize the need of a discussion on testing numerical relays, both commissioning and maintenance procedures, but in my opinion we should do it in different topics. Not here.

Here I was very precise, in my first message, and I was discussing the "theory" of the RIO file itself.
I'll summarize again:

you go in front of the relay
you read all the settings from the relay from the software tool
you generate the RIO file (export the RIO file)
you import the RIO file from the test set software
you connect the test set to teh IED (maybe you have the automatic test switches/handles, so this is very easy)
you run the test
EVERYTHING is OK, but you have missed that some settings were completely wrong.


Considering the fact that:
- competent relay enginneers are disappearing from this planet (Ok, let me say Europe)
- time allowed to test (wrong or not) is always less

in my opinion the RIO file idea, brings to troubles, if applied passively.

I don't want to say that the trouble is in the RIO file concept, but it is in how people do apply this tool, and it should be maybe good to break this automatic chain and put one formal moment where the "head" of the tester is requested. I.E. entering the settings manually in the test set software and settings should come from setting document (paper or pdf file). No setting document available --> no testing.

This was the maning of my topic.

For the issues named in the beginning, I am going to open different topics.

 

[521AB]

".....I don't want to say that the trouble is in the RIO file concept, but it is in how people do apply this tool, and it should be maybe good to break this automatic chain and put one formal moment where the "head" of the tester is requested. I.E. entering the settings manually in the test set software and settings should come from setting document (paper or pdf file). No setting document available --> no testing......"


This is actually, according to my understanding, what the XRIO concept is aiming to..