ENTSO-E representing 41 TSOs from 34 European countries has published earlier in 2012 a statement on IEC 61850 for the application in European Transmission Systems. The statement criticizes that the level of interoperability expected by the utilities has not yet been implemented by the vendors.
This is also my personal experience speaking to hundreds of utility experts all over. What happened? How can it be overcome?
The main reason for some challenges in getting a higher degree of interoperability is that the same utilities (from the 41 in ENTSO-E) that are now complaining DID NOT get enough involved in the standardization process AND NOT in the process of implementation and first pilot tests. The feedback (needed in such comprehensive standards) was very weak.
I was personally seriously impacted by the changes in the utility industry some 10 years ago: The industry has funded my (and other peoples) involvement in the standardization work until 2002 – to help to make sure that the utilities’ requirements got implemented in the standards!! For the next 10 (crucial!) years after 2002 almost NO UTILITY expert showed up or was seriously involved. The vendors were finishing the standards without the “control” of the utility industry. AND: The first implementations and projects were not really watched and commented by the utility experts. The vendors still are preferably implementing turn-key substations often WITHOUT utility experts involved! Utility people usually have very little understanding what IEC 61850 means.
On one side it is unfair to not really showing up and not getting sufficiently involved in the process for the last 10 years and then – when some minor issues are still not solved – complain that the TSO’s requirements have not been fully met! Several experts have tried some 10 years ago to convince several CEOs of big utilities to continue funding the standardization work! We did not have any chance!
By the way – the good sign is now that the ENTSO-E TSOs WOKE UP! Hope that they will get back to become again a serious partner in the international standardization and in the implementation and application of the standards.
Download the ENTSO-E statement on IEC 61850
In the meantime many other domain have decided to use IEC 61850 – in most cases the interoperability at a very high degree is reached in these applications.
All market stake-holders are invited to get involved – some may first need to get some education to understand that IEC 61850 is more than just another protocol.
The statement refers to EPRI’s UCA development that has cost some 50.000.000 USD !! Where are the European utilities that are willing to spend a reasonable amount of Euros to get the remaining requirements of the TSO implemented in the years to come?!
I look forward to receiving many enquiries for training courses from European TSOs in the years to come ;-)
I have trained many utilities all over to help them to understand the standards, products, tools, and the vendors … often utility experts have NO clue what this is all about!
Posts
10 comments:
The ENTSO-E document contains the following boldfaced sentence: “A clear move by the market to a top-down [engineering] approach using standardized third-party tools is needed.” This sentence says a lot, but at the same time lacks conclusiveness.
On the one hand, there seems to be a confusion between the mere possibility of having fully-functional third-party tools and the standardization of these tools. In the current state of things we don’t even have the former, because proprietary, vendor-specific tools are usually required for the engineering tasks. That’s the issue we must address. Standardization of tools is not one of the objectives of IEC 61850, although it certainly lays the foundations for its accomplishment. It would perhaps be nice to have standardized tools, but that will be another standard’s matter. Let us proceed stepwise, please.
So let’s now talk about fully-functional, comprehensive third-party tools. What kind of ‘clear move’ are we talking about? How come we still don’t know, after ten years of having IEC 61850 around?
It’s about time we stopped beating about the bush. We users are the market, too. We must not accept any IED that requires, either for operation or for configuration purposes, communication methods and protocols other than those specified by the IEC 61850 standard. As simple as that. This implies, of course, that all configuration parameters shall be IEC-61850-modelled, settable and modifiable by ACSI services and SCL code. Vendor-specific proprietary tools shall perhaps be accepted as added value, but they will never be required, at any stage of the whole life cycle of the installation. Thus it will be up to the user to use them or not.
Julio Dominguez
(from the E3 Group on IEC 61850 http://sites.google.com/site/e3groupiec61850)
It would be highly appreciated to get more input from the market! The issue is really to reach a balance between benefits for vendors and users!!
I hope that the users will not accept deviations from the standard - and will continue to contribute to the standard, the implementation of the standard (by watching the process of implementation), and the use of the products (IEDs and tools).
Compared to other industries we are doing quite well! Sure, there is still (and always) something to do! There is no free lunch!
A few words in the above commentaries have prompted this epistle/rant... sorry for that.
Certainly it would be useful to get some [public] feedback from each of the vendors on how they are responding to the ENSTO-E ‘call to arms’ but I’m not sure how that can be achieved.
ENSTO-E, WG10 and CIGRE are trying to put in place mechanisms that will help work on the issues raised but even that has its own difficulties as a process.
Perhaps an open forum of Users is needed – all in one place and able to speak their mind – vendors not being allowed to have the microphone! :)
However to clarify, IEC 61850 Part 6 specifically identifies 3 different roles for tools
• System Specification
• System Configuration
• IED Configurator
The last is clearly what we also generally call the vendor-proprietary/vendor-specific tool used to configure the boxes.
We should not be surprised or annoyed that vendor-proprietary tools exist – they are a specific part of the Standard. We should take care though that the mere use of an IED Configurator is but one of three roles – just because we have an IED configured and operating according to IEC 61850 does not mean the project itself and all its engineering is in fact IEC 61850 compliant. This, I suspect, is the issue outlined by ENSTO-E – I would suspect that the projects which can’t be extended don’t have an SCD developed from an SSD simply because the proper tools for those didn’t exist at the time. And no, taking an ICD and making several copies as CID1, CID2, CID3 then taking those and doing CID1 + CID2 + CID3 is not equal to an SCD developed from an SSD with ICD instantiation so don’t expect easy “bay-based” copy & paste extensions. But if done right whole new bays can be engineered and commissioned in an hour.
The vendor-specific tools have to deal with
• LEDs on the front plate,
• Buttons on the front plate,
• Menu configuration
• Physical I/O
• as well as the internal logic
Whilst I agree these all have certain “settings” or “configurations” of the IED, they were and remain outside the technical scope of the Standard. Part 6 Introduction 2nd para says the main purpose is “to allow the interoperable exchange of communication system configuration data between an IED configuration tool and a system configuration tool from different manufacturers” – i.e. it is about how to generate configurations and apply them to two devices to talk to each other. These items are all physical items of the IED itself, except for the last, with specific configurations and nothing to do with ‘communication system configuration’ between two devices.
Frustration always sets in if you try to use a hammer as a screwdriver, or a screw driver as a hammer. Tools have certain roles and they should be used as such for the benefits they provide. If you choose not to use a particular tool, or use a tool the wrong way, don’t blame the definition of the tool you are using or the tool manufacturer.
ENSTO-E are right though that the ‘higher level’ SS and SC tools are limited in availability. But we also have to ask ourselves what is the value/size of that tool market? Can that revenue sustain development of a vendor-independent tool – I think the answer is self-evident that there are effectively only 3 or 4 tools claiming to be in that Space with huge differential between them – it is not an attractive market for bulk investment. On the other hand the industry spends (wastes) billions of dollars every year on repetitive wire-based engineering drawing the same signal between different terminals of different devices every time we do a different project with different vendors’ IEDs – even though we are trying to connect the same equivalent of a PTOC.Op to the equivalent of an XCBR over and over again – and when we replace the relays in 15 years or add a new bay in 3 years we’ll do that all over again, but tell our bosses we can’t afford the investment in learning other technologies that would avoid that waste.
Part 2
So what is causing us so much difficulty with vendor-independent tools at the SS and SC role level? Quite simply the several thousands of installations using IEC 61850 in some degree (some by lip service perhaps) could not have been built without the pre-requisite of the IED Configurator. Could the early projects have been built using a vendor-independent tool? – at the time no, they didn’t exist. Why? Simply because as yet no-one knew what IED implementations looked like with what nuances in the IED or the tools. Also since the vendors have spent 10-15 years working on the Standard, they needed a bit of revenue back and the easiest way to do that is to sell THEIR boxes which means a tool to configure THEIR boxes – they didn’t care about other boxes so the proliferation of single vendor projects.
But this vendor-independent tool has a huge ask. There may only be 20 or so protection suppliers, perhaps 50 SCADA suppliers, but there are hundreds - thousands of Condition Monitoring suppliers, Elec vehicles, wind farm developers, solar PV, distribution automation ….. Just recently I have been involved in projects where one vendor’s tool identifies two different ICD for the same hardware platform for two different applications (say incomer and feeder) by the “desc” field, where as the SC tool assumed that it would be identified by the “type” field. Then if the “type” field was changed in the instances, the vendor tool would not accept the SCD and would revert the instances back to the original ICD values. Which field does exactly what is not prescribed in the Standard (at this stage). However we do know the Standard forbids an IED Configurator ‘undoing’ any configuration so arguably this vendor’s tool does not comply with the Standard but the SC tool is being modified to cater for this so it can cater for a raft of other vendors with different nuances – gives us a better tool thanks to having to cater for arguably non-compliant other tools. Or the asset owner has a (logical) preference for harmonising naming conventions between the fixed naming of one vendor and the configurable naming of another – but what about the next project with different vendors and different limitations… - perhaps the next project has vendors with all fixed naming … This magic vendor-independent tool has to foresee all these problems based on individual vendor selections and project/utility preferences. If we don’t engineer the engineering process and associated tool use in consideration of the IEDs we will surely also be frustrated, delayed and annoyed.
However having said all that, as I said in another post in this blog, that doesn’t mean we can’t think of improving the existing Standard and expanding the scope of the Standard for where and how we apply IEC 61850 philosophies to solve an even bigger portion of our engineering than just how to configure two devices to talk to each other. Moves and proposals are afoot and TISSUES have been raised … - but users MUST speak up - We can’t let vendors dictate (they aren’t all nasty though) a Standard as the lowest common denominator where they don’t lose business if they don’t do the development to enhance/upgrade to users expectations spelt out in the Standard.
The utopia of all configurations of devices in an SCL process is something I fully support but there is a long way to get there. As often is said by users "never mind whether I want products complying to Ed2, it would be nice if all the vendors complied to Ed1 and in the same way ...."
Perhaps more users need to comment on their experiences along the lines of ENSTO-E.
Rodney, Karlheinz: your epistles are welcome.
We know that IEC 61850, right now, makes a distinction between the System Configurator and the IED Configurator. Yes, and that’s precisely what we regret!
You will surely agree with me that the standard provides (via ACSI services, SCL code and FC=CF/SP data attributes) all the resources needed to get rid of the IED configurator. Thus an engineering process in which a single system configurator tool generates a single SCD file, then extracts from it the different CID files to be directly loaded onto the IEDs, is absolutely compliant with the standard.
Rodney talks about the configuration bits that must ‘naturally’ be made by the IED configurator: LEDs and buttons on the front plate, local menu configuration, physical I/O, internal logic. I don’t see why there cannot be a logical node to model LEDs and buttons, as much as a GGIO can be used to model the physical I/O. Local HMI configuration and logics may be trickier, but they can be modeled, too. (A do-nothing, implicit approach is viable for the HMI: just let the IED read the section, pick up the relevant part of the single-line diagram and draw the HMI accordingly. Simple and elegant. As for logics, a simple modeling approach, based on IEC 61131, has been proposed by the E3 Group.)
Why get rid of the IED configuration tools? There are several reasons that summarize in one: the principle of economy. If the problem is that things have turned too complicated, the solution has to be a simple one or it won’t be a solution. Vendor-specific tools are essentially non-standard; even the simplest ones have a lot of built-in idiosyncrasy. For instance: equivalent concepts receive different names by different vendors, equivalent tasks are performed through different user-interface panels and navigation sequences. Engineering and maintenance personnel have to learn all the tricks and bits for every tool, attend specialized training that can only be given by the vendor. Don’t forget, either, that these tools are software: they must be configured, supervised, periodically updated, and so on; and since they can fail, they add failure modes to the whole system. All circumstances remaining equal, simplest means least failure-prone. Can I be even more honest? Proprietary tools give vendors the opportunity to control and patronize the client: introduce vendor-specific training programmes, consultancy, engineering methods and tools (for instance, a System Configurator that cooperates ‘naturally’ with the IED tools), and so on. Eventually the client may find him or helself in a position where going multivendor is clearly less efficient than buying all hardware, software and services from the same provider.
Precisely the position we wanted to eschew in the first place.
Kind regards,
Julio Dominguez
Dear Julio, dear Rod, This is a very valuable exchange of experiences, ideas, visions, wishes, ... unfortunately this did not happen some 5 ... 10 years ago. It is not too late to discuss the experience in a wider forum.
I have two suggestions: 1. To set-up an European IEC 61850 USERS Group - USERS !!!! 2. To discuss under such an umbrella the development of a set of reasonable basic tools that can be used by the member companies.
By the way, I am using IEDs for my training courses that are configured almost completely through a SCL file that is uploaded to the processor ... when restart, the Stack/API reads and interpretes the file and builds the model and binds te model to the application (very flexible approach).
Don't worry - keep going ... we get there. I have waited some 25 years to get to what we have right now: standard models, communication, configuration language ...
@Julio – sorry to be slow to reply.
RIGHT NOW, the IED vendors could use a GGIO to model the push buttons on the front plate of the IED which could also be done in perfect accordance to the existing Standard – Edition 1 or 2 Parts. If the vendor wanted to avoid being cruel to you from a semantics point of view, as discussed in TISSUE 900 under Part 7-4Ed2, it would be better to rename that GGIO under their or your own namespace as “KBUT” or some such.
This pushbutton LN needs to model the pressing of the Left/Right/Up/Down and Enter buttons. We can certainly do that with GGIO1.Ind1 – GGIO5.Ind1 or GGIO1.Ind1 – GGIO1.Ind5.
There might even be some LEDs that you want to turn on using GGIO or your own name space “KLED”.
All VERY easy. The Standard doesn’t prevent this at all and as you can see, in fact gives you the possibility to do it.
But what do these KBUTs do as they generally are linked to certain program implementations of the IED and their menu structure – i.e. they force different proprietary actions depending on where you are in the proprietary menu tree so you will need some further proprietary mechanism to define that.
However we can TOO easily assume that the Standard was written to solve “world peace and hunger”.
Part 1 of the Standard spells it out clearly. IEC 61850 was written to define the configuration of the communication necessary for two functions in two different IEDs to be able to interoperably communicate with each other.
In other words, if some piece of information could conceivably be needed to be sent over the Substation LAN to another function in another IED, then we needed
• an engineering process and file exchange formats that supports multiple engineers with individually multiple responsibilities in multiple stages of the process in multiple departments in multiple organisations in multiple locations using multiple tools of their multiple and independent choice,
• a data structure with semantics,
• a suite of client/server commands and reports and a special set of publisher/subscriber messages.
So from the perspective of the WG who had a very clear scope to do a very large job which itself took 12 years, whilst PTOC.Op is certainly something that may well be needed to be sent to another IED to inform of the status of the protection function, having that PTOC.Op in IED1 also turn on an LED on the front plate of the IED1 by any means was not in scope because the status of the button and the control of the LED is internal to the IED functionality and not communicated over the LAN.
A first response to that might be a scenario where say the autoreclose function is disabled by a command from somewhere else. This could be required to turn on an LED on the front plate indicating this has happened. However the command is not to “disable a/r and turn on the LED” – it is just “disable a/r” and it is the status of the a/r itself which may be communicated back out on the LAN as well as internally turning the light on – if that is what the IED vendor prescribes or the IED engineer configures the IED to do. The LED is a “local issue”.
No-one could say that the WG were inept or remiss at thinking about what constitutes configuring an IED. Configuration of internal functionality is just not in scope and so they have stuck to that as they should.
Perhaps not enough of us were involved in defining the scope at the outset, perhaps not enough of us sought out what was happening in the WG and try to influence any broadening of the scope.
However there is ample to scope to get involved and influence the Standard and/or other Standards to expand the relevancy and scope of IEC61850 principles throughout a broader consideration of the complete substation engineering process. TISSUE 927 under Part 6 Ed2 is an example of such engineering process expansion.
However back to the “one tool” scenario.
I don’t necessarily agree that “the Standard provides ALL the resources to get rid of the IED Configurator Tool”. The “one tool” is an interesting discussion and was the subject of CIGRE SCB5 in Lausanne in 2011.
I presented a contribution to CIGRE SCB5 in 2011 discussing the ‘benefit’ of the one tool philosophy.
I showed a slide with a famous Victorinox “Swiss Army Knife” – the normal one I would carry in my pocket with half a dozen blades. I know some people have ones with 8 or 10 blades but I have 6 I find generally usable.
I then showed a picture of another Victorinox Swiss Army Knife that had fifty – yes, 50 –blades which was about 30 cm wide. This one ‘super tool’ looks fantastic but certainly can’t be carried in your pocket or backpack (too heavy) and probably couldn’t really be used to undo a screw … and it didn’t have a hammer or shovel! :(
The objective of the Standard is to give us a suite of functionality - however they are grouped - for what tasks we need to do within our responsibilities. Certainly it defines certain roles for the engineering process tools:
the System Specification Tool,
the System Configuration Tool, and
the IED Configuration Tool.
How those are optimised in different tools, or a single tool, is not a requirement of the Standard but of the competitive, innovative, commercial market.
One tool that the specifier in the planning department, the integrator in the design office, IED configure on the factory floor, the tester during FAT/SAT, the commissioning engineer on site, the day-to-day operators and the maintenance technicians have to use - …. Well in such a multi-person, multi-department, multi organisation, multi-location engineering process, dealing with multiple IED types, I more than suspect it would be almost impossible to have one tool optimised for the individuals and IEDs involved at each stage – its menu and functionality would be huge and so overwhelming it would be as unusable as a 50-blade Swiss Army knife.
Imagine being confronted with dozens/hundreds of menu options that are irrelevant to what you normally do.
I think the Standard has it right. I don’t want one tool. But I do want each tool to work to produce and accept files interoperably. Yes, interoperability really starts with the tools exchanging SCL files. As I mentioned in my Part 2 above – sometimes even the ‘big vendors’ tools aren’t fully interoperable throughout the whole process in all cases.
Rodney:
What was the wheel invented for? Honestly, I don’t care. All I know is it would be foolish not to build cars, trains and trucks that roll on wheels. Similarly, the argument that “IEC 61850 should not be used as a means to achieve this or that because it was not envisaged with that purpose in the first place” sounds quite feeble. Perhaps the people who conceived IEC 61850-7 and IEC 61850-6 didn’t realize, in the beginning, that they were laying the foundations for standardized configuration. But they were! Usually good ideas are much more fertile than what their creators were aware of when they created them.
We must always take into account that another IED is not the only thing an IED interoperates with. It also does with the configuration agents, which are themselves electronic (digital) devices driven by people. Consequently, the concept of interoperability INCLUDES CONFIGURATION. Standardized configuration, i.e. the configuration of all IEDs by the same methods and data frames (thus possibly by the same tool) lies in the very concept of IEC 61850, from the moment when the standard contains methods for modification of an IED’s behavior either off-line (SCL language) or on-line (SetDataValues ACSI service, Control ACSI service). That is precisely the main strength of IEC 61850. No other industrial automation standard (AFAIK) contains such powerful resources.
The problem that you discuss as an example, on linking the LED activation with certain binary status signals known by the IED, can be solved easily with a “LEDGGIO1” containing “Ind1” and “InRef1” data objects, with “InRefX” pointing to the signal that causes activation of the Xth LED in the array, “IndX”. Admittedly, more complex logics are not definable within the standard in its present state. Therefore, the following paths (which are not mutually exclusive) must be followed:
1) Stick to IEDs for which all internal behavior can be customized by parameter setting. This is the case for most micro-RTUs and measurement/metering devices.
2) Choose IEDs whose internal logics, if needed, can be customized by means of standardized script (e.g. IEC 61131 Structured Text) that can be edited in any text editor, and may perhaps be appended to the CID.
3) Cooperate with user groups/IEC working groups in order to agree a standard method to be incorporated to SCL (like the one proposed by the E3 Group).
In any case, the spirit of progress should be “add to the standard whatever must be added so that fully standardized configuration is possible”, instead of “since the standard nowadays lacks this or that, standardized configuration is not a good idea”.
If we want to do things more efficiently, standardized operation is a must, and so is standardized configuration. Engineering tasks absorb a substantial amount of an utility’s budget and an efficient design of engineering methods is as important as the correct functional operation of the IEDs. Some manufacturers are not understanding this properly, and when you talk to them, they kind of tell you: “we have our plans and we have better plans than meeting our clients’ needs”.
Time will tell everyone if this is the right strategy.
Rodney:
Your “Swiss Army knife” example is indeed very appropriate: we are now bound to using a different blade for each different sausage. And the blade does not even depend on the sausage’s stuff and recipe (e.g. wiener, bratwurst, frankfurter, etc.). What then does it depend on? Er…, yeah, it depends on the manufacturer, and only on the manufacturer!
Can we not aspire to something better?
Post a Comment