testing of numerical relays
testing of numerical relays
(OP)
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?
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?






RE: testing of numerical relays
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
RE: testing of numerical relays
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
RE: testing of numerical relays
RE: testing of numerical relays
-------------
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
RE: testing of numerical relays
RE: testing of numerical relays
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.
RE: testing of numerical relays
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?
RE: testing of numerical relays
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.
RE: testing of numerical relays
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
RE: testing of numerical relays
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
RE: testing of numerical relays
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.
RE: testing of numerical relays
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.
RE: testing of numerical relays
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
RE: testing of numerical relays
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.
RE: testing of numerical relays
I also meassure that there is voltage over the trip contact.
RE: testing of numerical relays
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
RE: testing of numerical relays
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.
RE: testing of numerical relays
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
RE: testing of numerical relays
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
RE: testing of numerical relays
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
RE: testing of numerical relays
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.
RE: testing of numerical relays
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
RE: testing of numerical relays
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.
RE: testing of numerical relays
This is actually, according to my understanding, what the XRIO concept is aiming to..