Are building operators owning their systems – or just renting access?

Chris Timmins, Chief Commercial Officer at IOTech Systems, explores how closed platforms can create challenges around commissioning, reliability and handover, and why an edge-led approach offers operators another option.

Anyone who has gone through commissioning knows that the engineering is usually not the hardest part. The real challenge is getting access: access to data, the ability to make changes, and handing over a system in a way the operations team can use for years to come. The technical work is often straightforward, but issues with permissions, data and handover slow everything down. It’s like opening a new restaurant: the recipes are ready, but if the kitchen staff can’t get the keys or the ingredient list, nothing gets served.

All that friction adds up and, in the end, it’s the operations team that must deal with it. We’ve seen situations where a simple configuration change turns into a two-week process because the operator must wait for someone with the right credentials to come on site. Or, if they want to pull their own data into analytics, they find out they’re being charged by the data point, so now they’re forced to decide what they can do without. Tagging and ontology work often gets left out entirely because, when it’s a separate line item, it gets cut to keep upfront costs down, even though that just creates bigger problems later.

None of this is necessarily a controls problem. It is an ownership problem. And it is one reason edge-led architectures are starting to change how estates teams, specifiers and contractors think about commercial building infrastructure.

Commissioning

Commissioning, as it is typically carried out, can be a laborious process. It requires someone to survey the building, determine the connections, interpret the meaning of each point and then map this information into a format that the wider system can utilise. On larger sites, this represents several weeks of skilled work, and that expertise is increasingly scarce and costly. This is similar to the situation in manufacturing, where those with a deep understanding of legacy systems are retiring more quickly than they can be replaced.

The workforce problem here is real and well documented. Every year, the industry holds panels on the dwindling pool of building automation specialists, and every year the answer is the same: better tooling. What has changed is that the tooling has evolved considerably. Auto-discovery and auto-tagging running at the edge can interrogate a network, pull the device identifiers and map them against an open ontology such as Haystack or Brick, reducing the amount of manual work required. Work that may previously have been deferred because of cost or resource constraints can therefore become more practical to undertake as part of commissioning.

This isn’t just about the commissioning budget. When data is standardised and well tagged, it can make everything else – diagnostics, fault detection, portfolio reporting, even AI and analytics – run more smoothly. Skipping tagging doesn’t necessarily save money in the long term; it can simply push the costs into operations, where they’re harder to see and even harder to fix.

Reliability

If you want real dependability in building services, you need to be able to tell the difference between normal changes and actual faults. That means you need access to past data, context and systems that talk to each other. Just throwing another proprietary dashboard at the problem isn’t going to fix it.

This is where the cost of data points in closed platforms can become a reliability problem, not just a business one. If operators are limited in how much data they can collect and move, there is a risk they will collect less. With less data, they may lose some of the historical baseline needed for effective anomaly detection. Teams can end up working with only part of the picture because accessing the full picture becomes too expensive.

This directly affects maintenance. Without a reliable baseline, it can be difficult to tell if a unit is drifting or if it has always worked that way, leaving maintenance more reactive and calendar-based rather than driven by actual conditions. As analytics improve in the coming years, operators that have been collecting and structuring data effectively from the start are likely to be better placed to take advantage of them.

Edge-led collection offers another approach: process locally, retain what you need and route selectively to whichever analytics platforms, cloud services or internal data lakes are appropriate. The operator decides what goes where. Not everything needs to leave the building, and not every task necessarily requires the most expensive available model.

There is a broader point here that the market is still working through: different tasks warrant different models, and a good deal of useful diagnostic work may run perfectly well on less computationally intensive or lower-cost models, sometimes on the edge device itself. Defaulting everything to a single premium model because of an existing enterprise agreement may be a decision operators have not consciously made, but one that still has cost implications.

Interoperability and system changes

The real test for interoperability is not just, ‘Can these two systems talk to each other?’ It is, ‘Can the estates team actually make changes without kicking off a drawn-out licensing battle?’

For estates with multiple systems, or where switching providers or vendors matters, open, standards-based interfaces can provide an advantage when it comes to the economics and flexibility of ongoing operation.

When a building’s data is available through open APIs rather than a proprietary gateway, an operator may be able to trial a new energy analytics provider without replacing existing infrastructure, because that provider does not necessarily need to be on site to start receiving data. They may also be able to switch providers without losing their historical record if the data is retained independently, and integrate systems that were never originally designed to communicate with each other.

This can affect contractors too. When a contractor is asked to add a system or extend a network, they must first check whether the platform allows it and what the licensing costs are. This can mean talking to the vendor instead of the client, which slows down the job for reasons no one on site can control.

With an open data layer, that process can be more straightforward. It can also give contractors greater scope to offer services such as remote diagnosis and configuration on jobs that might otherwise require a site visit and a licensed engineer. This can be particularly useful for large, geographically dispersed estates.

Handover and evidence

Handover is where you either lock in operational ownership or lose it. If a building gets handed over with a proprietary, poorly documented tagging structure, the new operator is basically starting from scratch. And when managing agents change, the whole process can repeat because the new team may not be able to make sense of the last team’s conventions.

For estates that expect to change managing agents over the building’s life, specifying open ontologies and interfaces at the design stage can be a cost-effective way of supporting long-term reliability. Without it, a proprietary or poorly documented structure can mean the new team starts from scratch every time the agent changes, repeating survey and tagging work that a standardised model may have avoided.

Handover documents should include a usable data model, not just as-built drawings and a login. If operators can’t query their building from day one without calling for help, there is a reasonable argument that the handover is not yet complete, no matter what the paperwork says.

Cyber resilience

Opening building data raises real concerns about exposure, and those deserve a straight answer. Edge-led doesn’t mean all your data is flying out to the internet. Local processing can reduce how much operational data leaves the site and give operators greater control over what goes out, where it goes and who can access it.

What it does require is that access control, segmentation and update responsibility are treated as first-class parts of the design, rather than assumed to be handled by whoever supplied the controller. That is a governance question as much as a technical one, and it belongs in the specification.

The underlying point

All these issues – commissioning costs, diagnostics, system changes and handover headaches – really come back to one central question: do operators truly own their operations, or are they just renting access?

For a long time, that question did not have a straightforward practical answer because the architecture did not always allow one. The options available to operators are now broader. Buildings where questions around data ownership, interoperability and operational control are considered at the design stage are likely to be better placed to avoid some of the cost and reliability issues that can otherwise emerge several years into an operating contract.