IEC 61850 Is Very Crucial For Semantic Models And Interoperability

IEC 61850 provides a huge number of generic and specific semantic models ... Logical Nodes, Data Objects, Common Data Classes, Instance-Information, Topology Information, Information Exchange, Communication, Protocols, ...

Can you please show me an easy to understand example! Here you are!

The following figure shows how (meta) model information is added to a simple voltage measurement (right upper corner). The value is wrapped with a data object model comprising with many attributes like instCVal.mag.i or units ...
The logical device and and logical node instance information is added next. Finally the semantic of the information exchange (report model) is applied to the value - sure, there is a data set involved as well (not shown here).
All this information (general and specific (instance) semantic) could be described in an SCL document (using an XML based SCL schema). Note that some configuration information, e.g., engineering unit (kV), may be contained in the SCL document only. The device needs to process implicitly the voltage in kV. A device may allow to use the SCL document to configure the device to expose the voltage in V ... or mV ... A client (SCADA or ...) may read out the model at runtime (including the engineering unit, if that is implemented as a model attribute) or may just read locally the SCL document and get the engineering unit from the file. Note: the SCL document is the main document for the models and configuration ... keep it safe!! And check the online read model against the SCL file from time to time to compare the two in order to figure out any change!


Further in our example we have a simple bay topology with electrical equipment like generator, switch gears, voltage and current sensors. This topology could be engineered and documented with the SCL (System Configuration Language) - an XML schema for a whole system. The equipment is assigned to specific information models (MMXU.PhV.phsA. ...).
The system engineering could be managed, e.g., with the Helinks STS Tool. An easy to use tool.
The generic Information Model, e.g., MMXU (defined in IEC 61850-7-4) is concatenated with the application designation (MyGenSets/Gen11).


The various levels of semantics of the Message elements are:

1. Model Instance: Hierarchical Identification of the specific Model of Semantics (in SCL) 
2. Message Elements: Service Type, Identification, Value, Quality, and Timestamp (ACSI - Abstract Services)
3. Message Instance: Service Type, Instance of Identification, of Value, of Quality, and of Timestamp (Report)
4. Message semantic (ACSI mapped to MMS)

The modeling approach of IEC 61850 could be applied in most automation domains ... especially when electric power is applied.

Let me know please if there is a similar standard model defined for automation systems that may compete with IEC 61850 and IEC 61400-25. 

Why Wikipedia Misleads People Looking for Help regarding IEC 61850

How do people understand and learn what the standard series IEC 61850 really offers to the protection, automation and supervision of energy systems and what this all means for their application (as vendor, user, consultant, ...)? Some up-to-date discussion you can find on this blog, e.g., by this posting:

Who can tell you what IEC 61850 really is?

Some people (managers and ...) just go to Wikipedia and believe that they get a reasonable overview about IEC 61850. After reading the German and English version, they have learned: That IEC 61850 is mainly a PROTOCOL standard!

German Version tells in the very first sentence:

"Die Norm IEC 61850 der International Electrotechnical Commission (IEC) beschreibt ein allgemeines Übertragungsprotokoll für die Schutz- und Leittechnik in elektrischen Schaltanlagen der Mittel- und Hochspannungstechnik (Stationsautomatisierung)."

English Version talks a lot about PROTOCOLS:

"IEC 61850 is a standard for vendor-agnostic engineering of the configuration of Intelligent Electronic Devices for electrical substation automation systems to be able to communicate with each other. ... The abstract data models defined in IEC 61850 can be mapped to a number of protocols. Current mappings in the standard are to MMS (Manufacturing Message Specification), GOOSE (Generic Object Oriented Substation Event), SMV (Sampled Measured Values),[clarification needed] and soon to Web Services. These protocols can run over TCP/IP networks or substation LANs using high speed switched Ethernet to obtain the necessary response times below four milliseconds for protective relaying."

After reading these two pages ... some managers believe that IEC 61850 is mainly dealing with protocols. Protocols are required to exchange information between devices.
IEC 61850 deals mainly with the description of signal flows between any point of a (power or energy) system that generates information (status, measurements, alarms, settings, ...) and those points that need to receive or consume this information.(protection, automation, SADA, control center, ... asset management, ...).
The signal flow could be completely described (and documented) as an SCL file of tens of Mega Bytes ... such files have almost nothing to do with protocols - but the tools that design and engineer systems like substations are key to the future systems. SCL is defined in one document (IEC 61850-6). This document has the biggest impact on how we manage power systems in the future.
In my understanding SCL is likely 2/3 of the importance of IEC 61850. Then there are the many crucial models - and finally we have protocols. Protocols are crucial when it comes to devices that have to send and receive signals - no discussion.

Unfortunately the managers (and everybody) that uses Wikipedia for understanding the impact of IEC 61850 are completely mislead! And likely may not understand how IEC 61850 impacts the system design and engineering based on SCL - aspects that are today usually not linked to any protocol.

If the resources for a project to implementing and using IEC 61850 is determined by the assumption that IEC 61850 is another PROTOCOL - then it is likely that the project will fail to get what IEC 61850 could provide.

This post was triggered by a discussion during an IEC 61850 Seminar and hands-on training recently. It is really frustrating for engineers to discuss the needed resources with managers that believe IEC 61850 is mainly a PROTOCOL.

Who can tell you what IEC 61850 really is?

Seminar on Protection and Control in Stockholm (18-22 Sep / 10-13 Oct 2017)

FMTP, KTH, OPAL RT, and NettedAutomation offer a very comprehensive training courses on IEC 61850 and related standards

Stockholm-Arlanda (Airport)
18-22 September 2017
Click HERE for details
Karlsruhe (Germany)
10-13 October 2017
Click HERE for details

Machine-processable Format of IEC 61850-related Data Models

