Plenty of process questions only make sense over the periods when equipment was actually doing something. The average discharge pressure of a compressor across a whole day is misleading if the machine was down for half of it, and the number that matters is the average while it was running. A filtered summary query answers exactly that kind of question by computing an aggregate over only the slices of time when a stated condition was true, rather than over the full range. This page explains how a historian gates one tag's summary on another tag's state, what results a filtered query produces, and why this conditional style of aggregation is different from a plain average or sum.
Filtered summary query in one line: A filtered summary query computes an aggregate, such as an average, sum, or count, over only the portions of a time range where a filter condition was true, instead of over the entire range. For example, it can return the average discharge pressure only during the intervals when a run-status tag showed the compressor running, or the total hours a tank level stayed above a setpoint. The historian evaluates the filter tag or expression to find the qualifying time windows and then aggregates the target tag across just those windows.
The core mechanic of a filtered summary is a two-part request: a target tag to summarize, and a filter condition that decides which moments count. The condition is usually an expression over one or more other tags, such as a run-status equal to on, a valve position above a threshold, or a mode tag in a particular state. The historian walks the filter across the requested time range, identifies the contiguous stretches where the condition held, and treats only those stretches as the domain over which the target tag is aggregated. Everything outside those stretches is excluded as if it did not exist for the purpose of the calculation.
Because process conditions turn on and off over time, the qualifying domain is generally a set of intervals rather than one continuous block. The compressor might have run three separate times during the day, so the filtered average is computed across the union of those three run periods, weighted appropriately by how long each lasted. Handling the boundaries correctly matters: when the filter flips from false to true partway between two samples, the historian has to decide the exact instant the qualifying window opens, which is where interpolation rules and the sampling behavior of the filter tag come into play. Good implementations let you specify how the boundary is treated so that a slow-changing filter tag does not smear the edges of the window.
This gating is what separates a filtered summary from post-processing raw data in a spreadsheet. Rather than exporting everything and then discarding rows, the historian does the selection and the aggregation together, in one pass over the archive, which is far faster and avoids moving large amounts of raw data. It also keeps the logic in one place, so the same filtered question can be asked repeatedly, on a dashboard or in a report, without re-implementing the condition each time.
The most familiar filtered aggregate is a conditional average, such as average temperature while a heater was on, which strips out the idle periods that would otherwise pull the number toward ambient. Filtered sums and totals matter for flow and energy, where you might want the total volume moved only while a pump was commanded to run, so that meter drift or small leakage readings during downtime do not accumulate into the total. Filtered minimum and maximum answer questions like the highest bearing temperature reached while the machine was under load, which is more meaningful than the all-time maximum that might have occurred during a test.
A particularly useful family is time-in-state, which counts how long the filter condition itself was true rather than summarizing another tag. This directly produces runtime hours, the total time a tank level was above a high mark, or the number of hours a unit spent in a given mode. Here the target of the aggregate is essentially the duration of the qualifying windows, and the result is a count of time. These figures feed straight into maintenance planning, utilization reporting, and environmental accounting, where the question is almost always how long, not what value.
Closely related is the count of transitions or events, which tallies how many times the condition became true. That answers how many times a pump started, how often a level crossed a threshold, or how frequently a compressor cycled, all of which are leading indicators of wear. Because these counts and durations come from the same filtered-evaluation machinery, a historian that supports filtered summaries can usually deliver both the value-based aggregates and the time-and-count aggregates from the same query family, which keeps analysis consistent.
For field operations, filtered summaries turn raw archive data into the numbers people actually manage by. Utilization, runtime between services, and time spent off-spec are all conditional by nature, and computing them by hand from trends is error-prone. A dashboard that shows average pressure only while running, or hours above a limit this month, gives operators and supervisors a figure they can act on without mentally subtracting the downtime. Because the filter is explicit, everyone can see the exact condition that defined the number, which makes the metric defensible when it drives a decision.
In a remote or cloud monitoring setup, filtered summaries are especially valuable because they push the conditional logic down to where the data lives. Instead of streaming a month of raw samples to a central system and filtering there, the historian evaluates the condition locally and returns only the small summarized result, which is cheap to transfer and fast to render across a fleet of sites. A central team watching many similar assets can ask the same filtered question of each site and compare, for instance, average load-side temperature while running, on equal footing.
The main caution is that a filtered summary is only as good as the filter and the data behind it. If the filter tag has gaps, bad quality, or coarse sampling, the qualifying windows can be defined imprecisely, and the aggregate inherits that uncertainty. It is worth confirming that the status or condition tag driving the filter is collected finely enough to catch the transitions that matter, and that its quality flags are respected, so that a stretch of missing status data does not silently get counted as running or not running when it should have been excluded.
A plain average includes every moment in the time range, so periods when the equipment was idle or down still count and can distort the result. A filtered summary first restricts the calculation to only the times a stated condition was true, then averages over just those periods. The difference is often large, for example an all-day average pressure versus the average pressure only while the unit was actually running.
Yes, and that is the usual case. The filter is typically an expression over one or more status or condition tags, such as a run-status or a valve position, while the target of the aggregate is a separate process tag. The historian uses the filter tag to decide which time windows qualify, then aggregates the target tag across only those windows.
For runtime hours the filter condition is the running state itself, and the aggregate measures the duration of the qualifying windows rather than another tag's value. The historian finds every interval where the run condition was true, adds up their lengths, and returns the total time. The same mechanism can count how many separate run periods occurred, which gives start counts alongside the hours.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.