A couple of application examples using IEC 61850 for substation protection and automation can be found in a 48 page brochure from Siemens (English and German).
The following topics are covered:
- Switchgear Interlocking with IEC 61850-GOOSE
- Reverse Interlocking Using the GOOSE of IEC 61850
- Beneficial Engineering of IEC 61850 Substation Automation Systems
- Innovative Solutions for Substation Control with IEC 61850
- Seamless Migration
- Ethernet Topologies with IEC 61850
- IEC Interoperability,Conformance and Engineering Experiences
- IEC Browser – A Powerful Test Tool for IEC 61850
The description is to a large extent vendor-neutral.
Click HERE for the English version [pdf, 1.4 MB]
Click HERE for the German version [pdf, 1.4 MB]
Posts
7 comments:
Page 15 reads (about IED parameterization): “naturally, device-specific tools are used for downloading the data to devices”. The question is: why naturally? Configuration parameters are part of the data model, and the CID file is specified by the standard. If a particular IED needs a parameter that has not been contemplated in the data model (IEC 61850-7-4), the standard allows the addition of extension data objects, which can be included in the CID as much as the standard ones. From a user point of view, the sentence should read: naturally, device-specific tools will no longer be needed and a multivendor substation shall be configured from a single engineering tool that directly generates the CIDs for all IEDs. That is real seamless, vendor-neutral, highly efficient engineering.
Julio Dominguez
(from the E3 Group)
http://sites.google.com/site/e3groupiec61850/
Julio, You are right!
The brochures are published by a vendor ... Hope the E3 Group and many other users could team-up with the vendors comunity in order to get the tools closer to the possibilities of the standard.
I have seen some progress over the recent years ... with GGIO and more flexible naming. I will post more on this the next days.
Thank you, Karl Heinz.
My company (and others in the E3 Group) is working on pure IEC-61850 engineering processes/tools for multi-vendor SAS. Perhaps we will be able to report on the results of this effort in a few months' time.
Hello Gents,
I see where you are coming from fellas, however the "device" specific tool is referring to the IED configurator, rather the 61850 focused system configurator and system specification configurator. Unlike latter the two tools, the IED configurator is used moreso for configuring the internal parameters (ie. word bits and other protection related parameters). Let's not forget 61850 is for external comms. Yes, in some cases the IED configurator can also perform the system configuator and system spec. configurator functions - such as DIGSI5) - but I reckon we'll still need unique IED configurator tools for each vendor...at least for the long term. For other vendors to become proficient with our the semantics of Siemens.dex files, etc (not ICD/CID), is highly unlikely.
Dustin:
“Let's not forget 61850 is for external comms.” Granted. But then other IEDs are not the only external thing an IED communicates with. It also communicates with the configuration agents. Interoperability between IEDs is desirable; interoperability between IEDs and configuration tools is not less desirable. This might be not very important for a vendor, but it is indeed very important for a user, since users (utilities) normally want to work multi-vendor. IEC 61850 provides the resources for standardized configuration, namely FC=SP and CF data attributes and SCL-coded configuration files. No need to invent anything! It’s all there in the standard. All you must do is make it MANDATORY.
It’s true that specific vendor tools sometimes seem sacrosanct, but they are not. If you look at it without prejudice, it’s all about a mentality change, rather than a technical change.
Regards,
Julio Dominguez
(from the E3 Group on IEC 61850)
Hello Julio,
You've made some great observations. I whole heartily agree that a universal software suite that handles ALL configurations is the ideal solution; but the question is it a realistic one?
If you take that same "silver bullet" approach with the hardware; for example a single piece of hardware (ie. mainframe) existed that integrated all the P,C&A functions into single super computer (or a set of computers, if redundancy is req'd) is obviously the ideal solution, but would the likes of the big five ever allow that?
The first step towards getting there will be a universal config software as you had mentioned, but what is preventing this from happening? First off, the vendors will have to "open" their source code, which in some cases they're already using open source OS, etc. This sort of IP is very valuable and is heavily protected - for good reason.
I respect the fact that we need a change in mindset within our industry, but one must not forget the business implications of these decisions. The IED configuration tool is not a revenue generator, like the IEDs are, but one may be an enabler to another? Just a speculation. Nonetheless, a good discussion. I would be keen to hear your observations from the work that you're doing in E3. Good on ya! Cheers...
Dustin:
There is no need for the vendors to open their code, unless the user wants to change the way the IED does things by firmware. I was not meaning that, and IEC 61850 is definitely not about that. It is only the INTERFACE between the IED and the outer world that we want to be standardized. A few items of data must be identified and named; if they have not been defined in IEC 61850-7-4, they can be defined by the IED’s designer by means of the extension rules and namespaces. Surely the firmware will handle lots of internal variables, but they are an internal issue!
Regards,
Julio Dominguez
Post a Comment