Measure Limits and Thresholds
Defining what good looks like — constant, measure-driven, and offset thresholds, and how they reach charts.
A limit records what a measure's value ought to be. Once a measure has one, Infohub can colour it on a chart, flag it in a table, and raise a notification when it goes out of range — and a reader no longer has to remember what good looks like.
Limits are the mechanism that turns numbers into information. A dashboard where every value is judged against a limit can be read at a glance; one without limits requires the reader to know the plant.
The shape of a limit#
Limits are defined in the Toolbox and attached to measures. A limit attached to a measure carries ranges — typically a high, a target, and a low — per time scheme.
The limit type determines which direction constitutes a breach:
| Type | Breach when |
|---|---|
| High | The value goes above the threshold |
| Low | The value goes below the threshold |
| Either | The value leaves the band in either direction |
Choose by what the measure means. Downtime and energy consumption are High limits — more is worse. Production and availability are Low limits — less is worse. A temperature or pH that must stay within a band is Either.
Where the threshold value comes from#
This is the part worth knowing properly, because it is more capable than most people use.
| Value type | The threshold is |
|---|---|
| Constant | A fixed number you type |
| Measure | Another measure's value |
| Offset | A relative amount |
Constant is the obvious case: a temperature must stay below 105 °C.
Measure is the powerful one. The threshold is another measure, which means it can vary by period without anyone maintaining it. Concretely:
- A production target entered monthly by planning becomes the limit on actual production — so the limit moves when planning changes it, with no limit editing at all.
- A design capacity held as a measure becomes the ceiling on throughput.
- Last year's value for the same period becomes the comparison a measure is judged against.
- A calculated value — 95% of nameplate, say — becomes a limit that tracks nameplate automatically.
This is how a plant with monthly targets keeps its dashboards honest. The alternative, editing constant limits every month, is work that will eventually be skipped and then dashboards are judging against a stale target.
Offset expresses a threshold relative to something rather than absolutely — a tolerance band around a target, for instance.
Drive limits from a target measure, not from constants. If a target changes with any regularity — monthly, seasonally, per product — hold it as a manual entry measure and point the limit at it. You then get a target that is versioned by period, entered by the people who own it, visible on charts, and reportable in its own right. A constant limit gives you none of that.
A threshold is effective from a date, not simply edited#
A limit attached to a measure does not hold one pair of numbers that you overwrite. It holds a series of instances, each carrying its own low and high and the date it takes effect from. Infohub resolves which instance applies when it evaluates a period, so a period from last March is still judged against the threshold that applied in March.
That has a practical consequence worth planning around: raising a limit does not silently re-colour history. Old periods keep being judged against the threshold that was in force, which is what you want for an audit trail and is occasionally surprising if you expected a dashboard to go green retrospectively.
A limit also carries a backfill point. Setting it is how you deliberately ask Infohub to re-evaluate past periods against the limit — see Backfilling and Recalculation.
Different thresholds per product, grade or state#
The single most under-used capability here: an instance can be switched to use attribute limits, and its thresholds then come from a table keyed by enumeration value or event attribute segment rather than from one low/high pair.
That is what you want whenever "good" depends on what the plant is making:
- A moisture specification that differs per product grade, keyed to the grade enumeration.
- A cycle-time ceiling that differs per recipe.
- A temperature band that differs per operating state, so warm-up is not flagged as a breach.
Without this, the usual workaround is a separate measure per product with its own limit, which multiplies the model and drifts out of step. With it, one measure carries one limit whose thresholds follow the running product.
The keys come from the same enumerations used by event attributes, so the grade list is defined once and used by both.
Scope: where a limit applies#
A limit on a measure is scoped by more than the measure:
| Scope | Effect |
|---|---|
| Time scheme | The limit applies to that calendar's periods — so a daily and a monthly limit can differ |
| Event scheme | The limit applies within event periods, letting a limit apply per batch or per run |
| Comparator | Which comparison constitutes a breach — >, >=, =, <=, < |
| Active | A limit can be switched off without being deleted, which keeps its history intact |
Limits can derive from other limits#
A limit can name another limit as its source, and Infohub resolves that chain back to the root when it reads threshold values. This is what keeps a templated limit in step: the instance's limit points at the template's limit, so a threshold changed once on the template reaches every instance rather than being copied into each.
It also means a threshold that "will not change" on one derived measure is usually inherited — change it at the source, or break the link deliberately. See Templates: Instantiating and Updating.
Limits vary by time scheme#
Limit ranges are held per time scheme, which means the same measure can be judged differently on different calendars — a weekday target and a weekend one, or a different band on the financial calendar.
Most models use one set. Where you need more, this is the mechanism rather than duplicating measures.
Getting a limit onto a chart#
There is one rule that shapes the workflow.
A limit slot only accepts a limit belonging to the measure on its parent chart item. So the chart must already carry that measure as a series before its limit can be bound.
The order is therefore always:
- Add the measure to the chart.
- Bind its limit.
Attempting the reverse has nowhere to attach. This trips up scripted chart building in particular, where it is tempting to configure everything about a chart in one pass. See How Infohub Charts Work.
What limits give you#
Colour. Widgets, table cells, and chart series take their status colour from where the value sits relative to its limits. This is the single highest-value use, and it is why a limit-less dashboard is so much harder to read. See Colour as Information.
Reference lines on trends. A trend chart with its limit drawn shows not just the shape but whether the shape is acceptable.
Notifications. The Measure Limit Exceeded message trigger fires on a breach, which is how alerting gets built. See Building an Alarm Strategy.
Exception reporting. A Limit Based Form shows values against their limits, which is the natural shape for a review of what breached and what was done about it.
Setting thresholds that work#
The technical part is easy. Choosing the numbers is where limits succeed or fail.
Set them where you would actually act. A limit is a statement that something needs attention. If a breach does not prompt anyone to do anything, the limit is at the wrong value or should not exist.
Do not set them at the specification boundary alone. A limit at the point where product is already out of specification tells you too late. A warning band before it gives someone a chance to intervene.
Use the plant's real operating experience. Chart the measure over a few months and look at where it normally runs. A limit set from a design document rather than from behaviour will either never fire or fire constantly.
Review them. A plant improves, and limits set at commissioning become meaningless. A limit that has not fired in two years is not evidence of excellence; it is usually evidence of a threshold nobody revisited.
A limit that fires constantly is worse than no limit. The fastest way to make a dashboard useless is a limit set so tight that everything is always red. Readers learn within a week that red means nothing, and the genuine exception is then invisible. If a limit fires most of the time, either the threshold is wrong or the process is not capable of meeting it — and the second is a different conversation from a limit configuration.
Manual entry measures deserve limits#
An easily-missed use. A limit on a manually entered measure flags an implausible entry at the moment it is typed, which catches the misplaced decimal point before it propagates into a monthly report.
This is the cheapest validation available in Infohub, and it costs one limit definition per manual measure.
Diagnosing#
| Symptom | Cause |
|---|---|
| Limit will not bind to a chart | The chart does not carry that measure as a series yet |
| Widget colour never changes | No limit bound, or a fixed colour was set on the widget |
| Colour is wrong | Threshold values, or limit type (High where Low was meant) |
| Limit never fires | Threshold far outside the operating range |
| Limit always fires | Threshold inside the normal operating range |
| Target does not track planning changes | Constant limit where a Measure-valued limit was needed |
| Limit correct on one calendar, wrong on another | Ranges are per time scheme; check the one in use |
| Notification not raised on a breach | Message definition and trigger, not the limit — see the Message Engine |
| Editing a threshold did not re-colour history | By design — instances are effective from a date; set the limit's backfill point to re-evaluate |
| Threshold reverts after a template update | The limit derives from a source limit; change it at the source |
| One product is always in breach | The instance needs use attribute limits, with a threshold per enumeration value |
| Limit ignored inside batches | It is scoped to a time scheme; an event-scheme-scoped limit is needed |