Microprocessor Relay Testing 1

[wbd]

Hello Everyone,
I would like to ask everyone's opinion and references on the frequency of testing microprocessor based and solid state relays. The type of testing is using a relay test set, not just the self-test feature of the relay.
With electro-mechanical relays, I've been testing them on a yearly cycle but the others I have been depending on the self-test feature.
I'm also limited by the test set (Multi-Amp SR-76) and am trying to get in the budget a newer test set and need some justification.
Thank You in advance.
wbd

 

[jghrist]

We have specified six years for microprocessor relays that have self-tests. See

http://www.selinc.com/techpprs.htm

for a paper "Philosophies for Testing Protetive Relays" that gives a method to select the optimum testing interval. SEL also says that meter checks and input/output tests only are required; characteristic & timing checks are not necessary.

 

[peterb]

wbd -
What I have been recommending to clients who are moving from an electromechanical to a microprocessor environment is that they start with a two year interval and then increase that as they get comfortable with the new technology and see the trend of test results over time.

You didn't say what type of relays you are testing, but I would infer from your use of the SR-76 test set that they would be mainly overcurrent and maybe differential relays. The basic tests for these won't change much whether they are electromechanical or microprocessor, so a test set with more bells and whistles may not be warranted on that basis alone. On the other hand, if you are getting into some more exotic areas such as playback of fault recordings from microprocessor relays, then a high tech test set is definitely in order (I recently isolated a transformer differential trip application problem using fault recording playback on a Pulsar test set - great feature, with a lot of practical utility).

jghrist - while I have the greatest respect for SEL as an ethical company and for their products, I don't think that I would take any manufacturer's say-so to replace prudent engineering practice for calibration checks. I agree with you in principle (it's all firmware and monitored hardware when you get past the analog/digital conversion), but I will continue to recommend calibration testing. As an aside, I recently came across some older (1994) SEL relays that had to be replaced because of drift that could not be corrected by calibration - admittedly, this is a rare exception involving slightly older analog-based technology rather than today's all-digital relays, but it does make the point.

 

[jghrist]

While I accept what SEL says in principal, I also specify calibration and timing tests. You probably couldn't get AVO to make a similar recommendation.

It's hard to break old habits even if they may not be completely rational. It is possible that the increased probability of a relay error and outage while testing and depending on backup (although extremely small) may be greater than the probability of a relay error causing a problem if left untested. Not really worth figuring out.

 

[peterb]

Another point worth making is that there is more than just calibration of the microprocessor relay involved in the maintenance exercise. You absolutely need to verify the integrity and operability of the CT/VT circuits and, most critical, of the trip circuit as a whole - you need to verify that the trip signal does go all the way through.
All of these factors may dictate a shorter maintenance interval than would be required for the relays alone.

 

[busbar]

One approach may be to get a basic two-channel amplifier-driven test set with manual control, and add a similar second and third later. One consideration not to leave behind is the instrument having adequate compliance to fully test existing electromechanical relays. Some reps are given new equipment by their manufacturers—a 14-30 day loan may be a negotiable proposition, especially if the rep senses your serious interest.

Software is a major commitment for a number of reasons. Although relatively expensive, rental of test sets may allow for ‘evaluation’ of sorts. It’s not real common, but used equipment becomes available at times, and sometimes changes hands rather quickly, so you may have to convince procurement to be a bit more flexible to accommodate this.

Whether your management cares or not, a variac/tapped-transformer test set can drive you mad trying to test numerical relays.

 

[Bung]

Peterb raises avery good point. We have had experiences of numeric relays driving big old trip coils and trying to interrupt the trip coil current. Result: vaporised trip contacts on those teenie little trip relays in the protection relay. Point is, you can't see it and you may not even know about it especially if the CB pallette switches did finally change state. Happened once where we didn't pick it up, and on a subsequent fault the relay tried to trip, but couldn't close its non-existent trip contact. We lost the bar on CB fail (another advantage of numeric relays - lots of useful extra functions).

We test at 3 year intervals, cycling an operational check with a full calibration. A properly cleared fault is taken as an operational check. All watchdogs are monitored via SCADA. All checks exercise full system from instrument transformer secondaries to CB trip.

BTW, we now use the SEL contact arc suppression devices, and have had no further problems with relay contacts.


Bung
Life is non-linear...

 

[GordS]

My approach to relay testing has been based on criteria given in a text titled "Reliability Centered Maintenance". Testing frequencies can be shown to be a function of relay failure rate, incident rate (eg how often does a motor fail) and acceptable consequence. The first two can be obtained from texts of experience. The third variable is usually given as the desired acceptable frequecy of protection being failed when called upon to protect. As an example, for personnel safety, we want the probability of a relay failure at the time it is called upon for protection to be remote. In my case, we have defined remote probability events as once every 200 years which defines my aceptable consequence. As a result, relay testing frequency becomes dependant on the relay function. As an example, motor protection, where the impact is motor loss and production impact, ends up with a testing frequency of 3 years. A switchgear relay that may be called upon to protect a person in contact with bus is tested yearly.

For microprocessor relays, my approach has been:
1. One test to confirm that the logic is functioning correctly (eg a timing test)
2. Test all of the A/D conversions. This is basically current / voltage injection and noting the displayed currents / voltages.
3. Trip test - confirm the relay trips its final device.
4. Test of instrument transformers.

 

[Bung]

The problem with an analytic approach to calculating testing periods is the lack of useful data. Most of our failures on uP relays have been some firmware bug or other, so once fixed won't crop again, and should not feature in future statistical tests. Also, the cost of non-operation is a dangerous number to calculate (remember that car with that bolt above the fuel tank... cost of pay-outs was factored into decision not to recall, and so court factored that into damages calculation).

In any case, personnel safety is still only a secondary function of protection - it is there to get the fault off before it becomes any more of a problem to personnel and plant than it already is. If the person was the source of the fault, well sorry mate, but he's probably dead anyway. So attaching meaningful numbers here is pretty haphazard.

I have tried to do these kinds of calculations, but I believe that they are ultimately only useful as one of the factors used to guide you to a decision - to illuminate the problem, not as teh sole basis of any decision.

Bung
Life is non-linear...

 

[jbartos]

Suggestion: Visit

http://www.selinc.com/techpprs/6000.pdf

The nowadays digital relays have self-testing feature, monitoring, reporting, etc., therefore, their routine testing is less significant. The electromechanical and solid state relays routine testing and maloperations were indicators of potential problems.

 

[johnspark]

Comment:
Relay testing and relying upon the relay to let you know if it is in trouble:
Only trouble with self testing by the relay itself is that we had a P44x series Alstom relay that had the potential to stop working after a few weeks from maintenance testing, without making the internal relay failure contact operate. (It was a firmware problem). So we only became aware of the potential problem courtesy of Alstom letting us know.
Of course this can happen with other relays by other manufacturers. (We appreciated Alstom letting us know in advance of any potential relay failure).

 

[GordS]

Analytic methods of calculating testing interval do suffer from lack of data and would not pass a rigorous statistical analysis. This is especially true with the newer uP relays. However, what is the alternative?

I would disagree that protection of people is a secondary function of protection. It is well documented that a persons chances of survial are improved if the exposure time to voltage decreases. A relay failure that requires back-up relaying to clear a fault is much more likely to kill someone.

 

[sparky1976]

Bung comments about bug in firmware are some thing should monitor continously from relay manufacturer website for firmware upgrade. I experince that several times with GE Multilin.