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]

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

 

[dede61]

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

 

[521AB]

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.

 

[521AB]

" ,,,,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..

 

[521AB]

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

 

[DTR2011]

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.

 

[521AB]

I have found at least one third part engineering tool, and I post the link here in hope that it might help some others..

http://www.ase-systems.com/iec-61850/visual-scl.asp

 

[DTR2011]

Omicron electronics

http://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.

 

[lz5pl]

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?

 

[521AB]

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

 

[dede61]

Following link gives you access to the Kema analyzing tool

http://www.kema.com/consulting_serv...sting/protocol_test_tools/analyzers/index.asp

regards,

Danny

 

[lz5pl]

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

 

[521AB]

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

 

[lz5pl]

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

http://www.triel.dir.bg

 

[521AB]

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

 

[JBinCA]

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

 

[dede61]

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.

 

[521AB]

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

 

[JBinCA]

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