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.

Three New CDVs of IEC 61850 Edition 2 Amendments published

IEC TC 57 just published three new CDVs for Edition 2 documents:

57/1707/CDV
IEC 61850-7-2 A1 Ed.2: Amendment 1 to IEC 61850-7-2 Ed.2: Communication networks and systems for power utility automation - Part 7-2: Basic information and communication structure - Abstract communication service interface (ACSI)
The Amendment solves issues that have been reported and discussed in recent years. Some 50 of them are documented in the Tissue Database for part 7-2.

57/1708/CDV
IEC 61850-7-3 A1 Ed.2: Amendment 1 to IEC 61850-7-3 Ed.2: Communication networks and systems for power utility automation - Part 7-3: Basic communication structure - Common data classes
The Amendment solves issues that have been reported and discussed in recent years. Some 45 of them are documented in the Tissue Database for part 7-3.

57/1709/CDV
IEC 61850-9-2 A1 Ed.2: Amendment 1 to IEC 61850-9-2 Ed.2: Communication networks and systems for power utility automation - Part 9-2: Specific communication service mapping (SCSM) - Sampled values over ISO/IEC 8802-3
The Amendment solves issues that have been reported and discussed in recent years.

All three documents can be accessed publicly.

Please take some time to review both documents.
The documents should be available online for reading and for comments.
Check HERE for the access and for providing comments.

Functional Constraint CO “Control” missing in IEC 61850-7-2 Edition 2

Somebody asked me today: “I did not find the CO Functional Constraint among the Functional Constraint list in IEC61850-7-2{ed2.0}.pdf, section 12.3.3.2 FunctionalConstraint (FC). Please advise what does it represent?”

In IEC 61850-7-2 Ed1, IEC 61850-7-3 Ed1, and IEC 61850-8-1 Ed1 the control model was described partly in 7-2, 7-3 and 8-1. Now we have the complete control model defined in IEC 61850-7-2 Ed2 – without any mapping issue! in IEC 61850-7-3 Ed2 we have defined for controllable data objects (CDCs: SPC, DPC, …) that the service is Control and the payload is as defined in IEC 61850-7-2 Ed2.

CDC: SPC, DPC, INC, ENC, BSC, ISC, APC, BAC adds the control service at the end of the CDCs for controllable data objects:

That is the reason why we have removed the FC=CO from IEC 61850-7-3 Ed2 (and IEC 61850-7-2 Ed2).

The FC=CO is introduced in the mapping in IEC 61850-8-1 Ed2.

From an implementation point of view (in MMS terms) it is more or less the same in Ed1 and Ed2 of the three parts. The description has changed – it is cleaner now … if you know where to find it … I agree it’s a bit confusing …

The Data Objects of CDC for settings like SPG, ING, … are not using the control services to set a value! These CDCs just support SetDataValues (which is a write in MMS …without the control state machines) and other services:

Hope that helps to understand the (mainly editorial) changes in the three parts 7-2 Ed2, 7-3 Ed2, and 8-1 Ed2.