tag:blogger.com,1999:blog-4947745203111651722.post3732869008317832058..comments2024-03-05T00:27:49.553-08:00Comments on News on IEC 61850 and related Standards: IEC 61850 – Is Interoperability of Devices reached?Karlheinz Schwarzhttp://www.blogger.com/profile/14655052638097798754noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-4947745203111651722.post-6003584151134109652013-03-13T13:21:04.236-07:002013-03-13T13:21:04.236-07:00I as a SAS system engineer have commissioned two S...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.<br /><br />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).<br /><br />I hope I would be able to commission a actual 61850 station using all its capabilities some day.<br /><br />Regards,<br />Nikunj PatelAnonymoushttps://www.blogger.com/profile/13223661230779940948noreply@blogger.comtag:blogger.com,1999:blog-4947745203111651722.post-76567232805136201752013-01-20T21:27:27.333-08:002013-01-20T21:27:27.333-08:00@ Dylan: The TISSUE process is open to anyone, yes...@ 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 ….<br /><br />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).<br /><br />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.<br /><br />My favourite clause of IEC 61850 is Part 1, Ch4:<br />“ 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”<br /><br />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 ….<br /><br />Education is clearly at least several key parts of the answer but I agree maybe not all parts.<br />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.<br /><br />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.<br /><br />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.<br />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<br /><br /><br />Rod Hugheshttps://www.blogger.com/profile/14916869433788165969noreply@blogger.comtag:blogger.com,1999:blog-4947745203111651722.post-36268772711965612332013-01-17T09:06:58.675-08:002013-01-17T09:06:58.675-08:00Dylan, You are right! I am hired by a big utility ...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.<br />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?!<br />I am convinced, that, when it comes to money, then they may be more open for implementing (usually small) changes.<br />ENTSO-E is likely the "power" to put some pressure on some vendors to ...Karlheinz Schwarzhttps://www.blogger.com/profile/14655052638097798754noreply@blogger.comtag:blogger.com,1999:blog-4947745203111651722.post-14876747676284260552013-01-17T08:04:56.903-08:002013-01-17T08:04:56.903-08:00Is education really the only answer? It is a commo...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 <i>conformant</i> but due to interpretation of the standard are not <i>interoperable</i>.<br /><br />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 Jenkinshttps://www.blogger.com/profile/02087325791513092526noreply@blogger.comtag:blogger.com,1999:blog-4947745203111651722.post-73230258333159434252012-12-04T04:26:21.104-08:002012-12-04T04:26:21.104-08:00There are several questions that arise ... one cru...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.<br />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!!Karlheinz Schwarzhttps://www.blogger.com/profile/14655052638097798754noreply@blogger.comtag:blogger.com,1999:blog-4947745203111651722.post-391442873402969062012-12-04T03:32:52.940-08:002012-12-04T03:32:52.940-08:00An interesting question arises:
If the IED has a ...An interesting question arises:<br /><br />If the IED has a non-conformance, does it have a valid Conformance Certificate?<br /><br />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.<br /><br />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?<br /><br />If yes, is this a failing of the test process and certification process?Rod Hugheshttps://www.blogger.com/profile/14916869433788165969noreply@blogger.comtag:blogger.com,1999:blog-4947745203111651722.post-37822714716828209712012-12-04T03:26:46.464-08:002012-12-04T03:26:46.464-08:00An interesting question is then:
If one or the oth...An interesting question is then:<br />If one or the other IEDs are "non-conformant" as you seemed to infer, does it have a valid Conformance Certificate? Rod Hugheshttps://www.blogger.com/profile/14916869433788165969noreply@blogger.com