How Many and Which Information Models are defined in IEC 61850?

I guess you have heard that IEC 61850 defines a lot of Information Models. Yes, You are right.

The models are managed exclusively by the corresponding working groups with the Enterprise Architect UML Tool (the UML data base is for internal use only). The model version:

UML model of 61850 (wg10built6-wg18built3-wg17built5-jwg25built2-tc17built1-tc38built1.eap)

comprises the following number of Logical Node Classes, Data Objects (Attributes), Enumerations and Abbreviations:



An excerpt from the UML modes looks like this:



The UML Model is the single source data base that is used for the extensions and maintenance of the model, as well as the generation of Word or PDF documents ... The PDF documents are sold by IEC and other organizations.

You may complain that the standards are not for free ... hmm ... BUT look: You can download the various Code Components for free.

Click HERE for the Code Component for IEC_61850-7-4.NSD.2007A2.light.zip (IEC 61850-7-4 2007A2 NSD light, see the IEC 61850-7-4:2010 for full legal notices). The full version has additionally the semantic descriptions of the models.

Example of Enumeration:


Example of excerpt of LN Class MMU:



Click HERE to see the list of all Code Components as per today ... more to come soon.

To my understanding you can model many required information generated and consumed by a huge number of applications in almost all application domains of automation in the electrical system and beyond.

As the above example of MMXU shows, you can use this LN Class wherever you have 3 phase AC system!! In a building heating system for the electrical values of a compressor or a fan or a pump or ... the blue sky is the limit for the applications.

Click HERE to learn about crucial details discussing the LN Class MMXU and how it can be applied ... you may have never expected this comprehensiveness of the MMXU.

Note that the 3 phase system was first (more than 100 years ago) - then we have put a facade in front of the measurement function which exposes the measurements as data objects of the class MMXU. The application has driven the class - not vice versa.

The current edition 2.1 models defined in IEC 61850-7-3 and 7-3 are listed in the contents tables of the preview documents. The following Preview documents (free access) for models of the edition 2.1 consolidated versions are available:

Preview IEC 61850-7-3 Edition 2.1
Preview IEC 61850-7-4 Edition 2.1

Example of 7-4 from the preview:



In case you find any error in the standards, please visit the Tissue Database:
https://iec61850.tissue-db.com/parts.mspx

IEC 61850: Usage of XML Schemata for Model Name Space Definitions

One of the crucial challenges in dealing with IEC 61850 is the sheer unlimited amount of Models (Logical Nodes, Data Objects, Data Attributes, Data Attribute Types, ... and related Services). How to manage these? How to figure out which model was valid last year, which model details are currently valid, ... questions, questions ...
What are the answers to these questions? Simply: good documentation of content, modifications, extensions, and changes.
The IEC TC 57 WG 10 has published a document that defines the rules for model content of IEC 61850 based core data model in IEC 61850-7-2, IEC 61850-7-3 and IEC 61850-7-4. Other domains (like DER, Hydro, Wind, etc.) could define their own data model based on IEC 61850 core data model to be able to use IEC 61850 core parts as a common layer.

The published 70 page document 57/1925/DTS contains the new draft rules:

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

The voting and commenting period closes 2017-12-15

"Year after year the IEC 61850 data models are extended both in depth with hundreds of new data items, and in width with tens of new parts.
In order to foster an active tool market with good quality, and at the end to improve IEC 61850 interoperability, we need a machine-processable file describing data model related parts of the standard as input. This is the purpose the new language Name Space Definition (NSD) defined by this part of IEC 61850.
This will avoid the need for any engineering tool related to the IEC 61850 data models to get the content of the standard manually entered, with the highest risk of mistakes. This will also help spreading easily any corrections to the data model, as requested to reach interoperability. Tool vendors will be able to integrate NSD in their tools to distribute the standard data models directly to end users."

This new document seems to be crucial for all experts that deal with models and their implementation in Tools and IEDs.

What is an IEC 61850 Data Model – Come and See

Data or device modeling is a crucial feature of IEC 61850 and IEC 61400-25. You may have seen many different approaches to explain how such a model looks like. Some five years ago I used these Russian dolls (matryoshka doll):

An IED contains a lot of “inner” objects.

 

Today I have thought that another approach may help you to understand the IEC 61850 approach:

What do you think? This and more will be explained in detail during my comprehensive – most liked – courses.

Out-Of-Range Quality Flag and Reporting Quality-Change Event

In addition to the following two discussions that contain a view on measured values:

What Does Complexity of a Protocol Mean-
Are you prepared for the Solar Eclipse 2015 on March 20-

