Digital Twin technology for decarbonising any built environment.
Integrated analysis tools for the design & retrofit of buildings.
Create a sustainable masterplan for a city, community or campus.
Optimise building performance at an individual level or across a portfolio.
Analyse the feasibility of energy network decarbonisation strategies
A customisable range of operational dashboards, portfolio management and community engagement tools.
Exceptional room & zone loads analysis for building & HVAC design.
Predict building energy consumption, CO2 emissions, peak demands, energy cost & renewable production.
All Consultancy Projects
Data analytics in buildings. What should in theory be a streamlined engineering process can become complicated quickly. This article describes some of the challenges faced by Building Managers and Owner/Operators when deploying building analytics across a building or portfolio.
At a conceptual level the overall building analytics process can be broken into three component stages:
1. Data Survey
2. Data Exchange
3. Data Analysis
So for a Building Manager/Owner/Operator looking to deploy a building analytics solution it should be relatively straight forward you'd think:
So where does the process go wrong? What is it that makes this simple process definition become a more complicated affair?
From my own experience as a building analytics practitioner the challenges are almost always linked to the overall concept of Data Ownership. Struggle and debate is never far away when the themes of data access, data ownership and associated contracts are involved.
The typical building analytics offering goes something like this:
Analytics Provider: "Hi Building Owner/Operator, you should really check-out our building analytics services. Understanding and utilising your data better would really help you identify inefficiencies, achieve energy/cost savings and assist with investment strategy planning"
Owner/Operator: "Ok, sounds great. I'd love to try a pilot project. Energy/Carbon saving across the business is a primary Board level focus right now and is getting lots of attention, so we'll have the budget available for sure. What do you need to get started?"
Analytics Provider: "We need access to you Energy Metering and BMS data. Historical data can be a great resource, so if you have data records going back over say the last 12-months we could start with that before developing a live feed."
Owner/Operator: "Ok, I'm interested. We employ a 3rd party BMS Service Company to maintain our BMS system but they will have all the data you need for sure. Speak to Engineer X and they'll give you everything you need to get started, here are their contact details..."
<<< Some time later... >>>
Engineer X: "So you want access to historical BMS trend data. Sorry, but we don't routinely store that. Archiving trend data slows the BMS system down, there's not enough hard disk space either, and ultimately the BMS system is old and needs upgraded. Old parts are hard to get now and new BMS software upgrades are available too. We've been telling the Building Owner/Operator this for years but there is never any budget available. We'd also need an NDA and Data Sharing Agreement before we can share anything and the client's IT team will never allow it."
This is the pretty much where the data struggle begins. There is a difference in understanding between the Owner/Operator's expectation of the BMS Service/Maintenance Contract and what's actually being delivered within the Contract term.
Many Owner/Operators see the BMS system as some sort of magic box which manages itself with minimal human intervention or at restricted maintenance/service prices. Like all machines BMS and HVAC equipment needs to be well maintained or is likely to degrade over time and unlikely to deliver on design performance expectations.
So Engineer X, in an effort to try and steer any newly available budget towards their own backlog requirements (BMS hardware upgrades etc), can often restrict access to the data either intentionally or subconsciously. Technical road-blocks get introduced during the Data Survey discussions which ensure that any available data typically stays within a closed-protocol environment. Ultimately it's seen as not being the client's data at all but actually the BMS system's data. It's becomes a "the data in the machine stays in the machine" psyche... and even many so called 'open-protocol' BMS systems can easily fall into this trap.
To compound this issue further there is an inherent industry lack of Contract/Specification language on data access and ownership. Generally none of these contractual logistics are covered under any legal terms, and hence the data struggle ensues.
The Owner/Operator wants and expects the data to be available to feed the Building Analytics process, but the required data simply isn't accessible for one reason or another. Days become weeks, weeks become months, and months become Financial Years. Valuable building performance data records are lost, BMS/HVAC systems degrade, buildings underperform, and very little changes.
It's not without additional and often significant investment that things finally get moving. Typically this involves the building Owner/Operator paying additional BMS upgrade (or 'unlock') fees, either to install additional communication hardware (e.g. a Niagara based JACE = £££) or even a complete replacement of the entire BMS system infrastructure (£££££) which may have been perfectly adequate in the first place. BMS hardware is expensive and unnecessary system upgrades simply for the sake of it are a sure way to erode Return on Investment (ROI) margins on any energy project.
So what does this do to the building analytics and investment strategy planning process? Well it can often get blocked at the Data Survey stage before it really gets off the ground or project fees end up being diverted for additionally required equipment and project costs increase.
The barriers and data blocks which can develop in the Data Survey stage can often restrict the overall aims and objectives of the strategic downstream project(s). There are of course winners and losers in this process and needless to say it is seldom the building Owner/Operator who wins.
So what's the moral of the story? Initially I'd say there are some key points that can be taken away:
1. As an Owner/Operator make sure you have access to your Energy + BMS data. Don't simply believe that the data is there, make sure you can actually see it, pull down CSV data logs periodically on sample points and run some data sense checks. This is good practice and is sure to keep all project stakeholders sharp and alert.
2. If you don't currently have adequate Energy/BMS access then take steps to get closer to it. This could involve speaking to your BMS engineer or building analytics specialist to discuss the options that might be available. Ideally try and involve both in a round-table discussion... their varying perspectives on data access and data-driven objectives will be evident.
3. Consider going further and adding some technical/legal language into future contract specifications on data access and ownership. What's expected? What does compliance look like? How are data metrics actually measured? What are the penalties for non-compliance?
That's probably enough for now to spark some discussion and of course interested in any comments/feedback. It's a big industry globally and I appreciate there may be many other viewpoints on the topics discussed.
I may well discuss further on future posts and will hopefully even get to Stages 2 + 3 of the building analytics process! Meantime feel free to get in touch direct if you'd like to discuss any aspect of your data analytics workflow.