IEC61850 3rd part engineering tool 1

[521AB]

As far as I have been able to understand there are today two types of IEC61850 engineering tools available on the market: ABB (called IET or CCT) and Siemens (Digsi).
Are you aware about any third part IEC61850 engineering tool?
Thanks

 

[dede61]

JBinCA,

I coundn't agree more, I also feel this is a missed oppertunity. When I speak with different manufactures, they all consider that they have found the one and only solution and all other fail to prefrom. I feel there is a lot of protection from the manufactures, in this way the customer gets more and more connected to the products of one specific manufacturer. Implementing IEC61850 doesn't change this. I know for one case where the manufacturer would have withdrawn the warrantee on the compleet system if the customer would choose a different brand of IEC61850 switch (even if it was certified IEC61850).

 

[lz5pl]

I don't think that 61850 is intended to standardize relay settings structure. It is developed (if I am not wrong) just to make works on control system engineering easier by establishing only one common standard protocol. Inter relay communications in general case are not necessary for protection functions (excluding busbar protection), they just can simplify some logic functions which up to now were executed by hardwired contacts and binary inputs.
Therefore I don't think that we should expect such standardization for protection setting menu.

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[521AB]

Guys,
I think you are not fair on that.
I want to comment this, even if not completely pertinent with my original message -(
As long as we talk about simple protection functionality, overvoltage, overcurrent etc., it is maybe possible to standardize. But when we talk about higher performances, directionality discrimination, harmonics detection.... fault type detection..., distance protection..., autorecloser with 10 different shots etc..... every manufacturer uses its best knowledge to achieve the protection task (which is NOT an exact science!).
So if one manufacturer has 25 settings for distance protection, and another one has 50, you cannot say that one is better of another one, untill you see how the relays really perform, and you cannot force the "50-setting manufacturer" to use only 25. It would not be technically fair.
I believe (and I hope it will never happpen) that it will not be possible to standardize the settings. UNLESS we just standardize the FORMAT of exporting the settings (from the protection device or from the software tool). For instance in XML format well defined, no matter how many they are.
This is already coming-up, so we will see..

 

[JBinCA]

I would tend to agree with at least part of what 521AB is saying. I think if there ever is a standard on relay settings, it will likely pertain to the more basic protective functions first.

I still don't see what would prevent adoption of a standard, however. We've been able to develop standards pertaining to power system protection (eg IEEE 242, and others in the color book series), why would we not be able to develop standards pertaining to how the protection standards are implemented?

Think about the current effort that could be eliminated by this. SKM, Easypower, and the like could export settings files (or more likely partial settings files) in the standard format. The relays could be loaded directly with this file. If the standard included register mapping for common energy and power quality values, SCADA and HMI software suites could be made to automate the set-up of logging and displays based upon the standard. Test set manufacturers could provide auto-test functionality that was based upong reading relay settings in this standard format.

On that last point, I know that Megger is working on keying their auto-test functions off of information gleaned from relay settings files. I'm not sure how far along they are, but Since most Multifunction relays have text based settings files (GE, Schweitzer, and Basler all do), it's fairly straightforward to decode. I believe that they are focussing their energy on the more simple protective elements.

 

[JBinCA]

521AB,

Your points seem like they form an argument against standardization in any area that is complex or difficult.

I would argue that these are the areas where we should wan't standardization the most.

Wouldn't you be more inclined to specify / buy relays that were programmable by a well developed standard? What about meters? What about PLCs? I think the point of standardization is that it is an advantage to the user, not the manufacturer.

I would certainly not want the standardization process to result in lowering quality, and I don't think it needs to. Even if the settings were standardized, I would expect individual manufacturers to continue to use their own algorithms to employ those settings.

I am interested in your thoughts on this, but am especially interested in keeping the discussion alive. I'll start a new thread soon to continue the conversation.

Best Regards,

JB

 

[521AB]

JBinCA,
I am NOT against the standardisation when it is difficult. I am against the standardisation where it doesn't help or where it flattens the development.
For me, if you say "standardisation of relay settings" I understand that an autorecloser must have 10 settings, not one more, not one less.
Directional overcurrent protection must have 12 settings, not one more, not one less. Distance protection should have 15 settings etc.
If this is what standardisation means in the protection settings, then I am completely in disagreement.
If we mean: "let's standardize how settings are stored in the boxes, so that everybody in principle can read them and change them", I completely agree with this.

Suppose that tomorrow I invent one protection relay that automatically learns from other relays, that will be removed after some time. There are zero settings there (in principle). If you standardize the settings, you kill the development. people are lazy..

 

[slavagar]

Hi.
Somebody have expirence with 61850. I'm know about GE, ABB, Siemens and Areva projects. But I'm understood all projects are with vertical communication. Somebody know something about real project with GOOSE messages.

My opinion about standardisation:
1. IEC61850 is good idea. End of end we (customer) can use standard convertors, switchs and SW for IED connection from several companies. Classic example Modbus RTU.
2. GOOSE messages between several types of IED is also very
important ( but I think it's avil in next type of relay).
But NOT standards for protective relay functionality and settings. 521AB is right, we kill devolpment.

 

[slavagar]

Hi.
If we discuss about GOOSE messages, I would like ask your opinion about:
Interlocks between bays by GOOSE only or by HW also.
Used GOOSE messages for BFP in MV swg.
Automatic transfer switch ( between two infeeds and couplers for example) by GOOSE messages only.
What do you think about used IEC61850 ( in future) for meas data, for example send voltage from BB VT to bay's via 61850 network

 

[521AB]

Hi.
Somebody have expirence with 61850. I'm know about GE, ABB, Siemens and Areva projects. But I'm understood all projects are with vertical communication. Somebody know something about real project with GOOSE messages.

Not true, some years ago (last or 2 years ago, in the states, ABB, AREVA, GE Siemens and I also think SEL (alphabetic ordedr, please note) DID exhange succesfully goose messages together. It was a customer test but it works.
ABB is recceiving in operation GOOSE messages from external equipments, that they order some setting group changing (don't know the details, I just read it somewhere). Probably other manufacturers do that as well. It is not so complicated to get receive a GOOSE message.

My opinion about standardisation:
1. IEC61850 is good idea. End of end we (customer) can use standard convertors, switchs and SW for IED connection from several companies. Classic example Modbus RTU.

I agree, Once again: IEC61850 standard is aimed to INTEROPERABILITY, so I don't think that manufacturers should consider themselves "competitors" on this issue. It would go against the main task of the standard (my interpretation, maybe naive)


2. GOOSE messages between several types of IED is also very
important ( but I think it's avil in next type of relay).

This is already done and is not a big issue.

But NOT standards for protective relay functionality and settings. 521AB is right, we kill devolpment.

I agree with you, of course.

 

[521AB]

Hi.
If we discuss about GOOSE messages, I would like ask your opinion about:
Interlocks between bays by GOOSE only or by HW also.

A) By Software (i.e. GOOSE). Safety interlockings maybe we should do them by hardware as well.
Maybe it's not easy to be iteroperable here, some manufacturers base the SW interlocking on the "SPEED" of information (position etc), some others don't care about the speed..

Used GOOSE messages for BFP in MV swg.

A) The standard is forseen to send protection signals via GOOSE. I agree with you, unless you are 18 years old, used to "GOOSE" with the Playstation from the real beginning (I am not ), I also would start on MV stations. Just a feeling, not a mistrust on the standard. Anything new, should be "digested". If I we have some years of good experience on the MV side, we have the necessary experience to "promote" it on the HV level.

Automatic transfer switch ( between two infeeds and couplers for example) by GOOSE messages only.

A) I see no problem on that.


What do you think about used IEC61850 ( in future) for meas data, for example send voltage from BB VT to bay's via 61850 network

A) This is already available in the so called IEC61850/9/2 (I think) standard, where the analog quantities are send via ethernet. The protection relays will not need A/D concerter and not even transformer cards..... Test equipment will be as big as a credit card...