The title and scope of IEC 61850 was for many years very restricted:
2001 – 2009: Communication networks and systems in substations
2010 – … : Communication networks and systems for power utility automation
The new title and scope is still too restrictive! The working group wanted to change to “… for automation”. This was not accepted by the IEC Central Office. IEC deals with electro-technical matters. The term “automation” was understood as to broad.
From a content point of view IEC 61850 could be used all over where measurements and status information needs to be communicated – in any application domain. Even if you are just monitoring a process or system (no control need) you can use IEC 61850 models, messages and configuration tools.
The Model “STMP” (temperature supervision logical node) can be used wherever a temperature measurement is taken: Temperature of a transformer, of a room, ambient temperature or your body temperature. When the “STMP.Tmp.mag” value reached the configured limit (Alarm limit or Trip limit) an report or a GOOSE message may be issued.
By the way, IEC 61850 has rules how to define extended logical nodes and data objects. All values can be communicated the Ethernet and TCP/IP based information exchange methods.
Experts pointing to the scope “substations” are not up-to-date. Those arguing that IEC 61850 is for “power utility automation” only may not like to accept that IEC 61850 is very generic or common – applicable in a wide range of applications.
The title and scope are just “toner on paper”.
Posts
1 comment:
Dear Karlheinz:
In connection to the topic you are addressing here, i.e. potential of IEC 61850 to extent its scope, at the E3 Group we have asked ourselves whether the Ethernet switches should host an IEC 61850 data model and be able to behave like an IEC 61850 server. This may include several degrees of compliance:
1) A limited IEC 61850 data model, using a number of newly defined logical node classes and (possibly) CDCs. The purpose of this model would be to provide information of the Ethernet switch status (health, VLAN definition, congestion, etc.) by means of the Report Control Block model.
2) A more advanced IEC 61850 data model including also the configuration data, thus allowing online engineering tasks to be performed from an IEC 61850 client.
3) In addition to the above, the Ethernet switch would provide SCL support, so that the it could be declared in an SCD/CID file and completely configured by means of the SCL language. A substation configuration tool would configure the Ethernet switches as much as the other IEC 61850 IEDs, including the data traffic (at the application level) amongst them.
At the present moment, we believe that we would be more than happy with stage 1. It would allow the user to smartly integrate Ethernet monitoring in the telecontrol applications (in the same way as, for instance, the health of an RTU is nowadays known by these applications), creating an obvious synergy. A slightly downgraded, but still acceptable and cheaper-to-implement solution to achieve this stage would be the use of GOOSE messages instead of the Report Control Block model. (This would spare the manufacturers the inclusion of an MMS layer in the device’s firmware.)
If I know well, the initial purpose of IEC TC 57 WG 10 was to progress in this direction, for the results to be published in “IEC 61850-90-4 TR
Communication networks and systems for power utility automation – Part 90-4: Network engineering guidelines for substations”. This TR is due for publication by autumn this year.
However, I have also learned that the WG decided, at some moment, to abandon the specification of an IEC 61850 data model for the Ethernet switch, as (probably) too ambitious a goal. From my point of view, this would be a pity and would let users and manufacturers alone and disbanded in the design of methods for Ethernet monitoring integration.
Best regards,
Julio Dominguez
(from the E3 Group on IEC 61850)
Post a Comment