I will now look into the possibility to automatically monitor and report the limit violation of a measured value using standard configuration of IEC 61850 Information Models (LN STMP1), Data Sets and Report Control.

There are two options to report the temperature value reaching the maximum possible value: using the quality information of the “Tmp.q” (configured by the configuration of the “max” value in “rangeC”) or the “Alm” (configured by “TmpAlmSpt”) as depicted in the following figure:

We need to configure a Data Set and a Report Control Block for each case. In case of using “q” we have to communicate and interpret the “q” value “questionable and out of range” (which is a bit pattern!). In case of using the alarm data object “Alm” we just send and receive a simple Boolean value “True”. There is no need to interpret a bit pattern.

For machines it should be no big difference to analyze a bit pattern or a Boolean value.

Both approaches would provide the information that a measured value is higher than a specific limit (max or alarm limit). Which one you would like is up to you.

It is recommended that for specific domains it is specified in a “profile” document, which option to use. Maybe you want to use both: the “q” for asset management and the “Alm” for Automation functions to automatically start a cooling system. The “Alm” could easily be used for GOOSE messaging to inform a wide range of subscribers of the alarm …

The nice thing is that you can easily configure the multiple options just by SCL !! No programming needed – if the values of “q” and “Alm” are provided by the application.

Lesson learned: First define your need – then design the behavior of your Report and GOOSE messaging. If you don’t know what you want to accomplish, no standard can help you.

COSEM Object Model (IEC 62056) carried with IEC 61850 Data Model

IEC TC 57 has just published a very interesting new draft (57/1521/CD):

IEC 61850-80-4 TS:
Communication networks and systems for power utility automation - Part 80-4:
Translation from COSEM object model (IEC 62056) to the IEC 61850 data model

The IEC 61850 is already THE international Standard series when it comes to (electric) power applications and information modeling and exchange. Metering Information is quite often exchanged with DLMS and COSEM:

COSEM (Companion Specification for Energy Metering) is part of the DLMS (Device Language Message Specification)

This information needs to be “fed” into the IEC 61850 world. That is done by defining how the corresponding COSEM information can be wrapped with IEC 61850 Logical Nodes and Data Objects. The title says: Translated … which means the same.

Here is an example:

IEC 61850 Data	COSEM OBIS Code	Explanation
TotVAh	(1-b:9.8.0.255) – (1-b:10.8.0.255)	Net apparent energy
TotWh	1-b:1.8.0.255 - 1-b:2.8.0.255 (¦+A¦ - ¦-A¦)	Net real energy
TotVArh	1-b:3.8.0.255 - 1-b:4.8.0.255 (¦+R¦ - ¦-R¦)	Net reactive energy
SupWh	1-b:1.8.0.255 (+A)	Real energy supply (default supply direction: energy flow towards busbar and is equivalent to Energy Export[+])
SupVArh	1-b:3.8.0.255 (+R)	Reactive energy supply (default supply direction: energy flow towards busbar and is equivalent to Energy Export[+])
DmdWh	1-b:2.8.0.255 (-A)	Real energy demand (default demand direction: energy flow from busbar away and is equivalent to Energy Import[-])
DmdVArh	1-b:4.8.0.255 (-R)	Reactive energy demand (default demand direction: energy flow from busbar away and is equivalent to Energy Import[-])

These IEC 61850 Logical Nodes are of interest for the translation:

MMTR - Metering 3 Phase
MMTN - Metering Single Phase
MMXU - Measurement
MMXN - Non-phase-related measurement
MMDC - DC measurement
MSQI - Sequence and imbalance
MHAN - Non-phase-related harmonics or interharmonics
MHAI - Harmonics or interharmonics
MFLK - Flicker measurement

Closing date for comments: 2015-02-20

Another draft standard that “copies” IEC 61850 Logical Nodes

ISO/TC 205/WG 3 (Building Automation and Control System (BACS) Design) has published recently a new work proposal on power system information models [ISO/TC 205 / SC N 410].

Title: Facility Smart Grid Information Model

Purpose and justification of the proposal:
”The purpose of this standard is to define an abstract, object-oriented information model to enable appliances and control systems in homes, buildings, and industrial facilities to manage electrical loads and generation sources in response to communication with a “smart” electrical grid and to communicate information about those electrical loads to utility and other electrical service providers.

This proposed standard will define an information model intended to provide a basis for revision or creation of technology- specific communication protocol standards that enable products and services to control the operation of electrical energy generating and consuming devices found in homes, commercial buildings, institutional buildings, and in manufacturing and industrial facilities, in cooperation with energy providers in a "smart grid" environment.”

The new work item proposal states that “This proposal builds upon work done by IEC/TC 57 Power Systems Management and Associated Information Exchange … There is no known conflict with an existing IEC or ISO standard or project.”

