Wednesday, November 20, 2019

IEC 61850 Deadband Reporting and Logging - What Does It Provide?

IEC 61850 Reporting and Logging are very useful services to keep the needed bandwidth for messaging low. It is a bit tricky to understand how it works ... due to the fact that there are two documents that need to be studied to understand the function (IEC 61850-7-2 and IEC 61850-7-3). And: You need to know that some changes in the operation of Reporting and Logging happened from Edition 2 to Edition 2.1 (soon to be published as International Standard).

Deadbanding in IEC 61850 provides a filter mechanism that defines, when an analogue value will be reported by the IED (Server side) to another system (Client side).

Edition 2 of IEC 61850-7-3 defines:

"Deadband. Shall represent a configuration parameter used to calculate all deadbanded attributes (for example mag attribute in the CDC MV). The value shall represent the percentage of difference between max. and min. in units of 0,001 %.
If an integral calculation is used to determine the deadbanded value, the value shall be represented as 0,001 % s.
A db value of 0 shall suppress reporting events on the analog value, so that only changes of the range value will lead to events."

Edition 2.1 of IEC 61850-7-3 will define:

"Deadband is a configuration parameter used to calculate deadbanded value 'mag'. The value of 'db' shall represent the percentage of 'dbRef' in units of 0.001 %. Therefore, 'db' = [0...100000], corresponding to [0 %...100 %], respectively. If an integral calculation is used to determine the deadbanded value, the value of 'db' shall be represented as 0.001 %s.
With a 'db' = 0 the attribute 'mag' follows the instantaneous value.
If 'db' is not present in the model, then the deadband calculation is a local issue."

See Tissue Data Base on deadbanding.

"db" = 0 is a dangerous configuration value!! It is like divide by "0". Any (small) change of "instMag" will issue a report or log entry. I am a little bit confused ... but finally it may help with the following use case: Output of the Schedule "ValMV" that is of CDC "MV". See the following figures for some details:


"db" >= 0 could reduce the number of events (reports/log entries) for analogue values. Usually an analogue value is a measurement or a calculated value.

In case of modeling schedules (FSCH in IEC 61850-90-10 / IEC 61850-7-4 Ed2.1) it is required to report/log a scheduled value - which is similar to a measurement ... but it is a non-continuous value (has "jumps" only) ... OK. CDC MV is used for the Output of a Schedule. What is the impact of the "db" value?!? Be careful!
The following figure discusses the impact of trigger option "data change" and "db"=0 as well as "data update":



Finally: If you need to see (as a client) changes only, then "db"=0 is the right configuration. If you want to receive/log a "confirmation" of any new value at the beginning of a new Schedule Interval (SchdIntv) then "data update" is the right configuration.

You need to understand your needs before you decide how to configure deadbanding.

Tuesday, November 19, 2019

The History Of The IEC 61850 Modelling

The standardization of IEC 61850 started in 1995 when the IEC TC 57 Working Groups 10, 11, and 12 had been setup. Later all projects have been moved to the Working Group 10 - that is still (very!) active today.
Prior to the new project proposal for IEC 61850 the EPRI UCA project developed core models for many signals and communication services. UCA used a simple table notation for defining "models".
The experts involved have discussed several options how to model the signals. In December 1998 the editors of the core documents (including myself) met in Ann Arbor (MI, USA).


We discussed modelling with ASN.1 or our own notation:



we were not quite happy ... then we discussed trying UML … walked across the street to the University bookshop to purchase some 10 Books about UML Modelling. I purchased several books, too:





… a senior development manager of protection relays was strictly against UML … he said, it will never be used for protection and automation. Some weeks later I met his engineers in their office … and saw that they used UML for developments …

Later I tried OWL with some success:



Experts involved in CIM (Common Information Models) used UML - with the SPARX tool Enterprise Architect (EA). It took several years before UML (and EA) was used to define all models of IEC 61850. Today (end of 2019) almost all models and other definitions are managed with the EA - it is a big success! The latest version comprises the following parts:


There are tools available to export parts of the model from EA as Word documents, html pages, pdf ...

Example of a model:



With the application of the SPARX EA we have a single source of all crucial definitions.

Note: The EA package "IEC61850Domain" is only available for the experts writing, publishing and maintaining the various standard parts.

