{{ }}) and the thresholds with your own, and click Validate before you save to see what the rule would have flagged over the last 90 days.
Data rules are introduced in Data Rules Fundamentals, and the operators and windows these conditions use are in Rule Expressions.
Data rules by the failure they catch
Values that cannot be right
Values that are wrong for their context
Two measurements that should agree and do not
Instruments and feeds that stopped measuring
Alert or correct a value
Every data rule does one of two things when its condition matches, and it is worth deciding which you want before you pick a rule.
Every substitute rule below also works as an alert: keep the condition and pick Alert.
An alert rule also chooses which data points to flag when it fires. Automatic flags every data point the condition names, and Specific data points lets you pick. Where a condition names a value and the status that gates it, picking the value keeps the alert on the thing that went wrong.
Hold for approval sits on top of a substitute rule. With it on, each match becomes a proposal for a person to decide before anything is written to the data. See Approve corrections.
What a data rule can see
Three things decide whether a rule you write will work on your data.- One event at a time. A rule reads the data points captured together on one event, the same row on the Events table, so two data points named in one condition have to arrive together. A rule naming data point types from two different event types is rejected when you save.
- History, when you ask for it. A condition carrying a
WITHINwindow reads earlier data points of the same type, which is what the stuck meter, spike, baseline and coverage rules below are built on. - Data arriving is what runs a rule. Rules are evaluated when data is captured, imported, or corrected, and they read the data you hold. A rule set to run only on demand runs when you evaluate a period instead. A feed that has stopped sending anything shows up in the Capture Rate view straight away, and a rule on its coverage reports once the feed delivers again.
Values that cannot be right
A value outside what the measurement can physically be
A meter counter that rolled over, a unit conversion applied twice, or a spreadsheet cell left blank all arrive as a value the measurement can never take. A biochar mass at or below zero is the plain case. Match the bound to the measurement before you use this one: a flow meter reads zero overnight while the equipment is idle, so a rule on a meter tests< 0 and leaves zero alone.
Adapt it to your measurement
Adapt it to your measurement
A percentage, such as feedstock moisture or methane content, takes
not between 0 and 100. A lab result takes not between with the range your lab can actually report, which is narrower than the range the units allow.This is the cheapest rule on the page to run and the one that catches the most obvious corruption, so it is worth having on every measurement that has a hard bound, not only the ones you suspect.A batch calculation result outside its physical bounds
A model output can go wrong while every input passes its own checks. A net removal figure at or below zero means an input is overstated somewhere upstream. So does a volume worked out by subtraction coming out negative, where the other sources have been taken off a total that was too small to start with. The outputs a model produces are its nodes, which is why the variable below reads{{node.<name>}} rather than naming a data point.
Adapt it to your model
Adapt it to your model
Pick the model on the When step, then type
{{ in the condition to choose the output from the list. A volume worked out by subtraction takes the same rule with < 0.The alert lands on the batch, so pair this rule with a Data Points rule on the inputs that can overstate, such as the physical-bounds check above, and an alert on the data point then points at the cause.Values that are wrong for their context
A process limit that only applies while equipment is running
A pyrolysis reactor spends part of every cycle heating up and cooling down, so a rule that tests the temperature alone raises a false alert on every start and stop. Adding the reactor’s status to the condition limits the rule to the time production is actually running. Both data points have to be captured on the same event.Adapt it to your process
Adapt it to your process
Replace
500 with the floor your process runs at, in the unit the temperature is captured in, and write the status value exactly as it appears in your data: the comparison is exact, so 'Running' does not match 'running'. A controller that reports status as a number takes = 1 in place of = 'running'.Flag the temperature only. With Automatic the status is flagged as well, and whoever triages the alert is sent to a value that did nothing wrong.The same shape suits any limit that only matters under load: a flare temperature, a kiln pressure, an engine’s exhaust temperature.A product meter reporting while the plant is off
On a biogas or renewable natural gas (RNG) upgrading plant, the product meter can report a small flow while the inlet meter shows the plant is not running. The rule reads the inlet as the gate and the product meter as the value to correct, so both have to be captured on the same event.Adapt it to your plant
Adapt it to your plant
Replace
25 with the inlet flow below which the plant is not producing, in the unit the meter is captured in. Keep Hold for approval on while you are confirming the threshold, so each match becomes a proposal to check against the plant log before anything is written. See Approve corrections.The != 0 clause stops the rule matching the zero it wrote, and leaves a product meter that already reads zero alone.The same shape suits any pair where one measurement says the other should be zero: a charger’s output against its session status, a pump’s flow against its run signal.A value that jumped away from its recent history
A value can sit inside its physical bounds and still be wrong for the hour it arrived in. A feedstock mass that swings by a third between one data point and the next, with nothing on the plant to explain it, is the case this catches. The condition compares the value against the average of its own recent history.Adapt it to your equipment
Adapt it to your equipment
RATIO divides the first value by the second, so the band is written as multiples rather than as a difference: NOT BETWEEN 0.67 AND 1.5 fires on a value less than two thirds or more than one and a half times its recent average. Widen the band on a measurement that moves fast, and tighten it on one that should barely move.Size the window against the interval the meter reports at. Six hours on a 15 minute meter holds two dozen values. A window holding only a handful is pulled upward by the very value you are testing, which makes an extreme value look closer to normal than it is.The value being tested counts in its own trailing window, so the first value on a new measurement is compared against itself, the ratio comes out at 1, and the rule does not fire.A result far from its own baseline
A batch result, a lab assay, or a daily average can be well inside its physical bounds and still be unlike anything the site has produced before.ZSCORE measures how far the value sits from the average of its window, counted in standard deviations, so it catches an outlier the bounds checks let through.
Adapt it to your baseline
Adapt it to your baseline
> 3 catches results above the baseline only. To catch both directions, write NOT BETWEEN -3 AND 3. Three standard deviations flags fewer values than two.The COUNT holds the rule until the window has twenty data points behind it. Keep it above ten for a threshold of 3: the tested value counts in its own window, so a window of ten or fewer cannot produce a z-score that high. ZSCORE also returns nothing when the window holds fewer than two data points or they are all identical, and the comparison is then false.To ask a different question, whether a result is more than three times the trailing average rather than three standard deviations from it, use RATIO. The two thresholds are not equivalent, and on a steady measurement the multiple is much the looser of them:Two measurements that should agree and do not
Two meters that should agree drifting apart
Two instruments measuring the same quantity should track each other: an inlet flow against an outlet flow, a mass measured on the truck against the same mass measured at the weighbridge. When they drift apart, one of them is wrong, and neither is outside its own bounds. Both meters have to be captured on the same event, both have to be numeric, and both have to be in the same unit, because the comparison reads the raw values with no conversion.Adapt it to your instruments
Adapt it to your instruments
The band is the tolerance you accept, as multiples:
0.95 to 1.05 allows five per cent either way. It covers the real process difference between the two measuring points as well as the instrument error.RATIO returns nothing when either side has no value, or when the second is zero, so this rule does not fire on a gap.Flag both data points with Automatic, so whoever triages the alert sees the pair.More product out than feedstock in
A mass balance is the check that needs no threshold at all: more biochar out than feedstock in is impossible, whatever the yield. A condition can compare two data points directly, with no number in it, as long as both are captured on the same event and in the same unit. The comparison reads the raw values, so a biochar mass in kilograms against a feedstock mass in tonnes fires on nearly every event.Adapt it to your process
Adapt it to your process
When one of the two data points is absent from an event, the condition has nothing to compare and the rule does not fire, so a pair that is only sometimes captured together is a rule that only sometimes runs.To allow for a yield you already know, use The same shape suits any pair the physics constrains: water out against water in, energy delivered against energy metered.
RATIO with the highest yield your process can reach. This one fires when the output is more than 35 per cent of the input:Instruments and feeds that stopped measuring
A meter stuck on one value
A flow meter or sensor that has frozen keeps reporting on schedule, so nothing about any single value looks wrong. The rule tests that the lowest and highest values over the last hour are the same, with a count beside it saying how many identical values it takes to call the meter stuck.Adapt it to your meter
Adapt it to your meter
Size the window and the count against the meter’s interval. A meter reporting every 15 minutes puts four values in an hour, so
COUNT >= 3 is met as soon as the hour is flat. A meter reporting once a minute wants a shorter window or a higher count, so a few quiet minutes do not trip it.The COUNT is required, and it has to be held to at least two values. A condition without one is rejected when you save, because MIN = MAX is true of a single value and the rule would otherwise fire on the first value after every gap.The last clause leaves out a flatline of zeros, which is what idle equipment produces. Drop it on a measurement that never legitimately reads zero.Catching a stuck sensor explains the condition and what Flag the whole run does, and Repair a stuck sensor writes the same rule as a substitution over the API.An analyzer value that dropped out
A gas analyzer that loses its connection records an empty value, or a zero, for a stretch of data points while the rest of the event is fine. The rule replaces each one with the last value the analyzer measured, and with the day’s average when there is no earlier value to carry forward.IS MISSING matches a data point that arrived without a value. A slot the analyzer never submitted at all has no data point for the rule to read, so a stretch where the feed sent nothing is a capture rate question rather than this rule.
Unless Data point to use names another data point type, the fill methods only draw on values carrying the same tracking ID as the data point being corrected, the identifier that ties a series of data points to one piece of equipment or one delivery. A rule that alerts where you expected a correction is the cue to check the tracking IDs on the events it reads.
Adapt it to your analyzer
Adapt it to your analyzer
Forward fill takes the most recent earlier value that this rule does not match, and only a measured one, so a run of dropouts fills from the last real measurement rather than from a value already corrected. When neither method finds a value, the data point is left as it is and an alert is raised.With Hold for approval on, each replacement stays a proposal until a person decides it. See Create a Data Rule for the method list and what each one draws on.
A month that came in under its expected coverage
DATA_CAPTURE_RATE reads the share of the data you expected that actually arrived, so a rule can flag a month that came in short. Every other rule on this page reads values you hold. This one reads how many of them turned up against the cadence you declared, which is how missing data becomes something a rule can act on.
The rule reports on a period once data arrives for it. To watch a feed that is quiet right now, and to see which slots are missing rather than how many, use the Capture Rate view.
Adapt it to your cadence
Adapt it to your cadence
Data capture rate is switched on per account. Ask your Mangrove account team if the Cadence field is not in your project.The rate is a fraction rather than a percentage, so compare against The rule is evaluated against the data points that did arrive, so with Automatic the alert lands on one of those rather than on an empty slot.The window is required and only two resolve,
0.9, not 90. To set the limit as time rather than a share, read the same gap with TIME_NOT_CAPTURED and compare it with a duration, on a cadence counted in seconds, minutes, hours, days or weeks:CALENDAR MONTH and CALENDAR YEAR. A year reads the year to date. The data point’s event type also has to declare a Cadence, since the cadence is what says how much data to expect; see Data capture rate for setting one. A rule that names a data point with no cadence behind it will not save.Capture rate reads a fact about the data point type rather than a value, so it belongs on an alert rule. A substitute rule can read it only when the rule runs on demand, and only for a data point other than the one it corrects.