Bounds Filter

The foglamp-filter-bounds filter is a plugin that allows limits to be set for assets containing numeric datapoints within FogLAMP. It generates a new status datapoint based on the lower and upper bounds defined for a datapoint.

This filter can be added to a south service, north service, or a north task. It is particularly useful for monitoring assets with numeric datapoints and generating a health status based on the defined bounds.

The process to add Bounds filter is like adding any other filter

  • Click on the Applications add icon for your service or task.

  • Select the bounds plugin from the list of available plugins.

  • Name your Bounds filter.

  • Click Next to be presented with the configuration page.

  • Configure your bounds filter.

  • Enable your filter and click on Done

Configuration

The configuration of filter is divided into two groups within configuration page as documented below.

Basic

boundsconfig

  • Asset: Asset name for which the filter should generate status datapoints. Leave the Asset field empty to apply the filter to all assets.

  • Suffix: A string value that will be appended to the new status datapoint generated by the filter.

  • Check the Enable box to activate the filter once the configuration is complete.

Bounds

Bounds tab is used to define datapoints along with their bounds that are used to generate corresponding status datapoints. Multiple datapoints along with their bounds can be specified for filter to act on. See Bounds Data Format.

boundslist

  • Key : The datapoint name for which the filter will generate a status.

  • Lower Bound: A floating-point value for the lower bound. Defaults to the minimum representable double value if not provided.

  • Upper Bound: A floating-point value for the upper bound. Defaults to the maximum representable double value if not provided.

  • Warning Threshold: A floating-point value in percentage for the threshold. Defaults to 0.0 if not provided.

  • Click on Done to activate the filter.

Bounds Data Format

A list of key-value pairs where each key corresponds to a datapoint name and the value defines the bounds and threshold for that datapoint. Bounds data contains a JSON of numeric datapoints to which filter is applied. The specified datapoints should have numeric value in order to generated status datapoints.

The filter generates status datapoints based on the following conditions:

  • Good: The value is within the defined upper and lower bounds and not within the warning threshold of those bounds.

  • High: The value is within the warning threshold of the upper bound but not greater than the upper bound.

  • Too High: The value exceeds the defined upper bound.

  • Low: The value is within the warning threshold of the lower bound but not less than the lower bound.

  • Too Low: The value is below the defined lower bound.

Here is an example configuration for the bounds data:

{
    "temperature": {
        "lowerbound": "20.0",
        "upperbound": "80.0",
        "threshold": "10.0"
    },
    "pressure": {
        "lowerbound": "30.0",
        "upperbound": "100.0",
        "threshold": "5.0"
    }
}

In this example:

  • The temperature datapoint will have a lower bound of 20.0, an upper bound of 80.0, and a warning threshold of 10%.

  • The pressure datapoint will have a lower bound of 30.0, an upper bound of 100.0, and a warning threshold of 5%.

With above configuration status datapoints for an asset with following reading:

{    "pump1" : {
         "temperature": "57",
         "pressure": "101"
     }
 }

Transformed reading after passing through filter:

{    "pump1" : {
         "temperature": "57",
         "pressure": "101",
         "temperature::Status": "Good",
         "temprature::Status": "Too High"
     }
}

Floating-Point Precision Across Architectures

The foglamp-filter-bounds plugin handles floating-point precision for numeric datapoints using double-precision floating-point arithmetic, which typically supports precision up to 14-15 significant decimal digits.

  • 64-bit architectures (common in most modern systems) allow for high precision, ensuring up to 14 decimal places can be accurately represented in both the lower and upper bounds for each datapoint.

  • 32-bit architectures, though less common, may exhibit slightly reduced precision due to potential limitations in floating-point handling. In such cases, precision may be restricted to 6 decimal places, and users should be cautious when specifying bounds for high-precision datapoints on these platforms.

This difference in precision may lead to slight variations in status generation for extremely precise datapoints across different system architectures.