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.

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.