Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
XRIO format for relay testing 1
- Thread starter 00123456
- Start date
To what I know, XRION stands for "Extended RIO".
One example of XRIO is one file that Omicron Software reads and contains a sort of "application". Once it is open (you are always inside the Omicron software), you are requested to enter the settings of the relay associated to that XRIO file. Then the "application" automatically draws the characteristic (I am talking about distance protection) starting from the settings that you have entered. So in Omicron they make the RIO file by themselves..., without needing to import any RIO file.
One example of XRIO is one file that Omicron Software reads and contains a sort of "application". Once it is open (you are always inside the Omicron software), you are requested to enter the settings of the relay associated to that XRIO file. Then the "application" automatically draws the characteristic (I am talking about distance protection) starting from the settings that you have entered. So in Omicron they make the RIO file by themselves..., without needing to import any RIO file.
- Thread starter
- #4
Thanks 52AB, IS OMICRON instrument detecting relay settings from any numerical relay automatically? & it is creating distance protection characteristics? Or we need to enter relay settings (say Z & angle, R & X etc.)in software & it is creating XRIO?
XRIO is an extension of RIO. The 'X' stands for extended. To my knowledge, there are some relay manufacturers (ABB & Seimens) that will directly export their settings in the RIO/XRIO format.
What does this mean? Well for a multi-zone distance protection, all of the zones and delays that are in the relay are also read by the test set. This allows the Omicron SW to be able to define the testing parameters (reach and timing).
For some more complicated schemes (DCB, POTT, etc), user intervention is required to define the logic tests. The XRIO file does not contain information regarding the logic mapping of the functions to output contacts.
What does this mean? Well for a multi-zone distance protection, all of the zones and delays that are in the relay are also read by the test set. This allows the Omicron SW to be able to define the testing parameters (reach and timing).
For some more complicated schemes (DCB, POTT, etc), user intervention is required to define the logic tests. The XRIO file does not contain information regarding the logic mapping of the functions to output contacts.
Thanks 52AB, IS OMICRON instrument detecting relay settings from any numerical relay automatically? & it is creating distance protection characteristics? Or we need to enter relay settings (say Z & angle, R & X etc.)in software & it is creating XRIO?
What I have seen, you have to manually enter the settings. Settings should come from the setting document, and not from the relay itself (from the front screen or from the seting software tool after you just did a READ ALL....). in order to detect eventual setting errors in the relay. Very good concept, I think.
What I have seen, you have to manually enter the settings. Settings should come from the setting document, and not from the relay itself (from the front screen or from the seting software tool after you just did a READ ALL....). in order to detect eventual setting errors in the relay. Very good concept, I think.
- Thread starter
- #7
Thanks 521AB for information.
If i need to enter relay settings manually (Read from relay front screen or setting software) in "testuniverse" software & it is creating XRIO file then what it does really make any sense? My understanding is; this feature is similar to looks like as a ISAWIZARD software. If you can see the special distance module in ISAWIZARD (ISA make)software (which can able to commuinicate with DRT6), they have given the same feature in different way. We just need to select relay model (say; MICOMP442, or REL511 or 7SA522 etc.) & it is automatically creating relay characteristics.
Same thing we made RIO converters in VB with EXCEL CONTROL for somany relays (RAZFE, LZ92, LZ96, YTG31, REL100, REL521, P442, P443, 7UT512, 7UM612, SEL311, SEL387, SHPM130, MBCH, KBCH, OMEGA420, SHNB, SPAD346 etc.)& we are just entering the relay settings from screen or setting software & it is creating RIO files those file we are importing in testing softwares & we are doing steady state relay testing.
Thanks
If i need to enter relay settings manually (Read from relay front screen or setting software) in "testuniverse" software & it is creating XRIO file then what it does really make any sense? My understanding is; this feature is similar to looks like as a ISAWIZARD software. If you can see the special distance module in ISAWIZARD (ISA make)software (which can able to commuinicate with DRT6), they have given the same feature in different way. We just need to select relay model (say; MICOMP442, or REL511 or 7SA522 etc.) & it is automatically creating relay characteristics.
Same thing we made RIO converters in VB with EXCEL CONTROL for somany relays (RAZFE, LZ92, LZ96, YTG31, REL100, REL521, P442, P443, 7UT512, 7UM612, SEL311, SEL387, SHPM130, MBCH, KBCH, OMEGA420, SHNB, SPAD346 etc.)& we are just entering the relay settings from screen or setting software & it is creating RIO files those file we are importing in testing softwares & we are doing steady state relay testing.
Thanks
Yes, it i similar to ISA idea. Completely right. I never thought about it but you are right. Actually ISA came up with this idea first, to be honest....
The idea is quite simple: you do not enter the settings manually because you "copy" them from the relay HMI. You enter the settings manually because you get them from the setting document!
I am sure, by doing this, you will find a lot of setting mistakes in your relays!
If you automatically read the settings from the relay, or you get a RIO file that is generated by one tool that is reading the settings from the relay, the RIO file is correct from the settings point of view, but if they are wrong, the RIO file is also wrong... the problem is that nobody notices it!
As alternative what do you want to do? Take the setting document (paper) and check the settings, one by one, with the relay front HMI?
The idea is quite simple: you do not enter the settings manually because you "copy" them from the relay HMI. You enter the settings manually because you get them from the setting document!
I am sure, by doing this, you will find a lot of setting mistakes in your relays!
If you automatically read the settings from the relay, or you get a RIO file that is generated by one tool that is reading the settings from the relay, the RIO file is correct from the settings point of view, but if they are wrong, the RIO file is also wrong... the problem is that nobody notices it!
As alternative what do you want to do? Take the setting document (paper) and check the settings, one by one, with the relay front HMI?
XRIO functionality 101, as I see it:
An XRIO converter can import a data source, possibly from 3rd party software, the relay setting software. The same XRIO converter can also use manually inputed data.
Broadly the XRIO converter manipulates this data into meaningful quantities. That is to say it takes raw line data/setting quantities and produces relevant test values. Similar manipulation could be done in an Excel spreadsheet, but that would exist outside of the occ.
Important to note is not just mathematical manipulation capability, but also conditional capability, - "IF...Then" ability, as well as boolean logic.
The XRIO convertor is produced by the relay tester who tailors it to his own specific test plan and relay application. All previous functionality is still available, and a tester could continue in blissfull ignorance of the XRIO capabilities as before.
To continue, the manipulated XRIO quantities are 'linked' to fields in actual test modules. There is a vastly greater number of fields that are available for this linkage, than previously existed with the 'RIO' functionality. Important to note is these linkages are also available to test modules that were not governed by the RIO test object. Eg ramping and sequencer modules. Furthermore it was not possible to have more than one RIO functional block, eg distance, overcurrent etc in a RIO file, in XRIO it is. So now only one test object is required, if for instance the relay has several types of conditional overcurrent or distance characteristic alternatives simultaneosly available within the protection.
Eg parameter changeover or emergency overcurrent etc.
Also important is that these linkages are done in a relative manner.
I will use a simple example to demonstrate.
To check a relay's current pickup level.
The setting is 1 * IN.
Inom is 5Amp.
Data input fields are is 1*In, and 5Amp. (the meaningful value in absolute current for the current pick up is 5A).
It is the tester, who programmes the 2 simple input fields and also creates a 3rd meaningful output field that he equates to the product of the two input fields. He then links (fixes relatively) the value of the output field to the ramp starting current value, the expected value, the tolerances, as well as ramp stop value, in a relative manner.
Eg:
The start of the current ramp is 0.9 * Third field value =4.5A
The expected value = Third field value = 5A
Minus tolerance = 5% of Third field value = .25A
Plus tolerance = 10% of Third field value = .5A
The stop of current value should a trip not be sensed = 1.5 * Third field value =7.5A
This is a very simple example of an XRIO convertor but as you can see, the XRIO convertor populates the test plan right down to the injection quatities. The XRIO is part of the occ file. If for example, the next relay of a similar type now has a setting of 2In and a 1Amp Inominal. The same occ file complete with existing XRIO is used as a template. A name change and two quick changes and all five fields in the test plan are adjusted accordingly relative to the new settings.
No value had to be manually adjusted in a actual test module itself.
This may sound simplistic, and it is. It is fully appreciated when for instance the relay has four frequency levels, 2 overvoltage, 2 undervoltage and df/dt and all pickups and drop off are to be tested. Then literally the adjustments of a handful of settings can affect thousands of actual test module fields.
Then XRIO becomes a massive time saver and there is never any finger problems, which of course there would be if thousands of fields had to be manually adjusted.
In conclusion for once-off test just test the relay as you have done previously.If multiple complex relays of the same type are to be tested. Then the time spent developing an XRIO convertor is generally recouped after about 3-4 relays.
After that the time spent testing a complex relay is halved or realistically even less.
To address the settings errors, using the relay itself as the data source is indeed insecure, and will perpetuate setting errors.
However the test plan designer could use line parameters as an XRIO data source instead of relay settings if he wished. Programs like CAPE can be used to inface with DIGSI and omicron directly, hence the the test kit and the relay have received their input data by via a parallel source, both without human intervention and can cross check each other.
These issues are real but, can be addressed easily in your way of working.
As regards mapping of output contacts:
This functionality is easily achieved. Take for example a distance relay that could be either PUTT or POTT.
Remember you are no longer limited to one distance test object block.
So in my occ file I have an advanced distance module that receives its characterics from distance block(1) and my relative shots pre-programmed. That is as per usual, prior to XRIO.
However, I have a second advanced distance module, again with relative shots pre-programmed, but this time with a logic output (Carr. Receive) pre-programmed aswell. The distance characteristic that pouplates this module is from distance block(2).
Ah!, but you say a POTT and a PUTT have completely different responses to the logic input. Well, of course they do, but this is where the conditional logic of the XRIO applies, the characteristic of distance block(2) is conditionally created different depending of whether the XRIO is told it is a POTT or a PUTT.
In other words logic outputs dont need to be manipulated, they would be pre-inserted into the template test plan. It is the characteristic expected response that populates these pre-programmed modules that is conditionally manipulated by the XRIO convertor.
An XRIO converter can import a data source, possibly from 3rd party software, the relay setting software. The same XRIO converter can also use manually inputed data.
Broadly the XRIO converter manipulates this data into meaningful quantities. That is to say it takes raw line data/setting quantities and produces relevant test values. Similar manipulation could be done in an Excel spreadsheet, but that would exist outside of the occ.
Important to note is not just mathematical manipulation capability, but also conditional capability, - "IF...Then" ability, as well as boolean logic.
The XRIO convertor is produced by the relay tester who tailors it to his own specific test plan and relay application. All previous functionality is still available, and a tester could continue in blissfull ignorance of the XRIO capabilities as before.
To continue, the manipulated XRIO quantities are 'linked' to fields in actual test modules. There is a vastly greater number of fields that are available for this linkage, than previously existed with the 'RIO' functionality. Important to note is these linkages are also available to test modules that were not governed by the RIO test object. Eg ramping and sequencer modules. Furthermore it was not possible to have more than one RIO functional block, eg distance, overcurrent etc in a RIO file, in XRIO it is. So now only one test object is required, if for instance the relay has several types of conditional overcurrent or distance characteristic alternatives simultaneosly available within the protection.
Eg parameter changeover or emergency overcurrent etc.
Also important is that these linkages are done in a relative manner.
I will use a simple example to demonstrate.
To check a relay's current pickup level.
The setting is 1 * IN.
Inom is 5Amp.
Data input fields are is 1*In, and 5Amp. (the meaningful value in absolute current for the current pick up is 5A).
It is the tester, who programmes the 2 simple input fields and also creates a 3rd meaningful output field that he equates to the product of the two input fields. He then links (fixes relatively) the value of the output field to the ramp starting current value, the expected value, the tolerances, as well as ramp stop value, in a relative manner.
Eg:
The start of the current ramp is 0.9 * Third field value =4.5A
The expected value = Third field value = 5A
Minus tolerance = 5% of Third field value = .25A
Plus tolerance = 10% of Third field value = .5A
The stop of current value should a trip not be sensed = 1.5 * Third field value =7.5A
This is a very simple example of an XRIO convertor but as you can see, the XRIO convertor populates the test plan right down to the injection quatities. The XRIO is part of the occ file. If for example, the next relay of a similar type now has a setting of 2In and a 1Amp Inominal. The same occ file complete with existing XRIO is used as a template. A name change and two quick changes and all five fields in the test plan are adjusted accordingly relative to the new settings.
No value had to be manually adjusted in a actual test module itself.
This may sound simplistic, and it is. It is fully appreciated when for instance the relay has four frequency levels, 2 overvoltage, 2 undervoltage and df/dt and all pickups and drop off are to be tested. Then literally the adjustments of a handful of settings can affect thousands of actual test module fields.
Then XRIO becomes a massive time saver and there is never any finger problems, which of course there would be if thousands of fields had to be manually adjusted.
In conclusion for once-off test just test the relay as you have done previously.If multiple complex relays of the same type are to be tested. Then the time spent developing an XRIO convertor is generally recouped after about 3-4 relays.
After that the time spent testing a complex relay is halved or realistically even less.
To address the settings errors, using the relay itself as the data source is indeed insecure, and will perpetuate setting errors.
However the test plan designer could use line parameters as an XRIO data source instead of relay settings if he wished. Programs like CAPE can be used to inface with DIGSI and omicron directly, hence the the test kit and the relay have received their input data by via a parallel source, both without human intervention and can cross check each other.
These issues are real but, can be addressed easily in your way of working.
As regards mapping of output contacts:
This functionality is easily achieved. Take for example a distance relay that could be either PUTT or POTT.
Remember you are no longer limited to one distance test object block.
So in my occ file I have an advanced distance module that receives its characterics from distance block(1) and my relative shots pre-programmed. That is as per usual, prior to XRIO.
However, I have a second advanced distance module, again with relative shots pre-programmed, but this time with a logic output (Carr. Receive) pre-programmed aswell. The distance characteristic that pouplates this module is from distance block(2).
Ah!, but you say a POTT and a PUTT have completely different responses to the logic input. Well, of course they do, but this is where the conditional logic of the XRIO applies, the characteristic of distance block(2) is conditionally created different depending of whether the XRIO is told it is a POTT or a PUTT.
In other words logic outputs dont need to be manipulated, they would be pre-inserted into the template test plan. It is the characteristic expected response that populates these pre-programmed modules that is conditionally manipulated by the XRIO convertor.
"Yes, it i similar to ISA idea. Completely right. I never thought about it but you are right. Actually ISA came up with this idea first, to be honest....
"
ehrm...ISA is not exactily known in the business for inovating new ideas, rather borrowing from others.
The original RIO idea dates back to the cooperation between Siemens and Omicron (15+ years ago). ABB eventually adapted this format. Programma got on board, etc.
The idea of RIO/XRIO is to take the settings (characteristcs ) of relay and make them some what standardized.
There is muc talk of doing this with IEC 61850 as well for relay testing.
"
ehrm...ISA is not exactily known in the business for inovating new ideas, rather borrowing from others.
The original RIO idea dates back to the cooperation between Siemens and Omicron (15+ years ago). ABB eventually adapted this format. Programma got on board, etc.
The idea of RIO/XRIO is to take the settings (characteristcs ) of relay and make them some what standardized.
There is muc talk of doing this with IEC 61850 as well for relay testing.
-
1
- #12
" ...ehrm...ISA is not exactily known in the business for inovating new ideas, rather borrowing from others...."
I don't want to defend/promote anybody. I'm just trying to be as correct as possible.
ISA didn't develop any RIO file importer (they have it now). In the beginning (1999 ... 2000, before I don't know) they had developed some ".exe!" applications. Each application needed (and needs, they are still available) a manual entering of the settings and than ISA SW could draw the distance protection characteristic of the relay from the settings.
The RIO file concept (who really "took-off" some years after 2000) removed the needs for those small applications.
Anyway when I saw that, nobody had done it (Omicron had the RIO importer, Programma had some Excel files that could eventually generate the RIO file that it should have been imported by Freja SW, Doble didn't have it.. only ISA had it. They took the responsibility to draw the characteristic of the relay in their own software. The XRIO is doing a similar concept.
And regarding innovation: who has a distance protection search function like in ISA? Not to defend ISA, but they are doing their job, like everybody.
The difference between RIO and XRIO is huge. In the RIO, the test set software just imports the characteristic, which is supposed to be generated by the relay manufacturer (generally the software tool). In XRIO, no matter how the settings are entered, the characteristic is drawn by the test set software. Are the manufacturers involved in this? Who checks that the characteristic is really drawn correctly? (same concept was valid for ISA at that time? WHo "told them" that the characteristic was really the one they have drawn?).
RIO specification is "freeware". If you ask it at Omicron, they send it to you. I think this is a very nice move from Omicron, towards all the technical community.
I don't want to defend/promote anybody. I'm just trying to be as correct as possible.
ISA didn't develop any RIO file importer (they have it now). In the beginning (1999 ... 2000, before I don't know) they had developed some ".exe!" applications. Each application needed (and needs, they are still available) a manual entering of the settings and than ISA SW could draw the distance protection characteristic of the relay from the settings.
The RIO file concept (who really "took-off" some years after 2000) removed the needs for those small applications.
Anyway when I saw that, nobody had done it (Omicron had the RIO importer, Programma had some Excel files that could eventually generate the RIO file that it should have been imported by Freja SW, Doble didn't have it.. only ISA had it. They took the responsibility to draw the characteristic of the relay in their own software. The XRIO is doing a similar concept.
And regarding innovation: who has a distance protection search function like in ISA? Not to defend ISA, but they are doing their job, like everybody.
The difference between RIO and XRIO is huge. In the RIO, the test set software just imports the characteristic, which is supposed to be generated by the relay manufacturer (generally the software tool). In XRIO, no matter how the settings are entered, the characteristic is drawn by the test set software. Are the manufacturers involved in this? Who checks that the characteristic is really drawn correctly? (same concept was valid for ISA at that time? WHo "told them" that the characteristic was really the one they have drawn?).
RIO specification is "freeware". If you ask it at Omicron, they send it to you. I think this is a very nice move from Omicron, towards all the technical community.
It's more clear to me now what this XRIO is.
It provides also a standard file format for the relay settings. If you test just one relay or one protection function it can be Ok to manually enter the settings in the XRIO convertor, but testing multifunctional relays, with automatic test programs, it is simply impossible to enter the settings manually.
It provides also a standard file format for the relay settings. If you test just one relay or one protection function it can be Ok to manually enter the settings in the XRIO convertor, but testing multifunctional relays, with automatic test programs, it is simply impossible to enter the settings manually.
- Thread starter
- #14
- Status
Similar threads
- Question
- Locked
- Question