A totalizer that accumulates flow into a running total is doing numerical integration, and the accuracy of that total depends entirely on which method the PLC uses to add up each scan. The two common choices are the rectangular rule and the trapezoidal rule, and they can disagree by a meaningful amount whenever the flow rate is changing. This guide goes one level below the totalizer concept and looks at the actual arithmetic: how each method estimates the area under the rate curve during a scan, when the trapezoidal rule is worth the extra step, and how a variable scan time quietly erodes the answer.
Trapezoidal integration in one line: Trapezoidal integration is a numerical method a PLC uses to accumulate a signal, such as flow, into a running total by estimating the area under the rate curve each scan as a trapezoid rather than a rectangle. Where the rectangular rule multiplies a single rate sample by the elapsed time, the trapezoidal rule uses the average of the current and previous rate samples multiplied by the elapsed time, which cancels most of the error when the rate is ramping up or down between scans.
Integrating a flow rate into a total means summing, scan after scan, the small amount that flowed during each scan. That amount is the area under the rate-versus-time curve for that slice of time, and both methods are just different ways of estimating that area from the rate samples the PLC happens to have. The rectangular rule, sometimes called the Euler or left-hand rule, takes one rate sample and multiplies it by the elapsed time, treating the rate as flat across the whole scan. Geometrically it draws a rectangle whose height is that single sample and whose width is the time step, and it adds that rectangle's area to the total.
The trapezoidal rule keeps two rate samples in play: the rate measured this scan and the rate measured the previous scan. It averages the two, multiplies that average by the elapsed time, and adds the result. Geometrically it draws a trapezoid whose two parallel sides are the old and new rates and whose width is the time step, which follows a straight-line change in rate exactly instead of stepping. The only extra cost over the rectangular rule is holding the previous sample and doing one addition and one division by two, which is trivial for a controller.
When the rate is steady, both methods give the same answer, because the average of two equal samples is just that value. The difference appears only while the rate is changing. If flow is ramping upward, the rectangular rule using the older sample undershoots every scan and the total runs low; using the newer sample it overshoots and the total runs high. The trapezoid sits exactly on the straight line between the two samples, so on a linear ramp it is right rather than merely close.
The trapezoidal rule earns its keep on signals that ramp between scans, which is most real flow during transients: a well being brought online, a pump changing speed, a valve stroking open, a batch starting or ending. Across each of those changes the rate is sloping, and the rectangular rule accumulates a one-sided error every scan that all points the same direction and therefore piles up rather than cancelling. Over a ramp of many scans that bias can add up to a visible discrepancy in the total, which matters when the total is a measured quantity people are paid or billed on.
The size of the improvement scales with how much the rate changes in a single scan and how many such scans occur. If the scan time is short compared with how fast the rate moves, each rectangle is nearly right and the two methods barely differ, so a fast totalizer on a slow-changing process gains little. When the scan is longer or the rate swings quickly, the per-scan error grows and the trapezoid's advantage becomes real. This is why the trapezoidal rule is the common default in flow computers and totalizer blocks: it costs almost nothing and removes the systematic ramp error that the rectangular rule leaves behind.
It is worth being clear about what the trapezoidal rule does not fix. It assumes the rate changes in a straight line between the two samples, so if the true rate curves sharply within one scan, the trapezoid still misses the curvature, just by far less than a rectangle would. It also cannot recover information the samples never captured: a spike that rises and falls entirely between two scans is invisible to both methods. The trapezoid is a better straight-line approximation, not a cure for undersampling, so a rate that moves faster than the scan can follow still needs a faster scan, not just a better rule.
Both rules multiply a rate by an elapsed time, and the accuracy of the total is only as good as that elapsed time. A PLC scan is not perfectly periodic: the scan time varies with logic load, communications, and interrupts, so assuming a fixed nominal scan and multiplying by that constant introduces error whenever the real scan runs long or short. The robust practice is to measure the actual elapsed time each execution from a free-running clock or a timestamp difference and multiply by that measured value, so the total tracks real time rather than an assumed cadence. This is the same delta-time discipline that underlies any rate or integral calculation.
Scan jitter interacts with the choice of method in a subtle way. Because the trapezoidal rule already handles a changing rate correctly, its remaining error is dominated by how faithfully the elapsed time is captured, which makes measuring the true dt the higher-value improvement once the trapezoid is in place. A totalizer that carefully averages two rates but then multiplies by a wrong, assumed scan time has simply swapped one error source for another. Getting both right, the average rate and the real elapsed time, is what makes an accumulated total trustworthy over a long run.
In a cloud SCADA architecture such as Merobix, the primary integration almost always belongs at the edge, in the PLC, RTU, or flow computer that sees every scan, because that is the only place with access to the full-rate signal at full cadence. The platform then transports the accumulated totals along with their timestamps and quality, so an operator sees a total that was integrated correctly at the source rather than reconstructed from sparse samples after the fact. Where the platform does compute or check a total from historized rate points, the same rules apply, and it should use the actual time between stored samples rather than a nominal interval. Keeping the raw rate and the running total both visible lets an analyst confirm the totalizer is behaving and spot the ramp-error signature if a rectangular method is quietly running low during transients.
The rectangular rule multiplies a single rate sample by the elapsed time, treating the rate as constant across the scan, which biases the total when the rate is ramping. The trapezoidal rule averages the current and previous rate samples before multiplying by the elapsed time, so it follows a straight-line change exactly and cancels most of that ramp error. When the rate is steady the two methods give the same result; they differ only while the rate is changing.
It matters most when the flow rate changes significantly within a scan and does so repeatedly, such as during startups, pump speed changes, or batch transitions, because the rectangular rule accumulates a one-sided error across every ramping scan that piles up rather than cancels. On a slowly changing process sampled quickly, both methods are almost identical. The trapezoidal rule costs almost nothing to add, so it is the common default in flow computers and totalizer blocks.
No. It only assumes the rate changes in a straight line between two samples, so sharp curvature within a scan and spikes that rise and fall entirely between scans are still missed, just by less than the rectangular rule would miss them. It also depends on multiplying by the true elapsed time; a good rate average multiplied by a wrong assumed scan time is still wrong. Faster sampling, not just a better rule, is the fix when the rate moves faster than the scan can follow.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.