Increased and Sustainable Interoperability of intelligent devices in the power delivery domain is one of the crucial objectives of IEC 61850 and IEC 61400-25 (Wind Power). Interoperability is reached to a quite high degree – sure, there are a few examples where we see some challenges to improve one or the other technical problem!
My personal experience is that there is still some room for improvements – in the standard series IEC61850 and IEC 61400-25 and in the implementations and use of various vendors’ devices. One reason that causes headaches is linked to the many options in the standards. Vendors very often interpret the mandatory (m) and optional (o) designation as m=minimum, o=oops there is something we can ignore. Users often expect that they can decide to use mandatory and optional definitions – they expect that vendors have to implement almost all options.
There is – of course – a huge lack of understanding what and how to implement IEC 61850 and how to use standard compliant devices; and to figure out what goes wrong. Education of vendors and users is one of the most highly recommended actions to improve interoperability!
The other day I was called to help solving a six months’ discussion between two vendors of IEC 61850 compliant products, a third vendor using their devices, the project management and the user.
It took me (with a helmet and security jacket and security shoes) less than a day on the site (a medium voltage substation in a new coal fired 920 MW power plant) to figure out the reason of a non-interoperable behavior of the power plant control system (IEC 61850 client) that had a problem with one device type. The control system wants to set the TrgOps (trigger options) of the report control blocks in all devices. It sends a SetURCBValues service with the value [x111 11xx]. All but one devices accept this value (even they do not support one of the 5 bits that can be set to 1). One device supports only three out of the five [x100 11xx] – setting 3rd and 4th Bit true is not accepted and causes a negative SetURCBValues message (according to the definition in IEC 61850-7-2).
This minor issue causes a big trouble because the client (power plant control system) cannot set the General Interrogation to true – and cannot use it !!
I expect that this non-conformity will be fixed soon. It is not a big issue – but it caused six months trouble and created a lot of frustrations!
If the right expertise would get involved in such discussions at an early stage it is likely that many of the non-conformities would be solved very soon. Comprehensive education is required when it comes to IEC 61850 – the earlier the better. Be aware: IEC 61850 is not just another protocol.
Some complaints about the many options in the standard series are discussed in a paper published the other day.
“… the world needs — there is a user group already associated with IEC 61850 — is some type of organization that will work through 61850, come up with a subset that eliminates all the options and drive that down to the vendors and say, "here, do this." ”
This is a great approach. The main reason this has not yet been done is mainly the absence of users in the many discussions in the standardization working groups and the UCAIUG (UCA international users group), and in other discussions – and the lack in education of the users community.
Some pressure from the utilities on the vendors community to fix the relatively few known non-conformities in existing devices and tools would help to get rid of a lot of frustrations and to reach a higher level of interoperability. Many users are – not yet – in a position to figure out which device is conformant and which is not! A lot of these issues are independent of the question optional or mandatory and could easily be solved.
Recommendation #1:
People implementing and using the standard need (more) education.
Recommendation #2:
See recommendation #1.
Some discussion on Education.
Read statement of Vattenfall on Education for IEC 61850 [2007!!]
My personal experience is that there is still some room for improvements – in the standard series IEC61850 and IEC 61400-25 and in the implementations and use of various vendors’ devices. One reason that causes headaches is linked to the many options in the standards. Vendors very often interpret the mandatory (m) and optional (o) designation as m=minimum, o=oops there is something we can ignore. Users often expect that they can decide to use mandatory and optional definitions – they expect that vendors have to implement almost all options.
There is – of course – a huge lack of understanding what and how to implement IEC 61850 and how to use standard compliant devices; and to figure out what goes wrong. Education of vendors and users is one of the most highly recommended actions to improve interoperability!
The other day I was called to help solving a six months’ discussion between two vendors of IEC 61850 compliant products, a third vendor using their devices, the project management and the user.
It took me (with a helmet and security jacket and security shoes) less than a day on the site (a medium voltage substation in a new coal fired 920 MW power plant) to figure out the reason of a non-interoperable behavior of the power plant control system (IEC 61850 client) that had a problem with one device type. The control system wants to set the TrgOps (trigger options) of the report control blocks in all devices. It sends a SetURCBValues service with the value [x111 11xx]. All but one devices accept this value (even they do not support one of the 5 bits that can be set to 1). One device supports only three out of the five [x100 11xx] – setting 3rd and 4th Bit true is not accepted and causes a negative SetURCBValues message (according to the definition in IEC 61850-7-2).
This minor issue causes a big trouble because the client (power plant control system) cannot set the General Interrogation to true – and cannot use it !!
I expect that this non-conformity will be fixed soon. It is not a big issue – but it caused six months trouble and created a lot of frustrations!
If the right expertise would get involved in such discussions at an early stage it is likely that many of the non-conformities would be solved very soon. Comprehensive education is required when it comes to IEC 61850 – the earlier the better. Be aware: IEC 61850 is not just another protocol.
Some complaints about the many options in the standard series are discussed in a paper published the other day.
“… the world needs — there is a user group already associated with IEC 61850 — is some type of organization that will work through 61850, come up with a subset that eliminates all the options and drive that down to the vendors and say, "here, do this." ”
This is a great approach. The main reason this has not yet been done is mainly the absence of users in the many discussions in the standardization working groups and the UCAIUG (UCA international users group), and in other discussions – and the lack in education of the users community.
Some pressure from the utilities on the vendors community to fix the relatively few known non-conformities in existing devices and tools would help to get rid of a lot of frustrations and to reach a higher level of interoperability. Many users are – not yet – in a position to figure out which device is conformant and which is not! A lot of these issues are independent of the question optional or mandatory and could easily be solved.
Recommendation #1:
People implementing and using the standard need (more) education.
Recommendation #2:
See recommendation #1.
Some discussion on Education.
Read statement of Vattenfall on Education for IEC 61850 [2007!!]
Posts
7 comments:
An interesting question is then:
If one or the other IEDs are "non-conformant" as you seemed to infer, does it have a valid Conformance Certificate?
An interesting question arises:
If the IED has a non-conformance, does it have a valid Conformance Certificate?
If not, then we shouldn't be all that surprised that there could be problems - not that not no Certificate means there will be problems but it certainly doesn't rule out general problems.
If yes, did the person evaluating the tender response technical schedules know what the answers meant in general and for the specific requirements of the intended usage?
If yes, is this a failing of the test process and certification process?
There are several questions that arise ... one crucial lession everybody should learn here is: Before you install a huge system, run interoperability tests in a lab between all types of IEDs that have to communicate together one way or the other.
These tests should be conducted (witnessed) by a well experienced expert (like myself) ... this will definitely save time and money in the end ... and it will prevent frustrations!!
Is education really the only answer? It is a common quite possible, given the 'flexibility' of IEC 61850 to have situations like this were two different devices are conformant but due to interpretation of the standard are not interoperable.
In such a situation, neither vendor is particularly motivated to fix the problem (after all they are technically not doing anything wrong), and the utility/integrator is left alone to fix the problem. Should the handling of Tissues within UCA be extended so that these types of occurrences can be raised by end users - somebody needs to act as a mediator and specify/enforce required changes.
Dylan, You are right! I am hired by a big utility to help them as a mediator ... Utilities are the crucial people in the "Team" IEC 61850 - they have the "power" to specify and enforce needed changes in products, in standards and test specifications. They (or we as customers of the utilities) have to pay for it anyway - know or later.
There is also an issue of "competition" within one group of companies or between companies. Guess that technical people would implement changes to make the devices more interoperable in some cases -- BUT what should the utilities do if the Management of a vendor does NOT allow the technical people to implement a change?!
I am convinced, that, when it comes to money, then they may be more open for implementing (usually small) changes.
ENTSO-E is likely the "power" to put some pressure on some vendors to ...
@ Dylan: The TISSUE process is open to anyone, yes - anyone, to raise a TISSUE - they just have to create their own account (so they can be identified and be contacted for follow up if necessary) - it is free and can be done in a few clicks directly online from the TISSUES web site!! So nothing needs to change there – just more people using it if there are problems. As KHS says, if it is a problem of the Standard, getting a problem resolved does not mean any or all vendors will implement the solution ….
More generally though, we must always remember it is a SYSTEM. The Standard has never guaranteed or purported “blind interoperability” (arguably what ENSTO-E have suggested is the failing of the Standard).
The Standard gives the definition of items so that APPROPRIATE SELECTION, starting with SPECIFICATION, of the right combinations of items and requirements will result in the devices behaving interoperably in the particular application.
My favourite clause of IEC 61850 is Part 1, Ch4:
“ but the purpose of the Standard is neither to standardise (nor limit in any way) the functions involved in the operation of the substation nor their allocation within the SAS”
Blind interoperability with anything whatsoever is therefore not part of the objective otherwise it would have standardised AND limited the function AS WELL AS having prescribed where the function is allocated in particular devices of the SAS – that means one SAS would have to fit all substations – all substations are the same aren’t they – just like all houses are the same ….
Education is clearly at least several key parts of the answer but I agree maybe not all parts.
If people expect, as a result of not knowing any better, that the Standard is a miracle solution to “world peace and hunger” or at least anything happily connects to anything without any engineering – well they will at some point be sadly mistaken and disappointed - but that is not the fault of the Standard or necessarily the vendor’s interpretation and selection of implementation.
As one example, we see utilities writing useless specs such as "all IEDs shall be compliant to IEC 61850" (that is a ‘copy and paste’ by the way …). These engineers need education to know they need to specify to which parts, to which Edition of the Parts, with which TISSUES, to which mandatory, to which optionals, for which LN/DO/DA, to what performance .... they actually need – if they don’t specify it they should not be surprised if they don’t get it.
On the other side we see vendors forcing mappings of GGIO for GOOSE and not supporting SSD and SCD files created independent of their tools. These engineers need education on what GGIO is for and that the tools have to comply with the exchange of files between tools (interoperable) depending on the role of the tool in the engineering process – but remember you should never use a wrench as a hammer, or vice versa.
Yet how much education of the Standard is really going on – in the utilities, in the consultants, in the R&D teams of the vendors … - attending a 1 or 2 day “introduction” or “essentials” seminar is a good start but not sufficient – there is a journey to be had – just like learning to drive https://ideology.atlassian.net/wiki/x/tAFv
I as a SAS system engineer have commissioned two S/S of 132/33/13.8 KV. I have noticed that the S/S are IEC 61850 base but for name sake. Here we are using IEC 61850 for only relay communication by Report Control blocks. When we try to explain client for using GOOSE for interlocking and inter tripping they bluntly refuse to do so. As they are not confident enough to use it, as many vendor companies have papers (I will not take their names)had prove that the GOOSE communication is not efficient enough (which i completely don't understand). As I personally checked during my master thesis the the GOOSE messaging tripping and interlocking is achieved with average 2MS accuracy. The main latency comes into existence when vendor or utility do not select proper network configuration for GOOSE e.d VLAN ID, GOOSE APP ID etc etc..I have personally noticed that the S/S commissioned in my region of work by XYZ reputed company (Again will declare the name)has used only one GOOSE APP ID in whole S/S.
So my point is even if we test the inter operatibilty during pre-commissioning stages showing some basic communication does that implies that we are going to use atleast 80% of actual IEC 61850 configuration in S/S (I mean are we sure that actual fruits of IEC 61850 will be ripped). The idea here is not only the pre commissioning testing, it should also include the process and design during pre-commissioning testing for checking GOOSE parameters and how they will be manged in network to get least LATENCY. There are many problems which comes up in actual application which is quite obvious but then one should make a note that this things are taken care in design and specification, but I rarely seen a good specification or design which complies with actual implementation of IEC 61850 (As rightly mentioned by ROD in this discussion).
I hope I would be able to commission a actual 61850 station using all its capabilities some day.
Regards,
Nikunj Patel
Post a Comment