IEC has published the FDIS for ballot until 2012-11-30:
57/1286/FDIS
Part 5 Ed2: Communication requirements for functions and device models
Extensions in Edition 2 of part 5:
- requirements for communication between substation automation systems to utility automation systems;
- including the interfaces for communication between substations (interfaces 2 and 11);
- requirements from communication beyond the boundary of the substation
Note that part 5 does NOT DEFINE FUNCTIONS!! The scope states:
“The description of the functions is not used to standardize the functions, but to identify communication requirements between Intelligent Electronic Devices … Standardizing functions and their implementation is completely outside the scope of this standard.”
There are other parts of IEC 61850 that go beyond the issue of determining the communication requirements: e.g., part IEC 61850-90-7 defines behavior at the electrical coupling point of a PV inverter. Depending on the configuration (input) of the various settings of a specific model the electric output of the inverter has to follow the “FUNCTION” that is described in the Logical Node model!
Posts
6 comments:
So if the standardisation of functions is now clearly stated as out of scope for IEC61850 does this mean that we are not likely to see IEC61499/61850 harmonisation in future?
Dear Dylan, There are several issues with regard to "functions" and "function blocks". Each IED useful for an application needs to implement functions (e.g., interlocking). The function implemented will provide an interface to the communication by means of a Logical Node instance of LN class CILO. The interlocking FUNCTION may be programmed in C/C++, IEC 61131-3 - and may be exposed as a function block according to IEC 61499.
The interoperation of Logical Nodes with other Logical Nodes or the peripherie may be described/configured using IEC 61499. The role of IEC 61499 in conjunction with IEC 61850 is still under discussion. If a function is defined in the standard or not does not make a crucial difference for the application of IEC 61499.
Note also that the IEC 61850 parts (for applications in power plants and in DER) have already and will in future define "FUNCTIONS" like PID loop control - for which we have defined the information interface in Logical Node FPID.
Hope that helps.
Thanks Karlheinz, very helpful. The reason I ask is that I am seeing customers increasing ask for the ability to configure relays with a single .CID file with no provision for a separate private file for internal logic.
This to my mind would imply that all functions need to be modelled in the .CID itself, else there is a large block of the file reserved for "private data" - something I'm sure not sure is really in the spirit of the standard.
Hi Dylan, My vision is that there will be ONE (functional) Engineering tool sometime down the road, that has several export files: XML file for the IEC 61499 part, possibly one XML file for IEC 61131-3, and an SCL file for the "clue" software (communication). It is unlikely that everything will be stored in a very big file.
I would highly appreciate if your customers would get involved in the maintenance, extension, and harmonization/coordination of the standards and standardization working groups.
Groups tend to say: this or that is not invented here ... we don't need it or don't need to coordinate. Maybe you can modivate some domain experts.
The idea of a single file to download to the IED with all configuration for the IED was raised by the Spanish E3 document as a procurement specification a couple of years back.
So far I understand the vendors have been … slow … to respond to these user requirements and I believe other places like Mexico have attempted similar ideas with limited if any success.
If there was a single download file to the IED – lets call it a CID for the moment – it would need to deal with all the proprietary issues – number, purpose and configuration of:
• LEDs on the front plate,
• Buttons on the front plate,
• Menu configuration
• Physical I/O
• as well as the internal logic
Looking at Part 6 of the Standard, titled “Configuration description language for communication in electrical substations related to IEDs”, its Introduction 2nd para says the main purpose is “to allow the interoperable exchange of communication system configuration data between an IED configuration tool and a system configuration tool from different manufacturers.”
The purists and vendors would argue that the intent of the Standard is not to deal with the specifics of a particular IED in regards to the proprietary hardware issues mentioned above. Logic is one of those areas that is perhaps challenging some of that puritan thinking since it does come into play in some way for the signals between functions.
We also know that the purpose of the Standard is not specifically interchangeability (same hardware capabilities as mentioned above in all devices), but rather interoperability between devices of different vendors, is the issue of the number and allocation of an LED on one device of significance.
Moreover the 2nd para of Part 1 Ch4 says “Interchangeability is beyond this communication standard.”
However whilst these views have some substance, the genesis of the Standard was over 20 years ago amidst a group of a few engineers that eventually became WG10.
We now have some (hundreds of) thousands of engineers with over eight years real experience of the Standard.
Hence it is not surprising that E3 or even the ENSTO-E & VLPGO entities are calling for improvements to the Standard.
Indeed there is scope for improvement in the implementation by the vendors of the Standard:
• http://www.tissues.iec61850.com/tissue.mspx?issueid=864
• http://www.tissues.iec61850.com/tissue.mspx?issueid=880
• http://www.tissues.iec61850.com/tissue.mspx?issueid=900
and there is scope for enhancements of the Standard to consider more of the complete life cycle of engineering of the SAS from the initial system scoping and drawings:
• http://www.tissues.iec61850.com/tissue.mspx?issueid=927
through to the life-time management of settings with the LN, DO and Attrib semantics that should be adopted even in wire-based, non-communication based systems such that setting databases can integrate more seamlessly with the SCD and CID files.
So the Standard is not perfect. Some would say there is lack of maturity (not sure if that is of the Standard, the vendor implementations or the skill level of the engineers – or all of those). Certainly the Standard will continue to evolve so it is good that we don’t put blinkers on what we need on the basis that was not the original scope or the vendors might be put to harder work.
I agree with Rod ... and would like to add: it took 10 years from 1985 (MAP project) - 1995 (to start the work on IEC 61850); it took another 10 years (1995-2005) to get the first 16 parts of IEC 61850 published; it took just 5-7 years to learn that IEC 61850 is stable for many applications AND that is could be implemented AND used! Now we have 2012: let's work on some interesting extensions like configuration of IEDs, describing the FUNCTIONs with, e.g., IEC 61131-3 and IEC 61499, etc. etc.
We have a great base we can now use to build more possibilities on it!
It is not too late!! I recommend to extend the standard step-by-step. It's a Marathon - not a Sprint!
Post a Comment