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 TugboatEng on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
IEC61850 3rd part engineering tool 1
- Thread starter 521AB
- Start date
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
- 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
-
1
- Thread starter
- #4
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.
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.
- Thread starter
- #5
" ,,,,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..
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..
- Thread starter
- #6
- Thread starter
- #8
I have found at least one third part engineering tool, and I post the link here in hope that it might help some others..
Omicron electronics 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.
- Thread starter
- #11
Following link gives you access to the Kema analyzing tool
regards,
Danny
regards,
Danny
- Thread starter
- #14
Don't rely much on me, I am new in this field 
Up to now I work mostly with relay protections.
Up to now I work mostly with relay protections.
- Thread starter
- #16
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
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
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.
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.
- Thread starter
- #19
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).
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).
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
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
- Status
Similar threads
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question