Overview

Aggregations monitor tag data logged by the Data Acquisition Engine and apply user-defined rules to that data. When the conditions outlined in the rules are met, the aggregation service writes that tag data to a separate database. The tag data can have some modifications and math operations applied to it if desired, and that logged data can be displayed through Dashboards or used by external systems through Webhooks or Events.

Every aggregation data row written by the Aggregation Engine contains the values of every tag configured in that rule, whether that particular tag rule evaluated to true or not.

It’s important to keep in mind that Prophecy may not be the best place to aggregate data. There are multiple ways it can be done, ranging from the far back-end at the device level all the way to front-end in a Dashboard. Here are some considerations for each:

  • PLC / Device Level: This is best for condensing huge amounts of sensor switching, and to eliminate switch bounces, etc. A good rule of thumb for part counts is: if the part logging is less than 10 seconds per part, then aggregating this at the device level would be good.

  • Data Acquisition Engine: When needed, the Data Acquisition Engine can be used to log on tag value change, for example. This should be kept to a minimum unless really needed. Whenever possible, using the aggregation functionality described here should be used, as it's more easily configured. If you feel that aggregations won't work for the data you want to log, speak with the Prophecy Consulting Group for help with configuring the Data Acquisition Engine directly.

  • Prophecy: The Aggregation Service described here

  • Dashboards: Dashboards can be connected directly to logged tag data and perform small calculations, combinations, etc, but it is not suitable for aggregating or displaying large amounts of data on the fly.

Definitions

When creating and configuring rules, these terms will be important:

  • Aggregation Data: When the Aggregation Engine fires, it writes a row to a database separate from the main Prophecy IoT database and the logging table. These rows are the aggregation data, which can be used externally through events and webhooks or displayed graphically through Dashboards.
  • Aggregation Engine: The Aggregation Engine is a background process that runs alongside of the Prophecy IoT application. It runs the aggregations that have been configured on a schedule (generally every 30 seconds) and outputs aggregation rows to the aggregation database.
  • Aggregation Rule: 'Aggregation' for short. This is the set of condition groups (see below) that are evaluated every time the aggregation runs.
  • Fire: Whenever the Aggregation Engine processes a row of logged data that matches the aggregation rule, the aggregation is said to 'fire'. Aggregation data will be written, an event may fire, and a webhook may be called.
  • Logging Table: The Data Acquisition Engine logs tag data to a table that is not generally accessible directly. This is the source of the data that the Aggregation Engine evaluates each time it runs a rule.
  • Run: Each time the Aggregation Engine processes an aggregation, it's called a run. A run may contain multiple firings. Runs generally happen every 30 seconds.
  • Set: A set is all the logged data between the last time the rule fired and the next time it does. A run might contain multiple sets (meaning the rule conditions were met multiple times over that period) or a set might stretch across multiple runs (meaning the rule was evaluated several times before the conditions were met for it to fire).
  • Tag Data: Also referred to as 'logged data'. This is the data from tags that the Data Acquisition Engine writes to the logging table.

Rule Evaluation

Every aggregation rule is made up of one or more 'Condition Groups', each of which contains one or more 'Tag Rules'. When the rule runs, the Aggregation Engine retrieves all of the logged data from the logging table since the last time the aggregation ran. Each row is compared to the aggregation rule, and if the Aggregation Engine decides that it meets all the critera, an aggregation data row is written and (if the aggregation rule is configured to do so) an event fires and a webhook is called.

IMPORTANT - Aggregations fire when the logged data switches from not meeting the rule requirements to meeting them, ie from false to true. This prevents the aggregation engine from writing tons of lines of data when nothing significant has changed. When logged data becomes true, a row is written, and another won't be until the logged data has become false and switches to true again:

  • Rule evaluates to false (nothing happens)
  • Rule evaluates to false (nothing happens)
  • Rule evaluates to true (aggregation row is written)
  • Rule evaluates to false (nothing happens)
  • Rule evaluates to false (nothing happens)
  • Rule evaluates to false (nothing happens)
  • Rule evaluates to true (aggregation row is written)
  • Rule evaluates to false (nothing happens)
  • Rule evaluates to true (aggregation row is written)
  • Rule evaluates to false (nothing happens)
  • etc...

The aggregation data row that is written contains the values of every tag that makes up the aggregation rule, whether that particular tag's condition was met or not. The values written may be transformed before being written to the database.

When deciding how to set up your rule, remember:

  • Condition Groups are "OR'd" together, which means that if any condition group in the entire rule evaluates to true, the rule will fire.
  • Tag rules within condition groups are "AND'd" together, which means that all tag rules within the condition group have to be true for that group to evaluate to true.