Breaking the Smart Building Technology Onboarding Cycle

We feel the frustration from clients regularly. They sign up to Building Application X, Y or Z, and have their building data mapped and analysed. Despite the many tools that automate data onboarding, it can take months of tweaking and re-modelling before the data is insightful and delivers their use cases.

Then comes a need or want to change. Perhaps the client isn’t satisfied with the current system, or they want another means of analysis for new use cases or compliance. In our experience of reviewing, testing, developing and implementing Smart Building Platforms, no single catch-all system delivers every use case. So the onboarding cycle starts again.

This got us thinking: how do we break it?

When we talk to software platform providers, we always ask, “how can we make it easier to onboard a building onto your system?” The industry still hasn’t fully proven the long-term value of the upfront investment in smart building technology, and shortening onboarding is one of the most direct ways to speed up the testing and validation of new tools and analytics.

Owning the Data Layer

Watching a client go through this pain first led us to develop the concept of an Independent Data Layer (IDL): building data that is owned by the client, structured in an agreed format, and independent of any one application. Its foundation is the live telemetry from multiple normalised building services systems, stored in a time-series database in a structure agreed with the client upfront.

That means if they move to a new software tool three years down the line, they still have their full history in the same standardised structure. In a world of AI and analytics, data is king, and a long record of how the BMS and plant behave across seasons and conditions has proven value for analysis and optimisation.

But the problem wasn’t solved. Historic data alone isn’t the whole story. An IDL also needs a description of what the data is: which points belong to which equipment, and how that equipment relates to spaces and systems. That semantic context is what lets a new tool understand a building rather than start from scratch.

What can you do

Whether you’re an owner, operator, integrator, consultant or contractor, start by thinking about how you own, store and semantically describe building data so it is portable between applications. The data, and the description of how it relates to your building, belong to you, not to whichever platform happens to be analysing it this year.

The benefit is simple:

Portable data (retained history, no lock-in) + portable context (semantic description) = faster onboarding and more flexibility

You’re free to bring in new analytics or switch providers without redoing the groundwork each time.

Questions for building owners and operators

• Do you have an IDL, and where is it stored?
• What does it look like?
• What should it consist of, both the data and its description?

Coming soon: how to prepare your building data for AI. We’ll look at the context needed around your IDL and where semantic data fits in, and how adding semantic understanding is key to unlocking more value and insight from your data, quickly and efficiently.

Authors:

John Clarke –Managing Director, One Sightsolutions

Jim Griffin –Senior Smart Buildings Engineer, One Sightsolutions