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.

New Work Items Proposed within IEC TC 57 (IEC 62351-14)

57/1746/NP
Power systems management and associated information exchange - Data and communications security - Part 14: Cyber security event logging (proposed IEC 62351-14)

This part 14 of the IEC 62351 series specifies technical requirements for logging cyber security events: transport, log data and semantics, such as how to send and receive security events securely, reliably, how to forward security events or logs, etc.
The purpose of this standard is to specify the requirements needed by the power industry to meet
their cyber security needs, to comply with cyber security regulations and standards, and to guarantee
interoperability among different vendor products.

Logical Node "GSAL" (Generic security application), IEC 61850-7-4, is recommended to take into account with the already published data objects:

AuthFail       Authorisation failures
AcsCtlFail    SEC Access control failures detected
SvcViol        SEC Service privilege violations
Ina                SEC Inactive associations
NumCntRs   Number of counter resets

Ballot closes 2016-09-30

IEC 61850 DLL Demo with Looging and Log-File

The DLL Demo based on SystemCorp’s IEC 61850 Stack/API can very easily be configured with the corresponding CID-File for the Server to log data attributes listed in a DataSet. The log entries are stored in an XML file.

All you need to do is: Add the following 3 lines in the configuration file (after line 52):

Directory: /Resources_localhost (/Resources_2machines)
File: /VHPServer_localhost.icd (/VHPServer_2machines.icd)

<LogControl datSet="BHKW_ST1" intgPd="0" logEna="true" logName="DLLDemo" name="DLLTestLog">
    <TrgOps dchg="true"/>
</LogControl>

Restart the Serer and you have a log that is filled with events coming through the DataSet "BHKW_ST1".

Model as seen by an IEC 61850 Client (Browser):

The file format (DLLDemo.Xml) is vendor-specific:

Two Log Entries (4 and 5):

Note: The time stamp “t” is “000…0” because the Server application program is not providing it to the Stack … this could be done by extending the C# application source code that comes with the Demo package … if you are familiar with C# programming.

The services QueryLogByTime and QueryLogAfter will be available in the future.

The Log Model is available in the SystemCorp Library. It means, e.g., it is available in devices like the HMS SG line. The log file may grow very fast … be careful not to consume all memory resources. In the future the file will represent a circular buffer so that it will never overflow (by overwriting the oldest entries – as defined in IEC 61850-7-2).

