Out-Of-Range Quality Flag and Reporting Quality-Change Event

In addition to the following two discussions that contain a view on measured values:

What Does Complexity of a Protocol Mean-
Are you prepared for the Solar Eclipse 2015 on March 20-

I will now look into the possibility to automatically monitor and report the limit violation of a measured value using standard configuration of IEC 61850 Information Models (LN STMP1), Data Sets and Report Control.

There are two options to report the temperature value reaching the maximum possible value: using the quality information of the “Tmp.q” (configured by the configuration of the “max” value in “rangeC”) or the “Alm” (configured by “TmpAlmSpt”) as depicted in the following figure:

We need to configure a Data Set and a Report Control Block for each case. In case of using “q” we have to communicate and interpret the “q” value “questionable and out of range” (which is a bit pattern!). In case of using the alarm data object “Alm” we just send and receive a simple Boolean value “True”. There is no need to interpret a bit pattern.

For machines it should be no big difference to analyze a bit pattern or a Boolean value.

Both approaches would provide the information that a measured value is higher than a specific limit (max or alarm limit). Which one you would like is up to you.

It is recommended that for specific domains it is specified in a “profile” document, which option to use. Maybe you want to use both: the “q” for asset management and the “Alm” for Automation functions to automatically start a cooling system. The “Alm” could easily be used for GOOSE messaging to inform a wide range of subscribers of the alarm …

The nice thing is that you can easily configure the multiple options just by SCL !! No programming needed – if the values of “q” and “Alm” are provided by the application.

Lesson learned: First define your need – then design the behavior of your Report and GOOSE messaging. If you don’t know what you want to accomplish, no standard can help you.