IEC 61850 - Expanding Horizons
I do agree with the point that IEC61850 is and will be expanding its horizons especially after redefining its scope from Substations to complete power utility. With object models of Wind and Hydro already available & models of DER, standards of substation - substation and substation - control centre communication & mapping to web services are already underway, it will find a completely different focus. We can even expect revolutionary changes after the possibility of SCL to migrate to CIM to provide complete models needed for an EMS/ DMS systems.
But looking back, can we say that objectives of IEC61850 are completely achieved? Can we say the IEC61850 devices are completely interoperable? I feel that many vendor implementations had made this standard to deviate from its objectives. IEC61850 had provided options for private LNs, data & GGIOs for handling the situations which cannot be handled by the standard models. But now the scenario had reached in such a level that all the vendors are finding it much easy to have private models rather than going for the standard LNs, data or formats which will not help in achieving goals of a global standard. What is the purpose of the total interoperability, if a vendor IED cannot accept a GOOSE because there is a time stamp element? Are the test certificates and interoperability events helping any bit in providing true inter-operability? I feel interoperability still remains a key issue in migrating to IEC61850.
Another area I want to point out is the engineering efforts for IEC61850 which was hyped to be much less comparing with the native mechanisms. But if we notice the tools and systems available for engineering IEC61850 today, it is much oriented on the standards rather than looking from the users’ angle for the configuration. The user has to follow complete & elaborate 61850 standards to achieve the complete configuration. The second is the dependability of vendor tools for configuration is too high that each user needs to know all the vendor tools to achieve even simple configurations like GOOSE mapping. So the current scenario is such that IEC61850 has increased the engineering efforts rather than reducing the same, if one were to do an independent engineering based on the standard.
I personally feel TC57 WG10 had never foreseen such a huge welcome for IEC61850 which made the standard to have some limitation. The standard could have been made with Substation configuration language (SCL) completely compatible with the UML based CIM models. Today, with all implementations working well with the SCL & problems in migrating to CIM, it will require a long way for sending the model information to EMS/DMS systems.
In spite of all these problems, the high benefits in using the standard in comparison with native protocols, is driving the same a long way through. Tissues (technical issues) forum for IEC61850 had come good for the standard which takes users opinion and problems to address the same in revisions. Let’s hope new revisions can throw some light to these problems & come up with effective ways to ensure the interoperability.
12 comments:
Is there a sense that IEC 61850 is built and promoted by the major players as a competition to SEL's Mirrored Bit technology?. SEL support IEC 61850, but still prefers to use its Mirrored Bit technology, which gives it a competitive edge?.
If it is introduced just as a competition to mirrored bit, IEC61850 should only have GOOSE. Also SEL should not have made their IEDs compatible with IEC61850. The comparison can be made between Mirrored bit and GOOSE of IE61850 only. But the total IEC 61850 standard is much beyond a simple mirrored bit technology.
Now which is better - GOOSE or mirrored bit? I do agree with the fact that GOOSE is having an overhead of processing the structured data and I cannot comment on mirrored bit due to lack of experience on MirrB or SEL IEDs. But some of the vendors like GE have succesffuly used a schenario of passing GSSE data (just 32/64 bit lists) over a normal GOOSE communication layers as 'Fixed GOOSE'. There are much discussions going on to make this as a part of standard as it does not have any overhead of the structured GOOSE [Courtesy to Mark Adamiak of GE]. I believe this will be best way to optimize the data processing for events in GOOSE.
What is the depth of penetration of IEC 61850 based Substation Automation systems in the World? Is there a statistic available?
Dear Prashant
It is observed that UCA user group link on this website is routing to some other link. I suppose it should be routed to www.ucaiug.org.
Thanks Hari Prasad
Only from GOOSE testing can we able to conclude that the device had performed interoperability testing?
GOOSE testing only confirm's that the device can inter-operate with other device for GOOSE Messages of IEC 61850. It does not imply that the device is fully inter-operable on other aspect's of IEC 61850.
Thanks Prashant.
Is there any test tool to conduct interoperability testing?.
There are no tools to test inter-operability. However, UCA used to conduct tests or demonstrations for Inter-operability at CIGRE. Also it is expected that a conformance tested product will inter-operate with another product which has been conformance tested for the same functions. Eg: GOOSE. KEMA and CPRI in India provide conformance testing
Can conformance testing be done for Client devices also?
Yes. KEMA does certification for IEC 61850 Client too.
Post a Comment