×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

IEC61850 3rd part engineering tool

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

RE: IEC61850 3rd part engineering tool

How do you define the "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

Sorry I forgot to mention, KEMA has got some nice tools (also for diagnostics) for IEC61850 Ethernet networks. I believe they even have a freeware limited version available.

regards,
Danny

RE: IEC61850 3rd part engineering tool

(OP)
The IEC61850 engineering tool has in my opinion nothing to do with the "low level action" of instructing the device on what it has to do.
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

(OP)
"  ,,,,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)...."

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

(OP)
Danny,
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

There is a relay test set that can test 61850.  I agree that the OEM should supply the application SW for entering settings into the relay.  SEL has released a version recently.

RE: IEC61850 3rd part engineering tool

Omicron electronics www.omicronusa.com, makes a tool called the IED Scout.  It allows you to interrogate any 61850 device and read the scl files, etc.  SEL also has a tool for SEL based relays.

RE: IEC61850 3rd part engineering tool

521AB, have you used this software from ASE? I see for the first time third party tool for such purpose. But reading the manual I think it doesn't include run-time module, which to be used as operator's interface?

RE: IEC61850 3rd part engineering tool

(OP)
Unfortunately not.
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

521AB, I just downloaded it. Now will be in a hurry to evaluate it in 15 days!

RE: IEC61850 3rd part engineering tool

(OP)
I will also evaluate it, but only after your feedback, so I have 15 days more.
I hope you are going to implement GOOSE..

RE: IEC61850 3rd part engineering tool

Don't rely much on me, I am new in this field :(
Up to now I work mostly with relay protections.

www.triel.dir.bg

RE: IEC61850 3rd part engineering tool

(OP)
Too bad, I tried to install it on my PC (WIN XP) but the installer crashes...

RE: IEC61850 3rd part engineering tool

I was under the impression, from my contacts at multilin, that 61850 was intended to standardize the relay protective settings as well as the GOOSE messaging functions of the relay.

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

JBinCA,

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

(OP)
I would like to add that the standard gives the possibility to standardize the settings, but it is not mandatory.
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

Dede61,

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

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).

RE: IEC61850 3rd part engineering tool

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

RE: IEC61850 3rd part engineering tool

(OP)
Guys,
I think you are not fair on that.
I want to comment this, even if not completely pertinent with my original message (sad  
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 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.

RE: IEC61850 3rd part engineering tool

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

RE: IEC61850 3rd part engineering tool

(OP)
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..

RE: IEC61850 3rd part engineering tool

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.

RE: IEC61850 3rd part engineering tool

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

RE: IEC61850 3rd part engineering tool

(OP)
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.

RE: IEC61850 3rd part engineering tool

(OP)
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 smile  ), 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...

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources