IEC61850 3rd part engineering tool
IEC61850 3rd part engineering tool
(OP)
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
Are you aware about any third part IEC61850 engineering tool?
Thanks






RE: IEC61850 3rd part engineering tool
- Digsi only works for Siemens relays and bay units
- IET or CCT I'm not familiar with so I can't tell.
As far as have seen by now, you always need the typical brand software to load your relay parameters (also for the initial IP address you need to connect localy valid for Siprotec and others)
I feel that even if we have mananged to come to an open standard some Major Manufacturers try desperatly to close the door again by retracting the garantee on the systems if other manufacturers equipment are also used (even if they are IEC61850 certified).
regards
Danny
RE: IEC61850 3rd part engineering tool
regards,
Danny
RE: IEC61850 3rd part engineering tool
In the engineering tool you define the data sets you want to use and you define what to do with them (send them as Goose message or send them vertically to station HMI). You define also to which GOOSE messages your device will subscribe for.
It does not matter the brand of the device. The device is ond "SCL file" (icd?), which it is imported in the engineering tool. How this file is generated I do not care.
After having defined all these links, the eng. tool exports another SCL file (scd).
Engineering is done.
It's up to the vendors to import that file and instruct their devices to do what's written in the SCL file.
I am badly surprised on the guarantee issue. It sounds strange to me. Which type of guarantee? System functionality is a problem of the system integrator. Device functionality is a problem of the device supplier.
RE: IEC61850 3rd part engineering tool
This is part of the standard. Dialogue with the device (download/upload settings, parameters etc..) should be done by using the vendor's tool.
At least I remember I saw this in the spec. and do not find it strange. We are talking about interoperability and not interchangeability..
RE: IEC61850 3rd part engineering tool
any idea of what KEMA uses to analize the network?
Shouldn't be ebough Ethereal? (freeware and well working by the way). Do they maybe have a special "IEC61850 device interrogator"?
my regards
RE: IEC61850 3rd part engineering tool
RE: IEC61850 3rd part engineering tool
h
RE: IEC61850 3rd part engineering tool
RE: IEC61850 3rd part engineering tool
RE: IEC61850 3rd part engineering tool
The demo version couldn't be downloaded (server problems?).
I'll try soon, but I am more interested in GOOSE messaging (horizontal communication).
RE: IEC61850 3rd part engineering tool
http://ww
regards,
Danny
RE: IEC61850 3rd part engineering tool
RE: IEC61850 3rd part engineering tool
I hope you are going to implement GOOSE..
RE: IEC61850 3rd part engineering tool
Up to now I work mostly with relay protections.
www.triel.dir.bg
RE: IEC61850 3rd part engineering tool
RE: IEC61850 3rd part engineering tool
It sounds like this is dede61 had the same idea (although he is skeptical about it).
Isn't the intent to standardize so that a multilin created relay file could be loaded into a Schweitzer or basler relay and function correctly so long as all were 61850 compliant?
Thanks - JB
RE: IEC61850 3rd part engineering tool
No, you can't interchange parameters or setting files over IEC61850 between relays, every manufacturer has a specific firmware for his relays. IEC61850 is a communication protocol no more no less.
This does mean however that in your control system you should not make any addaptations if your inplementing a new relay, IEC61850 compatible, the data sent and received should contain the same information (form and content) for the relay and the system.
RE: IEC61850 3rd part engineering tool
The main idea of the standard is interoperability, which neans different devices from different vendors should be able to "talk" to each others (GOOSE messaging). And also should be able to send and receive parameters vertically (to a station HMI).
The standard also describes how the device should be mapped, which means described (names of functions, of signals etc). This "mapping" in practice is seen in the so called "SCL" files (SCD, ICD etc).
RE: IEC61850 3rd part engineering tool
It's true that each manufacturer has it's own firmware, but that doesn't pertain to the question at hand.
A standard could be developed for the organization and programming of the relay settings, and then manufacturers would have to make their firmware conform to that standard if the wanted to be compliant.
Thanks 521AB for setting me straight on this. The standard could have requiured settings to be standardized, but it did not.
Regards,
JB
RE: IEC61850 3rd part engineering tool
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).
RE: IEC61850 3rd part engineering tool
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
RE: IEC61850 3rd part engineering tool
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..
RE: IEC61850 3rd part engineering tool
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.
RE: IEC61850 3rd part engineering tool
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
RE: IEC61850 3rd part engineering tool
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..
RE: IEC61850 3rd part engineering tool
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.
RE: IEC61850 3rd part engineering tool
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
RE: IEC61850 3rd part engineering tool
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.
RE: IEC61850 3rd part engineering tool
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
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...