First and MOST IMPORTANTLY, IEC 61850 does NOT provide Interchangeability !!!
Please refer Part 1, Ch4, 2nd para on page 9:
"Interchangeability is beyond this communication standard" We must be careful not to create unrealistic expectations of IEC 61850's solution to world peace and hunger! What IEC 61850 DOES provide is the engineering process and configuration requirements for two functions to communicate with each other INTEROPERABLY http://en.wikipedia.org/wiki/Interoperability :
"Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation." In other words, it provides the ability for REUSABLE ENGINEERING of how you can make configurations for two functions talk to each over an Ethernet communication infrastructure (cat5/6, fibre, WiFi, radio - perhaps not carrier pigeons !) regardless of whose IEDs are chosen to be involved. This does not mean "any IED can be directly replaced by any other IED" You can say that IEC 61850 is one of the first (new) CHECK POINTS for INTERCHANGEABILITY in that the replacement IED has to support the same data model and the same communications services as the previous IED (just check their ICD files). That being the case then the specific old IED's IEC 61850 IED configuration section contained in the SCD (repeat for emphasis "in the SCD" !!) can be used by the new IED's IED Configurator Tool to create the CID for loading into the new IED. This means the new IED's IED Configurator Tool MUST support importing an SCD - some don't! Moreover, this also means that the SCD file MUST EXIST from your previous engineering process! OBVIOUS, but I dare say probably not properly true for pretty much most of the projects done around the world to date. Note that if the original engineering process merely took an ICD and created multiple instances of that file (most likely incorrectly call CID since they probably have no Substation section binding and no communication section information of the other IEDs it is talking to) then you will NOT have the equivalent of an SCD. Taking several such CID and 'adding' them together does not necessarily, certainly not easily, create an SCD "CID"1 + "CID"2 + "CID"3 << SCD However CID1 as created by the IED Configurator Tool as subset of an imported SCD is the correct CID file. Hence properly created SCD IS the ONE SOURCE OF TRUTH. Further, such "CID" files not as subsets of SCD (noting they may not really be true CID) created by the old IED IED Configurator Tool may or may not be accepted as imports to the new IED Configurator Tool - eg the old IED's IED Configurator Tool may create the IED section to use the ".Type" field for one particular purpose (since that purpose is not prescribed within IEC 61850 except that it exists), whilst the new IED's tool may require that use to appear in ".desc" Hence we see the comments by ENSTOENTSO-E and VLGPO where previous IEC 61850 systems are not easily expandable as the users had hoped. If the IEC 61850 principles and processes weren't used at the outset, you can't really expect subsequent engineering processes (proper IEC 61850 or otherwise) could 'blindly' take up the original engineering and do some scheme modification, system augmentation or IED replacement. Now back to the second part of INTERCHANGEABILITY engineering (definitely not plug and play): Physical replacement of a box has many requirements beyond the configuration of the function that communicate with each other. These non-IEC 61850 requirements include: - Physical dimensions
- Wire I/O requirements
- Wire I/O terminal mappings to LNs
- # of LEDs and specific allocation (not part of IEC 61850 datamodel)
- # of push buttons and allocation
- Menu facilities and language
- proprietary scheme logic configuration and and associated tool configuration file import/export.
|