A raw sensor count has to be converted into a meaningful engineering value somewhere, and that conversion is supposed to happen exactly once. A double-scaled tag is what you get when it happens twice: a value already turned into engineering units in the controller is scaled a second time in the SCADA, or the other way around, so the conversion is applied on top of itself. The result is a badly wrong number that, frustratingly, sometimes still looks believable. This guide explains why double scaling happens, how to detect it, and the governance rule that prevents it by giving the conversion a single, unambiguous home.
Double-Scaled Tag in one line: A double-scaled tag is one whose raw-to-engineering-unit conversion has been applied twice, typically because the PLC already converted the value to engineering units and the SCADA then scaled it again as if it were still a raw count, or vice versa. Applying the conversion on top of itself produces a value that is wrong by roughly the scaling factor, which can be an obvious order-of-magnitude error or, in unlucky cases, a number that still looks plausible.
To understand double scaling, start from the normal path. A sensor produces a raw signal, a count from an analog-to-digital converter or a current on a loop, and that raw value has no physical meaning until it is mapped onto an engineering range. That mapping, applying a span and offset so that the bottom of the raw range becomes the bottom of the engineering range and the top becomes the top, is the scaling. Done once, it turns a count into a pressure, a level, or a flow. The core rule is that this conversion should be performed exactly one time, at one place in the chain from sensor to display.
Double scaling happens when two places in that chain both think they are responsible for the conversion. A common pattern is that the PLC or RTU is configured to convert the raw signal into engineering units and then present the already-converted value to the SCADA, but the SCADA tag is set up as though it is still receiving a raw count and applies its own span-and-offset scaling on top. The value is now converted twice. The reverse also occurs, where the SCADA is meant to do the scaling but the field device has already done it, so the SCADA re-scales a value that was already in engineering units.
The root cause is almost always unclear ownership of the conversion. When it is not firmly established whether the controller or the supervisory system is the one place that scales a given point, two well-meaning configurations can each add the step, or a change on one side, someone moving the scaling into the PLC during an upgrade, can leave a now-redundant scaling in the SCADA that no longer belongs there. The defect is a coordination failure, not a mathematical one: each scaling step is individually correct, but nobody confirmed that only one of them should exist.
The easiest double-scaling errors to catch are the ones that produce an obviously impossible value. When a conversion is applied twice, the value is typically wrong by roughly the scaling factor, so a pressure that should read a few hundred might read in the tens of thousands, or a level that should sit at a few meters might read a fraction of a meter. An order-of-magnitude discrepancy against the expected range, or a value that has blown past the physical limits of the equipment, is a strong hint that a conversion has been applied one time too many. Comparing the displayed value against what the process could actually be doing is the first and often the fastest check.
The harder cases are the ones where the doubly scaled value happens to land somewhere plausible. If the scaling factors and offsets combine so that the twice-converted number still falls inside the range an operator expects, nothing looks wrong at a glance, and the error can persist for a long time. Catching these requires a cross-check against an independent reference: comparing the tag against a second measurement of the same quantity, against a manual gauge reading taken in the field, against a mass or volume balance, or against the same point as seen directly at the PLC before the SCADA scaling. When the SCADA value and the field or controller value disagree by a consistent factor, double scaling is a leading suspect.
Double scaling should also be distinguished from its cousins so the diagnosis is precise. It is not a swapped range, where the span or zero has been entered backwards or the wrong raw range was used, which tends to make a value read reversed or off by a different pattern. It is not a wrong single scaling factor, where one conversion was simply mis-entered. Double scaling is specifically the conversion being applied twice, correctly each time, so the signature to look for is a value wrong by the scaling relationship itself, consistent with the same conversion having been stacked on top of a value that was already converted. Recognizing that signature points the investigation at the ownership question rather than at a typo in a single scale factor.
The durable fix for double scaling is not a better formula but a governance rule: every point has exactly one place where its raw-to-engineering conversion is performed, and that place is documented and owned. Whether the conversion lives in the field device or in the supervisory layer is less important than that the choice is made explicitly, recorded, and consistent, so that the layer that is not responsible for scaling is configured to pass the value through untouched. Once ownership of the conversion is unambiguous for every tag, the conditions that allow two configurations to both apply it simply do not arise.
This rule earns its keep most during change. Upgrades, migrations, and integrations are exactly the moments when a scaling step gets added on one side without the other side being adjusted, so a new controller that now does the conversion internally must be paired with removing the redundant scaling from the supervisory tag, and vice versa. Treating the location of the scaling as a governed attribute of the point, reviewed whenever the point or the devices around it change, prevents a well-intentioned upgrade from quietly leaving two conversions in place. The discipline is to always ask, for any point being touched, where its single scaling lives and to confirm nothing else is scaling it too.
For a cloud SCADA platform such as Merobix, the boundary between the field device and the hosted system is precisely the seam where double scaling likes to hide, because the device is configured in the field while the tag is configured centrally. Establishing clearly that a given point is delivered to the platform already in engineering units, and configuring its tag to accept that value without re-scaling, removes the ambiguity across that seam for good. Because the platform holds the definitive tag configuration centrally, the decision about where each point is scaled is recorded in one place and applied consistently across every site, so a value arriving pre-converted from an RTU is not scaled a second time on the way into the shared history, and a fleet-wide report is not quietly built on numbers that were converted twice.
It happens when two places in the chain from sensor to display both apply the raw-to-engineering conversion because it is unclear which one owns it. Typically the PLC or RTU converts the value to engineering units and the SCADA then scales it again as if it were still a raw count, or the reverse. Each step is individually correct, but nobody confirmed that only one of them should exist, so the conversion gets stacked on itself.
The obvious cases show an order-of-magnitude error or a value beyond the equipment's physical limits, since the value is wrong by roughly the scaling factor. The harder cases land on a plausible number, so they need a cross-check against an independent reference such as a manual gauge reading, a second measurement, a mass or volume balance, or the same point seen directly at the PLC. A consistent-factor disagreement points to a doubled conversion.
A swapped range means the span or zero was entered backwards, or the wrong raw range was used, which tends to make a value read reversed or off by a distinct pattern. Double scaling means the conversion was applied twice, correctly each time, so the value is wrong by the scaling relationship itself stacked on an already-converted value. The fix for double scaling is establishing a single owner for the conversion, not correcting a reversed span.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.