Schneider EcoStruxure Building Operation runs a lot of commercial estates well. It holds schedules and sequences and raises alarms exactly as commissioned. Building Advisor gives cloud-connected sites a first pass at analytics on top. What neither one does is rank a sticking valve in one building against a drifting chiller three sites over, or fold in the Siemens estate down the road and the meters bolted on since. That gap is why so many EcoStruxure estates end up asking whether to expand within the Schneider stack or add a vendor-agnostic layer above it. Our Schneider EcoStruxure integration page covers the mechanics of the connection itself; this article is about the reasoning for adding an analytics layer.
What EcoStruxure Building Operation gives you, and where it stops
EcoStruxure Building Operation is a capable control layer. It runs HVAC, lighting and access sequences across a portfolio from one console. Cloud-connected sites also get Building Advisor's own detection rules on top. Most complaints about an EcoStruxure estate are not really complaints about EcoStruxure. They are a facilities team staring at a supervisor screen that shows every point and prioritises none of them, or a Building Advisor licence that only covers half the portfolio.
That is the edge Building Operation was never built to work at. A control system's job is to run one building correctly, not to weigh a valve fault in Gothenburg against a chiller drifting three sites away and decide which to fix first. Ask an EcoStruxure estate to do that natively and the result is more dashboards, not more clarity. Building Advisor was designed to read Schneider assets. Once a portfolio mixes vendors, the cross-site view stops at the Schneider boundary.
Reading EcoStruxure read-only, cloud API or on-prem agent
None of this requires touching anything EcoStruxure controls. A site running the cloud tier connects through Schneider’s own API: a client ID and a token, and data can start flowing the same day. A site running Building Operation on-prem, which is most of what we meet, connects through the FrostLogic Edge Agent instead. It reads the system locally over BACnet, OPC UA or Modbus and pushes the data read-only, without write access.
The on-prem case is worth dwelling on, because it is the normal case, not the exception. Plenty of EcoStruxure estates were commissioned with the cloud tier priced in, then never bought, or bought once and left to lapse. So every point Building Operation collects sits on one server in the plant room, invisible above building level. The Edge Agent connects that server directly, and skips the data-aggregator middleman too: no second vendor moving your data into a cloud first. One copy, stored in the EU. Not sure which protocol an estate is actually running? Our BACnet vs Modbus vs OPC UA guide breaks down the differences building by building.
Either route lands in the same place: EU-hosted infrastructure, GDPR-native by default. Nothing about Building Operation’s own data residency changes as a result of connecting it, and there’s no lock-in if a contract ever ends. See how FrostLogic handles data residency for the full posture.
What an EcoStruxure analytics layer adds on top
Once the data is flowing, FrostLogic Explore runs six detection methods against Building Operation's own points: statistical baselines, forecast residuals, pattern and seasonality matching, cross-signal correlation, drift detection, and physics constraints, then reconciles the results. Forecasting adds confidence bounds to every prediction, so an estimate comes with a stated margin of error rather than false precision. Continuous compliance checks the same data against BREEAM, LEED and Nordic Swan criteria on an ongoing basis, rather than in the usual scramble before an audit.
Running Building Advisor on the cloud-connected buildings? Keep it where it earns its keep. Explore reads the same points read-only, covers the buildings Advisor was never built to see, and grounds every finding in the physics of the building through Frostdynamics rather than a language model's guess at what a setpoint should be. Nothing gets ripped out to add it. Every finding, wherever it originates, lands in one ranked queue instead of a Schneider dashboard and a second tool for everything else.
A worked EcoStruxure drift example
Here is what that looks like on an actual point. A supply-air temperature on an EcoStruxure-controlled AHU starts running half a degree warm. Nothing alarms. It sits well inside any threshold Building Operation would flag, and on a supervisor screen it reads as noise.
Statistics barely notices, since half a degree sits inside normal variance. Drift detection catches the slope anyway: the slow, directional creep a threshold rule is built to ignore because no single reading ever crosses a line. Cross-signal correlation shows the heating valve opening further to compensate, a relationship a single-point alarm cannot see. Severity scoring weighs the persistence of the drift against the rising energy draw and flags it as material, the difference between something worth a look and something worth a ticket.
What reaches the engineer is not forty raw threshold alerts scattered across a shift log. It is one line: AHU-3 heating valve drifting, approximately 4% energy impact, investigate this week. Building Operation saw the temperature the entire time. It had no way to say what the temperature meant, and that is the difference between a trend log and a decision.
Getting an EcoStruxure estate connected
In practice there are a handful of routes in, depending on how the estate was built. A cloud-connected Building Operation deployment is the simplest case: credentials, and data flows the same day. On-prem sites go through the Edge Agent instead, reading BACnet, OPC UA or Modbus off the existing management PC, usually installed remotely in an afternoon.
The realistic case for most portfolios is neither pure Schneider nor pure anything else. A retail estate runs EcoStruxure in the flagship stores and Siemens Desigo in the retrofits. An industrial site runs Trend in the older buildings and Bastec in the newer ones. That is the normal shape of a portfolio, not an edge case, and it is exactly what Explore was built for. Every one of those systems reads into the same model, and the queue ranks a Schneider fault against a Siemens fault by what each is actually worth fixing, not by which vendor happened to win the tender that year.
None of this asks for a migration. Read-only ingest means Building Operation keeps controlling exactly what it controls today, and day-one export means the data and the findings leave with you if a contract ever ends. There is no rip-out on the way in, and no lock-in on the way out.
Other BMS vendors, same approach
None of this is specific to Schneider. The same read-only pattern applies to any BMS speaking BACnet, Modbus or OPC UA, which covers most of them, and the same read-only pattern works for Siemens Desigo too, covered in detail in Siemens Desigo analytics integration. Running a mixed estate already, EcoStruxure in some buildings and something else down the road? The full list of supported integrations covers Siemens, Honeywell, Trend, Bastec and the rest, all reading into the same model and the same queue, so a portfolio never needs one tool per vendor.
FAQ
Does adding an analytics layer to EcoStruxure require touching the control logic?
No. The connection is read-only from end to end. It does not modify sequences, setpoints, or alarm logic, and it never sits in Building Operation's safety chain, so there is nothing for a controls contractor to sign off on.
What protocols does this read from an EcoStruxure estate?
Schneider's own cloud API where a site has the cloud tier. BACnet, OPC UA or Modbus through the FrostLogic Edge Agent where it runs on-prem, which is most of what we meet.
Does this replace EcoStruxure Building Operation or Building Advisor?
No. Building Operation keeps running the buildings, and Building Advisor keeps doing whatever it already does well on the cloud-connected sites. Explore reads the same points read-only and adds detection, forecasting and ranking on top, without removing anything from the existing stack.
Is there a CMMS overlap, or does this replace EcoStruxure's native controls?
No to both. Explore is not a CMMS. It surfaces and ranks what is wrong; opening a work order and dispatching a technician stays with whatever maintenance system the team already runs. It also never touches Building Operation’s native control functions, which keep operating exactly as before.
Which EcoStruxure deployments does this work with?
Cloud-connected Building Operation, on-prem Building Operation, and the older StruxureWare-era systems some estates still run. Anything that exposes its points over the cloud API, BACnet, OPC UA or Modbus is readable.
Does this need new hardware on site?
Usually not. The FrostLogic Edge Agent typically installs on the existing Building Operation server or a machine that can already reach the BMS network, and most installs take an afternoon rather than a project.
How long before findings start showing up?
Most estates see first findings within the first week of data flowing, though the queue gets sharper as more history accumulates and the model learns what normal looks like for that specific building.
Where is the data hosted?
EU-hosted infrastructure on Hetzner, GDPR-native by default. Nothing about Building Operation's own data residency or network setup changes as a result of connecting it.
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.
