Linking Relay Settings to the RIO blocks - OMICRON Test Universe 4.2 1

[Joshua_Mc]

Hi,

Just wondering if there was a way to link the relay settings imported from an XRIO file to the RIO blocks e.g linking PHLHPTOC1 relay settings to the RIO block with the element PHLPTOC1 in it.


Can you automate the process of typing in the Overcurrent parameters via linking it to the relay settings?

Cheers.

 

[thermionic1]

Yep-

The SW has defined RIO blocks for test modules that have a defined function (OC, Diff, Distance, etc). You can make your own links by doing the following.

In the test object (RIO), make sure under view, make sure advanced is checked. Add an OC function. IN the customer section above, add a parameter of the data type you need.

In the OC section, say pickup in the far right column is formula. Right click, add reference and point to the custom value you have created. In the OC example, remember that the SW is in PU values, so if you are in the 5A world, this is a good place to do a bit of math (setting/5).

If you have something predefined, such as a template, you can modify some things as well. There is an area called RIO plus that does much of this. I don't advise changing this unless you have saved a copy. RIO + is the bridge between the XRIO converter and the RIO links.

 

[Joshua_Mc]

Is there a better way than linking them one at a time?

Also thanks for the quick reply!

 

[thermionic1]

The better way is to have Omicron do it for you. They have several hundred of these templates available on the user area of the website.

Else find something they have that is similar and modify to suit your needs. To be honest they have their own way of testing things and I have mine. I use the XRIO converter that comes with a PTT and then add my own tests. If its a predefined module (OC/Diff, etc) the links automatically work. I start a clean document, insert their XRIO file, then add my own test modules. I test how I want, but get the benefit of (semi) automatic relay setting import and that includes the translation of each relay description of a setting into the units that the Omicron SW wants.

If you own the kit, just call and they are pretty good at support. I'm pretty sure there are videos as well on how to do what you want. Its pretty flexible and powerful.

 

[davidbeach]

I was reading a much older thread on a similar subject - what are you trying to do?

One thing that lots of people seem to want to do is to prove that a given relay will function as set. That's part of a set of tests to make prior to allowing a particular relay onto the system. Once proven that relay X with firmware Y will function acceptably there's never a need to test that again, certainly not for every installed relay. Don't confuse product acceptance testing with installation commissioning testing. Too many people do.

What needs to happen for testing once a relay is installed is different. For a feeder relay, for a line relay, for a what ever relay, there should be a set of criteria that a relay at this location in the system should do this and shouldn't do that (trip/not trip, trip with one delay vs. trip with a different delay). Totally independent of how the relay is set. For instance, if the line protection criteria is that zone 1 should be set at 85% of the line impedance, there should be multi-phase fault casess and 1LG fault cases at both 80% and 90% applied to the relay and the results evaluated. Those test points should come from the system model and have absolutely nothing to do with settings that might or might not be in the relay at test time.

The nonsense of reading settings from relays and them applying test cases based on those settings is incapable of determining if the setting in the relay are reasonable or not. A relay with the factory default settings will pass that test, but won't do well in a real world environment.

The test set, used for testing installed relays, never, never, ever, never ever, needs to know what the settings in the relay are. What's needed are a set of cases and expected outcomes. 80% of the protected line should be instantaneous while 90% of the protected line should trip at zone 2 time. Etc. Test cases based on where the relay is, not on how the relay is set. If the relay is correctly set, per the setting criteria, it will pass. If it doesn't pass, well then the testing paid off.

Testing as a next level of setting QA. Not testing as a repeat of the factory relay QA.

 

[thermionic1]

davidbeach-

I agree with what you are saying, however there are certain things one must do to either satisfy a client specification or cover one's arse. A few examples:

1) New wind farm with 20 feeders, two busses, two transformers and one Utility PCC. The testing spec is created by someone with a different philosophy (copies NETA spec). Plant is built by a developer and sold off to owner/operator. Automating the settings for the feeders makes a lot of sense as only a few things will change from relay to relay. Ditto bus and Xfmr relays. Xfmr relays part of a NERC audit so consistency is important. PCC / Line relays are often review by interconnecting utility (or at least copies of report requested). Commissioning contractors are often paid after test reports are submitted. Three years after the job is complete, something trips and plant owner (with little knowledge of protection / power systems) calls looking for explanation. I've been on both sides of this having the detailed documentation showing that things were tested comprehensively or reviewing someone else's use of some software package that a monkey could run that shows a bunch of element pickups, but nothing in terms of logic (feeders also performing BF with no delay, etc).

2) In a utility environment. Say this time reclosing didn't work as expected. Someone gets a call from a relay placed in service 2 years ago. Glad we have not only the detailed test results, but captured the SER in the test report to show everything, at the time of testing, operated as designed.

3) In a utility environment, when a contractor is utilized instead of in house labor. It's often the in house relay techs that will scrutinize the test reports. Even though there may have been a specification provided in the bid specification, it can be vague and often times doesn't matter to the relay techs reviewing, as they may have their own view on what they want to see. In this case, it's also quite beneficial to over test / over document things.

4) As you are aware, there are multiple relay vendors and relay test set vendors. Each has its own nomenclature for whatever the protective function is. Take SEL vs. GE and Doble vs. Omicron. Take a element 21, 87T, 51. What we understand as O87P is or can be described differently by the relay vendor or test set vendor in their SW. Each relay vendor may have a different equation for restraint or even something goofy like a cubic spline between SLP1 and SLP2 (talking to you GE). Some utilities and many commissioning companies may have different test sets (that you only use every year or so), or you may run into a phase in the utility where vendor XYZ was used for a time and now no longer but the asset is still in service and now protecting a new transformer and must be retested. Every try and work on a non SEL early 90's IED? (Talking to you Alstom / ABB)

I work with many relay techs from our local distribution companies that also serve the transmission operator. Goods guys, but I also see many different personalities and testing philosophies. Maybe for them it's a CYA or "I get paid by the hour". Just last week I had this discussion with a very good relay tech and we both agreed that we are very, very unlikely to catch something wrong in a SEL-411L algorithm that wasn't thoroughly put through its paces at SEL R&D or RTDS.

Our Transmission company has a standard line package (or is trying to get there), as well as standard bus package, transformer package, etc. As a result, I have pretty good templates to cover these. Once I've seen the deviations of these and create my own iterations, it doesn't take too much effort to create a complete test that covers what's required and not touch a single thing in the relay during the test. That gives me more time to deal with the one incompetent person in the SCADA department the refuses to turn in their homework in a timely manner.