When a BMS Alarm Isn't the Real Problem: Turning Building Data Into Engineering Decisions
A practical look at fault detection, energy analysis, predictive drift, and benchmarking using real BMS data
A building management system (BMS) can tell you that an air handling unit (AHU) is operating, that the temperature is higher than normal, and that a valve is open to 95% of its maximum capacity—but can it tell you the root cause behind all these observations? This is an extremely difficult question.
Modern buildings continuously generate massive volumes of data from various sensors and device points. Today’s core challenge is no longer collecting data, but converting that data into actionable information that facility engineers can implement directly. This is exactly where the value of BMS analysis tools lies, and our research will launch its investigation with an analysis of a single AHU.
Start With One AHU
Consider a typical AHU with five important data points:
- Temperature
- Temperature setpoint
- Cooling valve position
- VFD speed
- Run status
Suppose the BMS reports:
Temperature → Above setpoint
Cooling valve → 95% open
VFD → Running
Run status → ON
Duration → Several hours
A conventional dashboard can display all of these values.
But the engineer's question is different:
Why is the AHU still missing its setpoint when the cooling valve is almost fully open?
That combination can indicate a cooling-capacity limitation.
Possible causes include:
- Dirty cooling coil
- Low chilled-water flow
- Low CHW temperature
- Undersized coil
- Valve or actuator problems
The important point is that no single data point provides the answer.
The relationship between the points does.
From Monitoring to Operational Intelligence
A monitoring system can display the actual situation.
For example:
AHU01
Temperature → 24.8°C
Setpoint → 20°C
Cooling valve → 96%
This information is useful.
But engineers often need something more meaningful:
The cooling valve remains fully open, but the air handling unit (AHU) never reaches the set temperature. Please check for constraints on cooling capacity.
The first output describes the actual situation that has occurred.
The second output attempts to explain the meaning of that situation.
This is exactly the core difference between basic monitoring and operational intelligence.
A monitoring system can output basic data for a single unit such as its temperature, setpoint, and valve opening while analysis can integrate this information to produce conclusions with greater value for decision-making.
Four Things Analytics Should Tell an Engineer
Instead of asking whether a BMS is "AI-powered", a more useful question is:
What engineering problems can this set of analysis tools solve?
In the daily operation and maintenance of buildings, four core categories of problems deserve attention.
Is There Any Abnormality in Equipment Operation?
The primary task is to identify abnormal behaviors, and the specific scenarios include:
- Valve saturation
- Valve leakage
- Sensor anomalies
- Unstable control
- Sudden temperature rise
A qualified analysis system must never only generate a list of hundreds of alarms. Instead, it should be able to distinguish between normal behaviors and those that require investigation, which can greatly save engineering time.
Does Equipment Energy Consumption Exceed the Necessary Level?
Energy consumption analysis is another core application.
For variable-speed fans, analysis can be conducted based on the affinity law (power is proportional to the cube of rotational speed): when the rotational speed decreases, the power of the fan will drop significantly.
In addition, the behavior of valves can be analyzed through thermal models to estimate the energy-saving potential in the cooling process.
But there is an important rule:
Never trust any energy-saving ratio blindly; always press for details on how it is calculated.
Statements such as “this system can save 20% of energy” are incomplete.
A result with reference value must specify what data was used, what baseline was selected, what formula was applied, what operating period was analyzed, and whether the result was obtained through actual measurement or simulation.
Only in this way can the energy-saving figure be verifiable.
Is the Equipment Gradually Deteriorating?
Not all equipment problems appear suddenly; performance may decline step by step.
For example, the process could unfold as:
normal operation → growing temperature deviations → longer valve opening durations → increased control deviations → the need for maintenance
Trend analysis can identify such issues before they develop into obvious failures.
A temperature trend that continuously deviates from ideal operating conditions can serve as an early warning, but there is an important distinction that must be clarified here.
Early warning drift detection is not equivalent to full predictive maintenance, and the quality of prediction depends entirely on the availability of usable data.
Which Equipment Should Be Prioritized for Maintenance?
As the scale of building equipment fleets continues to expand, the question of "which piece of equipment should be prioritized for maintenance" has become increasingly critical.
Imagine:
50 AHUs
100 AHUs
500 AHUs
If an operation and maintenance team manages 50, 100, or even 500 air handling units, and all units trigger alarms at the same time, the team has no way to investigate every problem simultaneously.
This is where benchmarking plays a key role.
It transforms the question of "which devices have triggered alarms" into "which devices have the worst performance", and generates a priority list using a unified efficiency score.
A Real 37-AHU Example
This logic is not just empty talk.
We applied this method to building management system (BMS) data from 37 AHUs at a cooling station.
The analysis layer only relies on several types of information from the original BMS:
- Process variables
- Setpoints
- Valve outputs
- Variable frequency drive (VFD) outputs
- Operating status
No new on-site hardware is required.
Across the 37 AHUs, the analysis calculated:
₹5,046,879/year
The analysis also calculated:
667,464 kWh/year
and:
547 tonnes/year
The method could simulate annual savings of 5,046,879 Indian rupees, reduce energy consumption by 667,464 kilowatt-hours, and avoid 547 tons of carbon emissions.
These aggregate results are already impressive, but findings from individual AHUs are even more noteworthy.
For example, unit AHU01 has its VFD consistently running at around 70% of maximum speed, and it has both energy-saving potential and a fault.
This shows that analysis cannot only focus on positive energy-saving outcomes.
AHU01: Savings and Faults in the Same Data
Using the Affinity Law, the analysis calculated:
56.6% Fan Energy Savings
The calculated monthly energy cost savings are approximately:
₹11,089 per month
Which translates to an annual total of:
₹133,068 per year
The average opening rate of the cooling valve is around 38.7%.
This analysis also calculated:
61.3% Chilling Energy Savings
The corresponding monthly energy cost savings are approximately:
₹4,363 per month
At first glance, these figures make this seem like a successful building energy efficiency case.
Yet the same set of data reveals a critical problem: the cooling valve stayed at or above 95% opening for 39 consecutive hours, but this air handling unit (AHU) still could not reach its set temperature.
The system also recorded 138 high-temperature peaks, with a measured maximum temperature of 37°C—far exceeding the set value of 20°C.
Possible causes include insufficient chilling capacity, valve leakage, sensor malfunctions, or abnormal actuator or manual override performance.
This is the key strength of this analysis: it did not only output the single conclusion that "AHU01 is energy-efficient and high-performing". Instead, it presented both the energy saving potential and operational faults, which is the truly useful information for operation and maintenance (O&M) engineers.
Why Operational Faults Must Not Be Overlooked for the Sake of Highlighting Energy Savings
Buildings are not marketing dashboards.
A single AHU can perfectly achieve energy savings while also having poor operational status and developing faults.
If an analysis system only reports positive results, it cannot provide a complete picture of the building’s O&M status.
Good analytics should expose both:
- Clearly separating well-functioning equipment
- Equipment requiring key focus
This makes the output far more practical for maintenance and engineering teams.
Benchmarking 37 AHUs
We conducted benchmark tests on 37 air handling units, and this analytical method can be applied to the entire project group.
In this example:
| Metric | Result |
|---|---|
| Best performer | 87/100 |
| Lowest performer | 4/100 |
| Portfolio average | 50/100 |
In this case, the highest-performing unit scored 87 out of 100, the lowest-performing unit scored 4 out of 100, and the average score across all units was 50 out of 100.
These findings lead to a core operation and maintenance question:
Which units should be prioritized for inspection?
This approach is completely different from the traditional logic that only counts the number of alarms.
Some units generate a large number of alarms but can still operate normally, while others have few alarms but suffer from control flaws and sustained performance declines.
Benchmark testing can clearly expose these types of discrepancies.
Don't Start With "AI"
Today, the label of "AI" is overused in the building technology sector, but for engineers, the methods that support results are far more important than any label.
If a platform says:
₹11,089/month saving
the obvious question is:
Where exactly does that number come from?
For the analysis of AHU01, different engineering problems require matching different methods:
| Problem | Method |
|---|---|
| Fault detection | SPC + Z-score + IQR |
| VFD energy analysis | Affinity Law |
| Cooling-energy analysis | Thermal modelling |
| Predictive drift | Linear regression |
| Benchmarking | Performance scoring |
The core principle is simple: apply the right method to the right problem, and do not force complex algorithms onto all building-related problems.
Interpretable Results Are Far Easier to Trust
Imagine a system reports:
AHU efficiency: 72/100
The next question should be:
Why is it 72?
An interpretable system must be able to answer:
- What data was used?
- What analysis period was examined?
- What methods were applied?
- What assumptions were made?
- What factors affected the score?
- What issues should engineers investigate?
This is the key difference between a "seemingly intelligent number" and a truly verifiable number.
Simple Engineering Models Can Be Powerful
Simple engineering models are equally powerful—not all building analyses require complex models, and in many cases, established engineering correlation logic is sufficient.
For example:
Fan power ∝ Speed³
The law that fan power is proportional to the cube of its rotational speed may seem simple, but it provides a solid physical foundation for analyzing the performance of variable-speed fans.
By the same logic, statistical methods can identify abnormal operating states of sensors without needing to build complex neural networks.
The objective isn't to make a system seem intelligent.
It is to make the results we produce truly practical.
But Don't Ignore Data Quality
Data quality is an issue that must never be overlooked: the effectiveness of any analysis can never exceed the quality of the data sources that support it.
The air handling unit (AHU) case study used in this paper draws on data collected and recorded every 15 minutes by a building management system (BMS).
This sampling frequency is sufficient to identify slow-changing conditions such as:
- Persistent valve saturation
- Temperature trends
- Long-term control deviation
However, it will cause under-sampling for fast control oscillations.
The predictive drift model we use also has clear limits to its applicability: temperature trends can provide early warning signs, but full state-based predictive maintenance requires additional data including:
- Motor current
- Vibration
- Operating hours
- Equipment health parameters
A reliable analysis system must clearly label all these limitations.
Do You Need to Replace Your Existing BMS?
As for whether existing BMSs need to be replaced? That is actually not necessary.
A major advantage of the analysis technology introduced here is its ability to reuse all the information that existing BMSs have already collected.
The architecture can be viewed simply as:
Sensors → DDC Controller → BMS → Analysis → Insights → Engineering Action
Instead of immediately asking, "Do we need a new set of building management systems (BMS)?", it is better to first ask a more valuable question:
"What useful information can we extract from our existing BMS?"
For a basic explanation of BMS architecture and building automation, please refer to:
https://ensmart.ai/blog/what-is-a-building-management-system-bms
For information on BMS/IBMS platforms and building automation solutions, please refer to:
For an in-depth understanding of building management software and methods for calculating return on investment, please refer to:
https://ensmart.ai/blog/building-management-software-complete-guide-with-real-roi-data
A Simple BMS Analysis Framework
The entire logic can be condensed into one workflow:
BMS Data → Analysis → Discovery → Interpretation → Action
Take AHU01 as an example.
Data on cooling valve status, temperature, setpoint, and operating hours collected by the BMS is analyzed through valve saturation and temperature deviation assessments.
This leads to the conclusion that there may be insufficient cooling capacity.
The basis for this conclusion is that the valve stays at a continuously high opening level, but the unit still never reaches the set temperature.
Action
Inspect the refrigeration coils, chilled water flow rate, valves, and actuators.
This is exactly the direction the industry is transforming toward:
from simple monitoring,
to operational intelligence.
Questions Engineers Should Ask BMS Suppliers
The next time you see a very high energy savings rate, do not stop at that number alone.
Please ask follow-up questions:
What data generated this result?
Which BMS points were used?
What calculation formula was adopted?
Does it align with general engineering logic?
What baseline was selected?
Which operating condition was it compared against?
Is this data a measured value or a modeled value?
This distinction is critically important.
Can this calculation process be replicated?
If it can, the difficulty of verifying the result will be greatly reduced.
What limitations does this result have?
A reliable platform should be able to answer this question clearly.
The Real Goal Is Never to Add More Dashboards
Buildings already generate massive volumes of data, and the core challenge is to turn this data into usable information.
The operation and maintenance team ultimately needs to answer four questions:
What is happening right now?
Why is it happening?
What impact does it cause?
What should be checked next?
This is exactly where the value of BMS analytics lies.
Our goal is not to create another dashboard stacked with charts, but to support better engineering decisions.
BMS data → more robust analytics → more evidence-based decisions
Learn More
What is a Building Management System (BMS)?
https://ensmart.ai/blog/what-is-a-building-management-system-bms
BMS/IBMS Platforms
Building Management Software: A Complete Guide with Real ROI Data
https://ensmart.ai/blog/building-management-software-complete-guide-with-real-roi-data
Top comments (0)