Most building sensor gaps get fixed the expensive way. Buy a probe. Run conduit. Get the point commissioned in the BMS. Wait for a contractor's slot to open up. A virtual sensor skips most of that. It's a metric calculated from sensors you already have, not a new piece of hardware. Supply-air enthalpy from a temperature and humidity reading. Occupancy from a CO2 trend. Equipment runtime from a power draw. If the physics connects two points, the second one is often a calculation away, not a purchase order away.
What a virtual sensor actually is
A virtual sensor is a derived reading. A physical sensor reports a value it measured directly. A virtual sensor reports a value computed from one or more other measurements, using a known relationship between them, whether that relationship is physical (thermodynamics, fluid dynamics) or statistical (a correlation learned from historical data).
The underlying idea has a longer history outside buildings. Process industries call it a soft sensor: inferring a variable that's expensive or impractical to measure directly, say polymer viscosity inside a reactor, from ones that are cheap and fast to read, like temperature, pressure, and flow rate. Chemical plants have leaned on soft sensors for decades because installing an in-line viscometer is a bigger job than reading three transmitters already on the line. Buildings are catching up to the same logic. A duct static-pressure reading can come from fan speed and damper position instead of a dedicated pressure transmitter. A chilled-water flow rate can come from valve position, delta-T, and the pump curve instead of a flow meter. In HVAC applications specifically, a virtual sensor most often stands in for a point that's either hard to reach physically or was never worth a dedicated transmitter in the first place.
Why you'd want one
Three situations push a team toward a virtual sensor instead of a work order. Coverage gaps: a point the original design never included, because nobody anticipated needing it, or the budget stopped short. Failed hardware: a probe that's been reporting a flat line for six months because nobody noticed, or noticed and the replacement is stuck in procurement. Points that are genuinely impractical to instrument directly: a steam trap buried behind insulation, a duct run through a finished ceiling with no access panel, a tenant space where the landlord can't get a contractor in without two weeks' notice.
In every case, the alternative to a virtual sensor is the same: procurement, installation, and a BMS re-commissioning cycle for a single data point. That's real cost and real lead time for something a calculation can often deliver in a week. Virtual sensors also do useful work where hardware already exists. Run a virtual sensor alongside the physical one it approximates, and a disagreement between the two is itself a signal: either the physical probe drifted, or the calculation's assumptions no longer hold for that piece of equipment.
Where virtual sensors earn their keep
Virtual metering for tenant sub-billing. Tenant billing and cost allocation usually want a submeter per space, and retrofitting one into every unit of an existing building is expensive. A virtual submeter derives a tenant's consumption from the main meter minus the loads that are separately metered, or from correlated equipment runtime where the relationship between runtime and draw is well understood. It won't match a certified revenue meter for billing-grade accuracy, but for cost allocation and anomaly detection, virtual metering is often close enough to be useful immediately.
Derived comfort indices. A single air-temperature reading doesn't tell you whether a space feels comfortable. Humidity, and to a lesser extent radiant surface temperature, matter too. A derived comfort index, calculated from the temperature and humidity sensors most zones already have, gets closer to what an occupant actually experiences than a bare temperature reading, without installing a globe thermometer in every room.
Inferred flow and load from correlated sensors. A flow meter that failed, or was never installed, doesn't have to mean flying blind. Where valve position, pump curve, and delta-T are all available, a virtual sensor can infer flow to a useful approximation. The same logic covers electrical load on a circuit with no dedicated meter, inferred from the runtime and rated draw of the equipment on that circuit.
Virtual sensors and data trust
A virtual sensor is only as good as what it's built on. Feed it a drifting temperature probe or a stale CO2 reading and it produces a confidently wrong number, without the visible failure signs a broken physical sensor usually shows. A dead probe often flatlines or reports an obviously impossible value. A virtual sensor built on bad inputs keeps producing plausible-looking numbers that are simply incorrect. That's a data-trust problem, and it applies to any calculated metric, not virtual sensors specifically. We've covered the broader question of validating sensor data before trusting it elsewhere; the short version is that a virtual sensor deserves the same drift-checking discipline as the physical inputs it depends on, not less.
Where virtual sensors fit in a sensor-intelligence stack
In FrostLogic Explore, a virtual sensor isn't a side feature bolted onto the analytics. It's an input, treated the same way as a physical one: versioned, watched continuously for drift, and validated before it's allowed to influence a forecast or fire an alert. That matters because the value of a virtual sensor isn't the calculation on its own. It's what the calculation feeds. Our BMS analytics platform reads physical and virtual sensors alike into the same anomaly detection, forecasting, and compliance pipeline, so a gap-filling virtual metric gets the same scrutiny, and does the same work, as a sensor with a physical probe behind it.
Curious what we could derive from your existing sensors? Request a demo and we'll look at what's already reporting in your BMS.
FAQ
Is a virtual sensor as accurate as a physical one?
It depends on what it's built on and how well the underlying relationship is understood. A virtual sensor derived from a well-characterized physical relationship, like enthalpy from temperature and humidity, can be very accurate. One built on a statistical correlation is only as good as the data it was trained on and how closely current conditions match that training period. For billing-grade accuracy, a certified physical meter still wins; for trending, anomaly detection, and gap-filling, a well-built virtual sensor is usually accurate enough.
What data does a virtual sensor need?
At minimum, the input sensors it's calculated from, sampled at a rate fine enough to catch the changes you care about, plus a known or learned relationship linking those inputs to the output you want. Physics-based virtual sensors need fewer historical data points than statistically-derived ones, which need enough history across enough operating conditions to learn a reliable correlation.
Can virtual sensors replace physical metering entirely?
No, and that's not really what they're for. Virtual sensors fill gaps and add redundancy; they don't replace the physical sensors a building actually needs for control loops, safety interlocks, or billing-grade metering. Where hardware exists, it should stay. Where it doesn't, and installing it is disproportionate to the value of the point, a virtual sensor is often the more sensible investment.
What's the difference between a soft sensor and a virtual sensor?
They're the same concept under two names. Soft sensor is the term process industries have used for decades. Virtual sensor is the term that's caught on in buildings. Both describe an inferred reading calculated from other measurements rather than measured directly.
How does FrostLogic Explore use virtual sensors?
As inputs, not as a side feature. Explore treats a virtual sensor the same way it treats a physical one: versioned, watched for drift, and validated before it's allowed to feed a forecast or trigger an alert through the FrostDynamics engine.
Does a virtual sensor need its own point in the BMS?
Not necessarily. A virtual sensor can exist purely in the analytics layer, calculated from BMS trend data without ever being written back as a BMS point. Some teams do write it back, usually when other systems like dashboards or reporting tools need to read it as if it were a native point.
How do you know if a virtual sensor's calculation is still valid?
Watch it the same way you'd watch a physical sensor for drift, and where possible, run it alongside the physical sensor it approximates so disagreements surface early. A calculation that held for one operating mode of a piece of equipment can quietly stop holding after a retrofit, a setpoint change, or a control sequence rewrite, so it needs the same ongoing scrutiny as anything else in the data pipeline.
FrostLogic Explore brings sensor intelligence, scenario simulation, and grounded-inference AI to commercial and industrial buildings. Learn more about Sensor Intelligence or talk it through with us.
Curious how this would look on your building?
What's your building not telling you?
Tell us what you're trying to figure out: energy drift, a BMS you don't trust, compliance you're chasing. We listen first, then tell you straight whether Explore helps. 30 or 60 minutes, your pick. No commitment either way.
