Sh*tty Data In ≠ Sh*tty Data Out
April 28, 2021
When building owners invest in Fault Detection and Diagnostics (FDD) Software, they expect results. But those results don’t come if the FDD rules produce false faults due to messy data.
Real data from real buildings is imperfect at best. Data points are missing, mislabeled, or unlabeled. Data points that mean one thing on one piece of equipment mean something else on another. Data points have erroneous, missing, or unreliable data.
For many FDD tools on the market, data messiness is the Achilles heel. If you’re developing fault rules from scratch, you’ll quickly learn you can end up spending more time fixing messy data than producing faults that lead to corrective actions.
And that’s just the first “D” in FDD: detection. When it comes to the second “D,” diagnosis, messy data can wreak similar havoc when trying to identify the root cause of a true positive fault.
How can we ensure FDD is producing actionable information an operations and mechanical team can trust?
Let’s unpack the traditional ways to solve this problem and how the Clockworks approach is different.
Defining Messy Data
Messy data typically presents itself in one of two ways: False Positives and False Negatives.
False Positives occur when an FDD tool produces a fault based on erroneous data and/or an incorrect understanding of equipment operation:
- Erroneous Data: Bad data is simple enough to understand. If a sensor drifts out of calibration, or loses communication with a controller, it will produce erroneous values which need to be excluded from the analysis. You’ll quickly lose the trust of the facilities management team when you trigger a ‘Hot Space Temperature’ fault only to realize the space temperature sensor is reading an erroneous value of 212°F.
- Incorrect Understanding of Equipment Operation. Incorrect understanding of equipment operation is more nuanced and difficult to account for in the fault rule configuration. Every mode of operation for each piece of equipment needs to be accounted for to accurately model ideal vs. actual performance. For example, the fault rules should account for a dehumidification sequence of an Air Handling Unit to avoid triggering a “Simultaneous Heating and Cooling” fault. When in reality, the unit is cooling/reheating to dehumidify the air.
False Negatives occur when an FDD tool doesn’t produce a fault when actual performance issues occurred. These are far more elusive, as it is almost impossible to validate the absence of a fault without performing an extensive manual analysis. Yet inevitably a facility management team will experience an equipment failure and look back at their FDD tool wondering why there were no faults before, during, or after the event.
DOWNLOAD NOW: The Definitive Guide to Building Analytics
To illustrate, consider a simple example of an FDD rule that checks to see whether an air handling unit’s hot water valve is leaking. The logic underpinning the rule requires a hot water discharge air temperature (HW DAT), Fan Status, and Mixed Air Temperature (MAT):
A False Positive would be produced if the Hot Water Discharge Air Temperature (HW DAT) sensor became disconnected from the controller and began producing an erroneous reading of 212°F. A False Negative would occur if the fault rule did not account for a unique configuration of an AHU controller which may not have a HW DAT sensor point.
REQUEST A DEMO OF CLOCKWORKS ANALYTICS FDD SOFTWARE
Ways to Deal With Messy Data
Since FDD has been around for over a decade, the industry has developed innovative solutions to this complex problem.
First, some recommend cleaning the data up front before doing FDD.
They commonly say, “Sh*tty data in, sh*tty data out”.
They will delay the FDD deployment and instead propose a retrocommissioning effort or controls upgrade to get the data in the right state. Unfortunately, this can result in extra capital expense, delayed benefits, and uncertain return on the investment. Ultimately, you may still find the data is messy and one of the following two options will still be needed.
The second approach is for building owners to hire service providers to adapt the FDD product to the real data and provide custom rules and manual diagnosis. This, too, has major downsides. The challenge is managing this complexity across a portfolio, and the dependency on the programmer(s) that built the custom code to adapt the algorithms to the data.
In a facilities management environment that tends to change frequently, one should question the scalability and maintenance challenges of deploying custom code on a one-off basis for each unique system configuration and sequence of operation. This lack of scalability, maintainability, and programmer dependency result in extra costs.
Luckily, Clockworks offers a third option: build adaptability into the FDD tool.
Clockworks Adapts to the Data
Unlike most FDD tools, Clockworks is built to accept data exactly as it is and provide whatever insights can be gained. In other words, Clockworks adapts to the best available information.
To explain, let’s return to the above example of a rule that checks whether a HW valve is leaking. But this time let’s look at the various ways a FDD should accommodate bad data when running an analysis.
Each analysis begins by validating if the data from each equipment is accurate and reliable to be used to produce a fault output. This includes checking each data point for up-to-date and accurate readings to support the analysis.
If the analysis requires knowing whether the unit is operating, Clockworks needs to account for all possible methods of determining the “proven on” status. This can vary widely across different controller configurations: AHU Status, AHU Command, Fan Status, Fan Speed, Supply Airflow, Discharge Pressure, etc.
And lastly, Clockworks needs to account for different methods of checking for a leaking Hot Water valve. If a Hot Water Discharge Air Temperature (HW DAT) point is available, the analysis can look for times when the hot water valve is closed but a temperature rise is detected across the coil. If a HW DAT point is not available, the analysis can look for times when no heating/cooling is occurring but a temperature rise is detected between the Mixed Air Temperature and Supply Air Temperature.
As Jaime described last week, there are a myriad of ways Clockworks adapts to the real world complexity of building systems. In order for FDD to be scalable, repeatable, and maintainable across a portfolio of diverse systems, the algorithms must dynamically accept the best available information for use in these analyses and checks.
Stay tuned for next week, where we’ll outline all the components that allow Clockworks’ information model to accomplish this. We’ll show why it’s the most robust in the business.
