Some of the things an operator most wants to know - the composition of a product, its quality, the emissions from a stack - are slow, costly, or impossible to measure directly and continuously. A soft sensor sidesteps that by estimating the hard-to-measure property from other measurements that are already available and are known to move with it. This guide explains what a soft sensor is, how it is built and kept honest against laboratory results, and the situations where it quietly stops being trustworthy.
Soft Sensor (Inferential Measurement) in one line: A soft sensor, also called an inferential or virtual sensor, is a model that estimates a property that is difficult or expensive to measure directly by using other tags that correlate with it. Instead of a physical analyzer, it combines readily measured variables such as temperatures, pressures, and flows through a mathematical or statistical relationship to produce a continuous estimate of something like product composition, quality, or emissions. It is calibrated against occasional real measurements, typically laboratory samples, and its estimate is only as good as the correlation and the calibration behind it.
The idea behind a soft sensor is that a property you cannot measure cheaply is often closely related to properties you can. The purity of a distillation product, for instance, tracks the temperatures and pressures on the column; a stack's emissions relate to fuel flow, air flow, and combustion conditions. If that relationship is stable and well understood, a model can take the easy measurements as inputs and compute an estimate of the hard property as an output, continuously and at no marginal cost, standing in for a physical analyzer that might be slow, expensive, or simply absent.
Soft sensors span a spectrum of sophistication. At one end are first-principles models built from the known physics and chemistry of the process, where the relationship between inputs and the estimated property is derived from theory. At the other are data-driven models trained on historical records, where the correlation is learned statistically from how the tags have moved together in the past. Many practical soft sensors are hybrids, using physical structure where it is known and empirical fitting to capture the rest. What they share is that the output is a computed inference, not a direct reading - the property was never actually measured, only estimated from things that were.
Because a soft sensor's output is never directly measured, it has to be anchored to reality through periodic real measurements - most often laboratory analysis of grab samples. The lab result is the truth against which the model is calibrated: the soft sensor is tuned so its estimate matches the sampled value, and thereafter its ongoing bias is checked by comparing new estimates against new lab results. A soft sensor that is never checked against the lab will slowly become a confident source of wrong numbers, so the sampling loop is not optional maintenance but part of how the sensor works.
Soft sensors fail in characteristic ways, and knowing them is what separates a useful estimate from a dangerous one. They are only valid within the range of conditions their model was built for; push the process into a regime the model never saw, and the extrapolated estimate can be badly wrong. They rely on their input tags being healthy, so a single drifting or failed instrument among the inputs can corrupt the output silently, without any obvious error. And the correlation itself can decay over time as equipment fouls, catalysts age, or feedstock changes, so a relationship that held at commissioning may no longer hold years later. This is why a soft sensor is treated as an aid that must be validated rather than a measurement to be trusted blindly.
A soft sensor consumes many input tags and produces a derived one, which maps naturally onto how a cloud SCADA already handles data. In a platform such as Merobix, the temperatures, pressures, flows, and analyzer readings a soft sensor needs are already being gathered from the field over Modbus, DNP3, OPC UA, and MQTT and held as live tags. The inferred property can be computed from those inputs and presented as just another value on the operator's screen, indistinguishable in use from a physically measured tag even though it is calculated.
The historian side of the platform is what keeps the sensor trustworthy over time. Because both the input tags and the periodic lab results can be stored together, an operator or engineer can overlay the soft sensor's estimate against the lab samples, see when the two have started to diverge, and recognize when the model needs recalibration before the drift causes a bad decision. Keeping the input history also means that when an input instrument fails, the effect on the estimate is visible and can be diagnosed rather than hidden. Treating the soft-sensor output as a first-class tag - trended, alarmed, and audited like any other - is what lets it add value without becoming an unverified black box.
A virtual flow meter is a specific kind of soft sensor - one whose estimated property happens to be flow rate, inferred from pressure, temperature, and choke position. A soft sensor is the general concept: a model that estimates any hard-to-measure property, such as composition, quality, or emissions, from correlated measurements. Every virtual flow meter is a soft sensor, but soft sensors cover far more than flow.
It is calibrated against real measurements of the property it estimates, most commonly laboratory analysis of samples taken from the process. The model is tuned so its estimate matches the lab result, and its ongoing accuracy is monitored by comparing later estimates against later samples. This lab loop is essential because the soft sensor never measures the property directly, so without periodic ground truth it will slowly drift away from reality.
Distrust it when the process is running in conditions outside the range its model was built for, when one of its input instruments may be drifting or failed, or when the underlying process has changed through fouling, aging, or a feedstock switch. In all of these the correlation the sensor depends on may no longer hold, so the estimate can be confidently wrong. Regular comparison against lab results is the main defense against being misled.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.