Browse Prior Art Database

Content-based identification of IEC61850 types Disclosure Number: IPCOM000210379D
Publication Date: 2011-Aug-31
Document File: 3 page(s) / 13K

Publishing Venue

The Prior Art Database


For IEC61850-compatible devices, due to interoperability reasons, it is required that the actual IEC61850 types (LN types, DO types, DA types) are described in a corresponding SCL file. Each such type must be assigned an id to distinguish and identify the types. Today's typical approach is to explicitely maintain the ids for types. This means that the user and/or tools need to refer to a "repository" of already defined types to know if a new should be created for a given type definition, or if the type has been already defined. In the proposed approach, the ids are generated automatically based on a hash of contents of type definitions, so no explicit naming of types is required anymore. The solution could simplify the implementation and usage of tools that create IEC61850 type definitions. The content-based identification will result in matching names for matching type even if they were defined independently. It also makes the processing of the definitions (like comparison or merging) easier.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 01 of 3

Content-based identification of IEC61850 types

The IEC61850 standard in parts 7-3 and 7-4 defines common logical node (LN) classes and common data classes (CDC) as well as their semantics. The definitions, however, describe a superset of the possible data model, with mandatory, optional and conditional elements. In addition, it is also possible to add new contents to the model using vendor-specific extensions.

To ensure interoperability, vendors of IEC61850 devices are required to provide exact definitions of actual types within the

section of corresponding SCL (ICD) files. For example, an LN type defines which data from the logical node class is used. An LN type definition is composed of DO entries, each referencing a DO type. A DO type, in turn, is a specification of the content out from the CDC definition. Such type definitions form a hierarchy which further consist of elements of DA type, and finally basic and enumerated types. Each type definition (LN type, DO type, DA type) is identified by an id, which is a string used to distinguish the types.

Type ids are managed directly by the IEC61850 tools that generate the SCL files, or by IED development tools that are used to prepare IED product metadata (often referred to as "typedata") containing definitions of IEC 61850 types exposed by the product. It is a convention that if the same type definition is reused, it should use the same id. Similarly, it must be avoided that the same id is given to two different definitions. The current approach is to use a naming convention for type names, for example they should be constructed using a naming pattern ABC



. This ensures the uniqueness, however it requires that a repository of defined types exists for each IED product or product family in creating SCL data for the respective product. The most difficult part of this scheme is handling of the

part, to make sure that types that differ get a new revision while identical types reuse existing revisions.

In this invention disclosure, it is proposed to introduce a naming scheme for IEC61850 type definitions that is based on a hash (e.g. an MD5 digest) of the contents of the type definition. It is possible (and quite straightforward) to specify a well-defined algorithm that recursively turns an IEC61850 type definition into a sequence of bytes and then computes a hash of that sequence. For example, to calculate a hash of an LN type definition, one could create the bytes sequence as follows:

-append the name of the LN class (represented as bytes, using e.g. UTF8 encoding) -append the count of DO elements within the LN type definition
for each DO element

-append the name of the DO entry
append (recursively) the sequence of bytes corresponding to the DO type definition.

The bytes sequence for the referenced DO type definitions would be generated similarly using DA entries and so on, recursively, down to basic and enumerated types. The whole byte sequence would be then used to calculate t...