Some exported documents (the so-called code components) are available for free access:
Click HERE for accessing these documents.

Thanks to the experts that have continuously pushed for using UML and EA. It took several years ... and it was not easy for engineers to use a formal language and tool to get where we are today.

These days the EA is used also for many other tasks: use cases, design state machines like for IEC 61850-90-16 (System management), ... IEC TC 57 has done a good job in using UML for CIM and IEC 61850. But another generation of engineers is needed to understand the full benefit of using UML.

Wednesday, November 13, 2019

E-Book verfügbar: etz Report 34 "Offene Kommunikation nach IEC 61850 für die Schutz- und Stationsleittechnik"

Der lange Zeit vergriffene etz Report 34 (2004, 159 Seiten):

"Offene Kommunikation nach IEC 61850 für die Schutz- und Stationsleittechnik"

ist als E-Book verfügbar!

Hier klicken, um die E-Book-Version zu erwerben.

Friday, November 1, 2019

Draft IEC TR 61850-90-18 on Alarm Handling Published

IEC TC 57 just published a new 50 page draft part of IEC 61850 (57/2157/DC):

IEC Draft TR 61850-90-18
Communication networks and systems for power utility automation –
Part 90-18: Alarm handling in IEC 61850 based systems

Comments are expected by Nov 29, 2019.

Work is done by TC 57/WG 10 together with TC 88/JWG 25 (Wind Turbines).

This part defines a methodology to handle alarms. The crucial concept is defining an “Alarm Server”.

Use-cases considered are related to:
WG 10: IED communications & associated data models in power systems
WG 17: Distributed Energy Resources
WG 18: Hydroelectric power plants
JWG 25: Wind Power

Sample Use case: Wind power system
"Several clients connected either to an alarm concentrator handling alarms from a system of
identical distributed IED’s or directly to one specific IED. Some of the alarms are defined as
latched and all alarms are defined either with or without acknowledgement.
If a wind turbine is maintained and thus in service state, all alarms must still be captured and
exposed, but marked with an “in-service” flag for filtering (and not to be annunciated).
The IED’s may either be proprietary devices or comply with IEC 61850.
Domain: Common in wind-power domains."

IEC TC 57 WG19 proposes CIM Profiles to JSON schema Mapping

IEC TC 57 WG is discussing the use of JSON for transferring message payload

DRAFT 62361-104:
POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION
EXCHANGE – INTEROPERABILITY IN THE LONG TERM –

Part 104: CIM Profiles to JSON schema Mapping

The introduction says:

"This standard is one of the IEC 62361 series which define standards that may be used by all
Working Groups within TC57. These standards address areas of interest that impact multiple
standards and provide consistency for implementations.
This part 104 describes a mapping from CIM profiles to IETF JSON schemas and defines the
rules that CIM JSON message payloads must adhere to.
The principle objective of this part 104 is to facilitate the exchange of information in the form of
JSON documents whose semantics are defined by the IEC CIM and whose syntax is defined by
an IETF JSON schema. ..."

JSON is applicable for encoding of CIM (IEC 61968/70) message payload and - as I believe - also for IEC 61850 message payload!

By the way: The post on "IEC 61850-8-2 Versus IEC 61850-8-1" discussing the use of JSON in addition to MMS/ASN.1/BER and MMS/ASN.1/XER has been visited 2,000 times since July 5, 2019 --> or 16 times per day.

Click HERE for additional discussion on the use of JSON ...

3-Day Training for Electrical Engineers New to IEC 61850

3-Day Training for Electrical Engineers New to IEC 61850

17-19 March 2020 | London, UK

Day One: Tuesday 17 March
Core Concepts
Overview of IEC 61850 and introduction to the core concepts, including the hierarchical data model, communication services and the range of applications possible.

Day Two: Wednesday 18 March
Engineering and Configuration
Deep-dive into the IEC 61850 engineering process, learning how to use Substation Configuration Language and engineering tools for IEC 61850 specification, system design and IED configuration.

Day Three: Thursday 19 March
Testing
Learn how to thoroughly test IEC 61850 systems, including functional and system testing as well as gaining an overview of cybersecurity considerations for IEC 61850 systems.

Click HERE to learn more.