There may be no conflict … the proposal (same as Draft standard BSR/ASHRAE 201P) “copies” Logical Nodes from IEC 61850 and modifies the Data Object names. For example:

Excerpt from Draft standard BSR/ASHRAE 201P:

5.7.3.3.1.5. DEROperationalModeControls

Operating mode at the ECP.
Control of the operational modes of the DER – constant watts, constant vars, …More than one mode can be set simultaneously for certain logical combinations (61850
Logical Node = DOPM).
Parent Class(es): CommonLN
UML element location: Model Elements from External Sources.IEC61850.61850-7-420. DEROperationalModeControls.

Table 5.193 - Class Attributes

Data Object	Description	CDC
OperationalModeConstantW	Mode of operation - constant watts.	SPC
OperationModeConstantPowerFactor	Mode of operation - constant power factor.	SPC
OperationModeConstantV	Mode of operation - constant voltage.	SPG

Excerpt from Standard IEC 61850-7-420 (LN DOPM):

Data Object	Description	CDC
OpModConW	Mode of operation – constant watts	SPC
OpModConPF	Mode of operation – constant power factor	SPC
OpModConV	Mode of operation – constant voltage	SPC

So, changing the names from abbreviated names to full text names makes it another standard information model … why? If other groups “copy” the Logical Nodes and Data Objects they should keep the names … Or?

I guess the main reason for this is:

Genesis 11:9 “Therefore, it is named Babel, because there the LORD mixed up the language of all the earth.” … languages spoken by humans and by computers!

How to define New Data Objects in IEC 61850?

The need to define new data objects is likely to have various reasons. One reason is that experts do not know which logical nodes and data objects are already defined. Let’s assume there is really a need for a new data object – there is not any data object that may fit.

Example (The following LN SIML, I found on the Web):

The standard LN SIML (Insulation Medium Supervision) provides the data object H2ppm (Measurement of Hydrogen (H2 in parts Per Million)):

There is a need to model H2ppm related semantic, e.g., “Hydrogen ppm Rate of Change” or “Hydrogen ppm Rate of Change Goodness of Fit”

These two semantic models are not defined in the standard. What is the best way to model these two?

1. Defining values in GGIO? – maybe not,
2. Defining new data objects in SIML? – may be the best solution (could be standardized later), or
3. Defining something like H2ppm1 (measured value), H2ppm2 (rate of change”, and H2ppm3 (roc Godness of Fit)? – That is definitely wrong!

Why are the following data objects in conflict with the standard modeling method?

Here is the definition for LN SIML (of the example I found) using multiple instances of H2ppm, defined in the Insulation Medium Supervision (Product Specification):

The standard IEC 61850-7-4 Edition 2 defines the LN as follows:

LN: SIML Name: Insulation Medium Supervision (Standard IEC 61850-7-4 Edition 2):

These data objects H2ppm1, H2ppm2, and H2ppm3 are not allowed – it is not allowed to instantiate data objects (with some exceptions, then the data object in the standard LN needs to be defined as MyDataObject1 – with a “1” at the end)!

For details on instantiating data objects see the following excerpt of IEC 61850-7-1 Edition 2 that defines the extension rule for data objects:

14.6 Specialisation of data by use of number extensions

Standardised data names in logical nodes provide a unique identification. If the same data (i.e. data with the same semantics) are needed several times as defined, additional data with number extensions shall be used. The rules for number extensions shall follow the naming conventions defined in IEC 61850-7-2 and be as follows:

• the number extension usage shall only be defined by the owner of the data namespace. This shall be done by adding the number extension 1 to a data object name (e.g. data1),
• data with no number extension shall not be extended by third parties,
• data with the number extension 1 can be extended. Number extensions may be ordered or not (1,2,3,4, or, 1,2,19,25),
• if only one instance of an extendable data is present in an LN, it shall have the number extension “1”.

14.8 Example for new Data

New Data “Colour of Transformer Oil”

The above figure shows also that a data Namespace Attribute “datNs” has to be specified for each new data object.

For the above listed additional semantic it would work with the following (standard conformant) extended data object definitions:

Example (wrong – semantic is in instances):
H2ppm1 (measured value)
H2ppm2 (rate of change)
H2ppm3 (roc Godness of Fit)

A standard conformant solution is (define new data object classes):
H2ppm (measured value)
H2ppmRoc (rate of change, extended data with datNs=Vendor so and so )
H2ppmRocGdns (roc Godness of Fit, extended data with datNs=Vendor so and so)

Please find further presentations on model extensions:
Click HERE for post1.
Click HERE for post2.