Interoperability - not Interchangeability

© Copyright Rod Hughes Consulting Pty Ltd
Rod Hughes Consulting
General Web Site
 
Applications
Home
Innovations and
Solutions Home

A bit about
Rod Hughes
 Link to this page...

The URL in the browser address bar is volatile and may be broken at any time.

To obtain a link to this page, click the <<Share>> button top-right of the screen.

  

Note - if the navigation pane on the left of this window is not visible, click the 2-pane icon on the top bar



First and MOST IMPORTANTLY, IEC 61850 does NOT provide Interchangeability !!!
Please refer Part 1, Ch4, 2nd para (both Ed 1 and Ed2):
"Interchangeability is beyond this communication standard"

We must be careful not to create unrealistic expectations of IEC 61850 as a 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 ENTSO-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.


Contact Me

Skype: (ping even if showing offline)
My status

Email Me

A phone call is nearly always welcome depending on the time of night wherever I am in the world.
Based in Adelaide UTC +9:30 hours e.g.

April-SeptemberNoon UK = 2030 Adelaide
October-March:Noon UK = 2230 Adelaide

  Office + 61 8 7127 6357
  Mobile + 61 419 845 253



Extra Notes:

Disclaimer
No Liability:
Rod Hughes Consulting Pty Ltd accepts no direct nor consequential liability in any manner whatsoever to any party whosoever who may rely on or reference the information contained in these pages.  Information contained in these pages is provided as general reference only without any specific relevance to any particular intended or actual reference to or use of this information. Any person or organisation making reference to or use of this information is at their sole responsibility under their own skill and judgement.

No Waiver, No Licence:
This page is protected by Copyright ©
Beyond referring to the web link of the material and w
hilst the information herein is accessible "via the web", Rod Hughes Consulting Pty Ltd grants no waiver of Copyright nor grants any licence to any extent  to any party in relation to this information for use, copy, storing or redistribution of this material in any form in whole or in part without written consent of Rod Hughes Consulting Pty Ltd.