IEC TC 57 proposes a new work item (57/1768/NP) IEC 61850-7-7:

Communication networks and systems for power utility automation – Part 7-7: Basic communication structure – Machine-processable format of IEC 61850-related data models for tools (proposed 61850-7-7)

Closing date for voting: 2016-11-25

This technical specification will define an XML schema for describing the code components of the data model parts of IEC 61850, to be used as input for tools (typically engineering or specification tools).

In order to foster an active tool market with good quality, and at the end to improve IEC 61850 interoperability, the market needs a machine-processable file describing data model related parts of the standard as input.
This will avoid the need for any engineering tool related to the IEC 61850 datamodel to get the content of the standard manually entered, with the highest risk of mistakes.

The NP comes with a 150 page draft.

IEC 61850/IEC 61499 Based Engineering

You may remember the papers on the use of IEC 61850 in conjunction with IEC 61499 published a few years ago:

http://blog.iec61850.com/2012/09/ieee-award-for-paper-on-standards-based.html

Since then a couple of papers on the subject have been published. One of the latest has been published today:

G. Zhabelova, C.-W. Yang, V. Vyatkin , “SysGrid: IEC 61850 and IEC 61499 based engineering process for Smart Grid system design”, IEEE Conference on Industrial Informatics (INDIN’13), Bochum, July 29-31, 2013

Abstract — The paper proposes a novel computer-aided model-based system engineering process for Smart Gird applications. The process is supported by the SysGrid tool that plays the roles of system configurator and device configurator.
The design process starts with single line diagrams which are automatically transformed to executable function block specifications. The process is based on the Smart Grid control architecture that is a heterogeneous network of controllers communicating in a peer to peer manner. This “artificial nervous system” of the Smart Grid will be capable of self-healing and dynamic adaptation to renewable generation and ever-changing loads. The tool supports system-level design of automation logic in the form of function block networks with compliancy to IEC 61499. The capabilities of SysGrid are demonstrated through the process of designing a distributed protection application.

Click HERE to download the full paper.

IEC 61850 – How to use the Standard in Substations?

The German mirror committee of IEC TC 57 (DKE K 952) is quite active in supporting IEC 61850 and helping the utility industry to discuss the application of IEC 61850 and provide feedback to the international standardization. Congratulation to all experts that have contributed to that work for many years! Well done!
The final documents of the modeling and engineering group provide a great inside view into the many use cases of IEC 61850 in protection and substation automation. The crucial results are written in English, too. Four out of seven topics are published in English:

1. Überblick [DE] / Overview [EN]
2. Engineeringprozess [DE] / Engineering Process [EN]
3. Engineeringwerkzeuge [DE]
4. Modellierungsrichtlinie [DE] / Modeling Guide [EN]
5. Mustermodellierung [DE]
6. Applikationsbeschreibungen [DE] / Application Description [EN]
7. Weitere Applikationen [DE]

Click HERE to access the above documents. The pdf documents are free to download.
Enjoy.

Mismatch of ConfRev values in IED and SCL file

The issue of how can the values of ConfRev (configuration revision) in an IED be consistent with the configuration file during the lifetime of IED has been discussed may times. The final standardized solution is now discussed in the IEC TC 57 WG 10 task force “System Management”.

Here are some hints on the issue that help to understand what to do until we get a standardized solution.

Part IEC 61850-7-2 Edition 2 defines for GOOSE Control Blocks:

18.2.1.6 ConfRev – configuration revision
The attribute ConfRev shall represent a count of the number of times that the configuration of the DATA-SET referenced by DatSet has been changed. Changes that shall be counted are:
– any deletion of a member of the data-set;
– Any adding of a member to the data-set;
– the reordering of members of the data-set; and
– changing the value of the attribute DatSet.
The counter shall be incremented when the configuration changes. At configuration time, the configuration tool will be responsible for incrementing/maintaining the ConfRev value. When configuration changes occur due to SetGoCBValues, the IED shall be responsible for incrementing the value of ConfRev.
If the value of DatSet is set through a SetGoCBValues service to the same value, the ConfRev value shall still be incremented.

Part IEC 61850-6 Edition 2 defines for GOOSE and SV Control Blocks:

confRev
“The configuration revision number of this control block; mandatory. It is recommended to increment it by 10000 on any configuration change, to distinguish this from online configuration changes [by services] leading to an increment of 1 only”

Work-around

In the meantime you have to implement a work-around on your own, e.g., when you implement online changes (caused by services), then the build-in IED Tool (“online tool” in the IED) has to increment the ConfRev value by 1. If you implement a change in the SCL file that is used to configure the IED then you are recommended to READ first the current ConfRev value of the IED and increment by 10,000 and “overwrite” the current value in the SCL file before you re-configure the IED.

It should be specified in the PIXIT file how your IED works (as publisher and/or subscriber).

Please note the tissue 840 (quite new) in which you can read:

“The question, how dynamic changes done online (through the IED front-panel or through communication services) relate to changes made through configuration files and if these changes shall be allowed for real use is a different topic. There is currently a task force active dealing with system management - they will need to address details on how precisely dynamic changes shall be handled compared to static (through configuration) changes.”

http://tissue.iec61850.com/tissue.mspx?issueid=840

In the following document you find also that the issue is well known:

http://www.fgh.rwth-aachen.de/verein/projekte/InterOP_TestReport.pdf

See §2.2.9

There is still some work to be done – you are invited to get involved in the ongoing work of the WG 10 (Project “System Management”) to provide your input on the issue “Configuration Version Control”.

A special group of the German Mirror committee of IEC TC 57 has published a requirement document for IEC 61850 Engineering Systems:

“Anforderungen an IEC 61850 Engineeringwerkzeuge” [Deutsch]