IEC TC 57 Just Published Draft IEC TS 618540-1-2 - Extending IEC 61850

IEC TC 57 just published the 43 page draft 57/2084/DTS:

Communication networks and systems for power utility automation IEC 61850-1-2 -
Guideline on extending IEC 61850

CLOSING DATE FOR VOTING: 2019-06-07

Excerpt of the draft:
------------
1 Scope
This document is intended for any users but primarily for standardization bodies that are considering using IEC 61850 as a base standard within the scope of their work and are willing to extend it as allowed by the IEC 61850 standards. The document identifies the required steps and high-level requirements in achieving such extensions of IEC 61850 and provides guidelines for the individual steps. Within that scope, the document addresses the following cases:

• The management of product-level standards for products that have an interface based on IEC 61850
• The management of domain-level standards based on IEC 61850
• The management of transitional standards based on IEC 61850
• The management of private namespaces based on IEC 61850
• The development of standards offering the mapping of IEC 61850 data model at CDC level
• The development and management of IEC 61850 profiles for domains (underlying the role of IEC 62361-103 and IEC 61850-7-6)

The document includes both technical and process aspects :
On the technical side, the document:

• Reminds the main basic requirements (mostly referring to the appropriate parts of the series which host the requirements or recommendations)
• Lists all possible flexibilities offered by the standards
• Defines which flexibilities are allowed/possible per type of extension cases

On the process side, the document covers:

• The initial analysis of how the existing IEC 61850 object models and/or communication services may be applied and what allowed extensions may be required for utilizing them in new or specific domains (including private ones). The results of that step are expected to be documented
• The extension of the IEC 61850 object models for new domains. The typical associated work is to identify existing logical nodes which can be reused “as is”, to determine if existing logical nodes can be extended, or to define new logical nodes
• The purpose and process to use transitional namespaces, which are expected to be merged eventually into an existing standard namespace
• The management of standard namespaces
• The development of private namespaces

---------------

It is highly recommended to have a closer look at this document and review the content in detail. Because in the end it will be used as a very crucial "cook-book" for those that need to extend the standard series IEC 61850 and IEC 61400-25.

How to use Generic Input/Output Logical Node "GGIO"

The Logical Node Class GGIO (Generic Process I/O) is (in my experience) the most liked and hated Logical Node. Why? GGIO is often used instead of well known Logical Nodes.
Example: Use of GGIO0.ST.Ind1.stVal instead of XCBR0.ST.Pos.stVal
The use of GGIO is not standardized!
You may use it or not ... one way or the other.
Last week I was contacted by an utility engineer on how to map reporting signals (M1-Boolean, M2-Boolean, M3- ...)?
There are two general approaches in the use of GGIO:

1. Add semantic to Prefix of LN and use many GGIO instances (M1_GGIO1, ...)
2. Add semantic to extended Data Objects in GGIO (M1, ...)


In the first case we instantiate GGIO 10 times.
In the second we extend the model by defining Data Objects M1 ... M10

The main difference is that in the second example we can use the prefix of the GGIO ("Report_") -> "Report_GGIO0" as a wrapper for Reporting. The semantic of the signals is further defined by extended Data Objects "M1", "M2", ...
Both modelling approaches are defined in IEC 61850-7-1 and 7-4. The second approach may not be supported by all tools and devices.
I personally would prefer the second approach.

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.

Utility Grid Communication Network in Electric Vehicle Charging Infrastructure takes IEC 61850 into Account

The IEC TC 69 (Electric road vehicles and electric industrial trucks) has proposed a new project to define "Utility grid communication network in electric vehicle charging infrastructure" - 69/176/NP. The New work proposal refers to IEC 61850 as standard that should be considered as base standard. It could be assumed that IEC 61850 has already a lot of definitions that can be re-used by the experts that will define this standard. It is likely that IEC 61850-7-420 has already many information models defined for that application.

Voting is open between 2010-09-17 and 2010-12-17

Click HERE for a the official IEC announcement. Contact your national body to get a copy of the proposal.

How to extend Models of IEC 61850 and IEC 61400-25?

Very often you can hear that IEC 61850 and IEC 61400-25 could be applied for new use cases only if new Logical Nodes would be standardized - which may take several years. Waiting years for new models is not what many companies and groups are looking for. Why to wait for years?

IEC 61850 has implemented a rule on how to extend and define new models: Name Space concept. This concept allows for defining extensions and new models (Logical Nodes, Data Objects, Common Data Classes).

Click HERE for an example of an extended Model: an new Logical Node (links to the next blog posting).