Cross-Signal Consistency Checks for Chillers and Pumps

Most monitoring checks each signal on its own: is this value inside its band, is it arriving, is it flagged. That misses an entire category of problem, which is signals that are each individually unremarkable and collectively inconsistent. A status point saying running while the associated power reading sits at zero is the simplest example, and nothing that examines either point in isolation will ever notice it.

The message up front: consistency checks compare related signals from the same plant and report when they disagree about what is happening. They are cheap, explainable and they catch instrumentation and mapping problems that threshold monitoring structurally cannot. They also require care in two respects: the relationships must be stated by somebody who knows the plant, and the output is a disagreement to investigate, never a conclusion about the equipment.

1. What a consistency check is

A consistency check takes two or more signals that describe the same physical situation and asserts a relationship between them that should hold whenever the data is correct. When it does not hold, something is wrong with at least one of the signals or with the situation, and the check does not know which.

The family divides usefully into three kinds.

• State agreement. Two signals that both report whether something is in a given state, for example a commanded state against a confirmed state, or a status against a current draw. These are the simplest and the highest-yield.
• Co-movement. Signals that should change together, or where one should respond when the other does. When one moves and the other does not, something has stopped tracking.
• Redundant measurement. The same quantity measured by two instruments or arriving by two paths, which should agree within the tolerance of the instruments.

What all three share is that they are explainable in one sentence to whoever receives the output, which is the property that makes them act on it. That explainability is also why they sit in the middle ground discussed in thresholds versus statistical methods.

2. What they actually catch

The pattern in that table is worth noticing: the most frequent causes are instrumentation, mapping and scaling problems rather than plant problems. That is the honest case for these checks. They are primarily a data quality instrument that occasionally surfaces something about the equipment, and framing them that way sets expectations correctly and keeps the output credible.

3. Building the check set

A workable process, and it is short.

• Sit with the engineer and list relationships that must hold for one equipment class, expressed as plain statements. An hour produces more than enough to start.
• Check which of them are computable from the points you actually collect. Several will not be, and that gap is itself a useful finding about instrumentation coverage.
• Have the engineer state the tolerance and the conditions under which each relationship applies, since most hold only in certain operating states and firing them during a shutdown produces noise.
• Require persistence before reporting. Momentary disagreement during a transition is normal; sustained disagreement is the signal. This removes most of the noise on its own.
• Test each check against history before enabling it. Running it over a past period shows how often it would have fired and usually reveals a condition clause that was missing.

4. What has to be true first

Consistency checks depend on knowing which signals belong together, and that is exactly the information most estates lack.

Comparing a status against a measurement requires confidence that both points describe the same physical unit, which is the verified mapping from point-to-asset mapping rather than an inference from names. Comparing values requires that units and scaling are known and consistent, from units and scaling. Comparing signals at the same moment requires that their timestamps are comparable, which is not automatic across controllers, per timestamps and clock sync. And a check comparing two points at an instant has to handle the case where one of them simply did not report, which is why completeness has to be visible to the check rather than hidden from it.

There is a silver lining here. The first run of a consistency check set is an extremely efficient way to find mapping and scaling errors, because a wrongly mapped point will disagree with its supposed companions immediately and obviously. Many teams get more value from that first pass than from the ongoing monitoring.

5. Writing the output so it is actionable and honest

How a disagreement is reported decides whether it gets acted on or dismissed.

• State the relationship that failed, in words. The signals involved, what each was reporting, and what was expected to hold. A responder who can see the reasoning will engage with it.
• Say which signal might be wrong, and that you do not know. A disagreement implicates all the signals involved, and phrasing it as a fault in one of them is an unsupported claim that will eventually be wrong.
• Include the duration. Sustained for a shift and sustained for a minute are different situations.
• Include completeness for the window, so an apparent disagreement caused by one signal not reporting is immediately visible.
• Route by likely cause, with triage for the ambiguous. Most of these should go to instrumentation or integration first rather than to a mechanical trade, which is the routing argument in alarm ownership.

6. Where the method runs out

Three honest limitations, worth stating before anybody over-invests.

A consistency check cannot tell you which signal is correct. It reports that two accounts of the same situation differ, and resolving that needs either a third source or somebody at the plant. In practice this is fine, because knowing that something is inconsistent is already far more than you had, but it means these checks generate investigations rather than conclusions.

They only cover relationships somebody thought to state, so coverage is bounded by the conversation that produced the check set. They will not find anything nobody anticipated, which is precisely the gap that statistical approaches are reached for.

And they decay. A check written against one plant configuration will start firing when the plant is modified, the control strategy is retuned, or a point is remapped, and a check that fires constantly gets disabled rather than corrected. They need the same change discipline and the same review cadence as anything else in monitoring drift, and an owner who revisits them when the plant changes.

The idea to walk away with

Checking signals against each other catches a class of problem that per-signal monitoring structurally cannot: readings that are individually unremarkable and collectively contradictory.

Get the relationships from the engineer rather than from the data, require persistence and state the operating conditions, test each check against history first, report the disagreement with its reasoning and without implicating one signal, route most of them to instrumentation or integration, and review them whenever the plant changes.

Final thoughts

Start with one check on one equipment class: the simplest state agreement you can express, run over the last year of history.

Count how often it would have fired and look at a handful of those occasions. If they are all transitions, you need a persistence clause. If some are sustained and unexplained, you have found something worth a conversation with the engineer, and you have done it with a rule that fits in a sentence and that nobody will have to take on trust.

Related reading: AHU telemetry quality checklist, Thresholds versus statistical methods, Communication versus equipment anomalies, Units and scaling, Duplicate sensor readings, Chiller plant analytics.