There is a possibility to convert the XML coded Log file into another XML based file: COMFEDE („Common Format for Event Data Exchange") published by IEEE.

Click HERE for Information on COMFEDE (DE).
Click HERE for Information on COMFEDE (EN).

Click HERE if you are interested to download the DLL Demo.

Question & Answer: What is the IEC 61850 EntryTime?

EntryTime is, e.g., used for IEC 61850 Log Entries to identify when a log entry has been stored.

Here is a Log Entry (encoded as an XML document):

<JournalEntry Entry="26" Day="11647" ms="19228670" Order="0">
  <Variable Tag="ServerIEDExample/CSWI0$ST$Pos$stVal">
    <BitString>00</BitString>
  </Variable>
  <Variable Tag="ServerIEDExample/CSWI0$ST$Pos$stVal|ReasonCode">
    <BitString>08</BitString>
  </Variable>
  <Variable Tag="ServerIEDExample/CSWI0$ST$Pos$q">
    <BitString>0000</BitString>
  </Variable>

The IEC 61850 EntryTime is mapped to MMS TimeOfDay:

The MMS TimeOfDay epoch began at 0 hours on 1 January 1984 (MJD 40 587). Times measured are designated in this standard as MMS TimeOfDay milli-seconds GMT and TimeOfDay days GMT, and represent offsets from the epoch.

How to translate the above time to date and time?

Day translates:
http://www.convertunits.com/dates/from/Jan+1,+1984/to/Nov+21,+2015

Date difference from Jan 1, 1984 to Nov 21, 2015
The total number of days between Sunday, January 1st, 1984 and Saturday, November 21st, 2015 is 11,647 days.

Milli-second translates:
https://www.unitjuggler.com/convert-time-from-ms-to-day.html?val=19228670

~=  5 hr. 20 min. 28 sec. 670 ms

Saturday, 21st November 2015 05:20:28:670

It is that easy.

By the way, the above log is generated by the SystemCorp Stack/API by simply adding three (3) lines in an CID File (in this case for the Smart Grid Gateway of HMS supporting Modbus, M-Bus, Profibus, Profinet, EtherNet/IP…):

<LogControl datSet="GooseDS" intgPd="0" logEna="true" logName="ServerIED" name="TestLog">
    <TrgOps dchg="true"/>
</LogControl>

Stay tuned for more features.

Can IEC 61850-7-2 Edition 2 be used to build Agents?

There are more and more discussions on the question if IEC 61850 could be applied to build an Agent. Some understand this as IEC 61850 versus Agent.

What is an Agent? There are as many answers when you ask experts.

I found a very interesting definition of an (special) Agent on Wikipedia:

“Monitoring and surveillance agents (also known as predictive agents) are a type of intelligent agent software that observes and reports on computer equipment. Monitoring and surveillance agents are often used to monitor complex computer networks to predict when a crash or some other defect may occur. Another type of monitoring and surveillance agent works on computer networks keeping track of the configuration of each computer connected to the network. It tracks and updates the central configuration database when anything on any computer changes, such as the number or type of disk drives. An important task in managing networks lies in prioritizing traffic and shaping bandwidth.”

More generally Wikipedia provides a definition of an Agent:

“In computer science, a software agent is a piece of software that acts for a user or other program”.

IEC 61850 can be used for many applications: Protection and Control in Substations, SCADA, monitoring any simple and complex computer based applications in the (power system) Automation or assets like transformer, etc. This covers also network components like Ethernet Switches – there is work underway to model the network management MIB onto Logical Nodes and DataObjects and use the IEC 61850 services!. An IEC 61850 Server can act for a Client (and its User – a person or program). Crucial characteristics of Agents can be found in IEC 61850, too. You are not (yet) convinced!?

Let me point to the Edition 2 of IEC 61850-7-2 (ACSI) published in August 2010. What is new there? A lot great stuff for more secure systems!

Edition 1 had already the service model of Reporting and Logging observing (monitoring) application information like status or limit violations – allowing to send and log spontaneous events. There was also a possibility to monitor attributes of the various control blocks (Reporting, Logging, GOOSE, SMV); allowing to report or log the enable request of a control block. This last application has been extended in Edition 2 to keeping track of all ACSI services.

Edition 2 of IEC 61850-7-2 introduces the concept of the Service tracking in clause 14:

The reporting and logging functions of process and function related data objects as defined in Edition 1 of IEC 61850-7-x and IEC 61400-25-2 are extended in Edition 2 of IEC 61850-7-2 to keep track of changes, event, or actions in the process related information modeled as Logical Nodes and DataObjects. IEC 61850-7-2 Edition 2 provides the possibility to keep track of all services, even those with negative responses. The services are classified as follows:

• Control block related services
• Command related services
• Other services

IEC 61850-7-2 Edition 2 defines additional specific common data classes for each type of service to be reported or logged. For a given Server, a single data object instance (tracking data object) needs to be instantiated in the object model for each kind of service, that will mirror the value of the service parameters exchanged and its acceptance by the server. This allows that a service can be logged or reported to any client. This requires that the tracking data object is a member of the data-set referenced by a LCB, BRCB, or URCB.

The following additional Common Data Classes (CDC) are defined in IEC 61850-7-2 Edition 2:

• Common service tracking (CST)
• Buffered report Tracking Service (BTS)
• Unbuffered report Tracking Service (UTS)
• Log control block Tracking Service (LTS)
• GOOSE control block Tracking Service (GTS)
• MSVCB Tracking Service (MTS)
• USVCB Tracking Service (NTS)
• SGCB Tracking Service (STS)

The tracking of services could be used to record the “manipulation” of the process and the information exchange control block attributes, e.g., the settings of relays or other functions. The FERC CIP (Critical Infrastructure Protection) requires to keep logs (records) of many information changes. The reporting and logging of IEC 61850-7-2 and the extended common data classes could be used to implement such a “Recorder” or “Data Logger”.

IEC 61850 (IEC 61400-25) provides a reach suite of service-oriented, event-driven or agent-oriented application and information exchange models.

The answer of the question in the headline is simply: YES, IEC 61850 can.

Basics of IEC 61850 Control Blocks and Communication

The standards IEC 61850 and IEC 61400-25 provide a reach suite of information exchange mechanisms. The basis of all exchanges are the information models (e.g., Logical Node “QE3XSWI1.Pos" that represent the real world information. The information models are shown on the right side of the following figure. DataObjects can be read at any time.

The next level on-top of the information models are the DataSets. A DataSet is a list of references to attributes of DataObjects (e.g., Pos). DataSets can be read – which is an optimization: instead of a list of references, there is only a single name to be provided (the DataSet name) for reading.

The third level are the Control Blocks (for reporting, Logging, GOOSE, and Sampled Values). All three levels constrain the way how values are communicated.

Details are presented, discussed and trained in the hands-on trainings of NettedAutomation.

Note that all four control blocks provide appropriate services for SCADA, real-time control, and protections. Applications in distributed automation (for power distribution automation) are likely to require additional features (communication between hundreds of devices, …).

One of the real crucial approaches is that the Data Objects are independent of the Data Sets, which are independent of Control Blocks. The SystemCorp IEC 61850 API provides almost everything discussed in this post! The API supports any Logical Node (standardized and extended!). The API runs smoothly on the BECK IPC 61850@CHIP.

If you want to know which of the above options you should apply, please let me know WHAT YOU NEED !!