Fault detection and diagnostics: turning building automation data into work orders

Reference article · 5 min read

A building automation system records supply air temperatures, valve positions, damper commands, fan status, and setpoints continuously. In most agency portfolios nobody reads that record unless a tenant calls about a cold office. Fault detection and diagnostics software, usually shortened to FDD, reads the same trend data on a schedule, applies rules to it, and lists equipment that is operating in a way it should not be.

It helps to be blunt about what that buys. FDD is not an energy savings product. It is a work identification product. It surfaces problems that were already costing money and comfort, and savings arrive only when someone changes something in the field or in the control program. An agency that buys the analytics without staffing the follow-through ends up with a good dashboard and the buildings it already had.

What the analytics actually find

First year findings are unglamorous and repetitive. These failures hide well because the building still delivers acceptable comfort.

• Simultaneous heating and cooling. A reheat valve leaking through while the air handler delivers cold air, or a terminal box heating a zone that is also being cooled. Expensive, and invisible without trend data.
• Economizer and damper faults. Outside air dampers stuck open in cold weather, stuck closed in mild weather, or linkage that has failed so commanded and actual position disagree.
• Overrides left in place. Points left in hand after a service call, or a loop disabled while responding to a complaint and never re-enabled.
• Schedules in occupied mode. Equipment running nights, weekends, and holidays because a schedule was changed for an event, or the holiday calendar was never maintained.
• Sensor problems. Flatlined points, readings outside a plausible range, and sensors that disagree with their neighbors. Every control decision downstream of a bad sensor is wrong.
• Resets that never move. Static pressure, supply air, or hot water resets that were configured but sit at one value, and equipment short cycling against its own controls.

What the data has to look like

Analytics can only see what the BAS stores, and this is where most projects stall.

• Point naming and tagging. The software has to know that a point is the discharge air temperature of a specific unit serving specific zones. Naming is usually inconsistent across buildings and controls contractors. Open tagging conventions and ontologies such as Project Haystack and Brick Schema exist to make this portable, and ASHRAE has work underway on a semantic data model for building systems. Confirm a standard's status before naming it in a specification.
• Trend intervals and retention. Many rules work at fifteen minute intervals. Short cycling and control hunting need faster sampling. Set retention deliberately: rules that compare one season to another need history the historian may not be keeping.
• Complete trends. A rule that needs a command, a feedback, and a temperature will not run when only two are trended. Expect an early phase of turning on trends and expanding historian capacity.
• Metering. Whole building interval data, from the utility or from submeters, lets you rank faults by plausible cost instead of by rule severity, and gives you something to check afterward.

Triage is the program

Whether this investment pays off depends mostly on whether a named person sits down each week, works the fault list, and turns real findings into work orders. Budget that time explicitly rather than assuming an existing engineer will absorb it.

1. Sort new faults by building and by likely impact.
2. Dismiss false positives, then tune the rule or the point mapping so the same one does not return.
3. Convert real faults into work orders with the trend chart attached, so the technician sees the evidence.
4. Track closure against the fault, and reopen it if the fault comes back.

Automatic work order creation sounds attractive and usually is not, at least early on. Unfiltered faults flooding the maintenance queue teach crews to ignore the source. Automate only the fault types you have learned to trust.

What to ask vendors and put in the contract

• Who maps the points, and what does remapping cost? Mapping is the real labor here. Ask whether it is fixed price, who owns the mapping, and what happens when a building gets a new controls contractor.
• Is the rule library visible and editable? You should be able to read the logic behind a fault, adjust thresholds, and suppress rules that do not fit your equipment.
• Read only by default. Decide deliberately whether the platform may write back to the BAS, and have IT and security staff review network access, hosting, and authentication before award.
• Data ownership and exit. Require trend data, point mappings, and fault history to be exportable in a documented format during the term and at termination.
• Licensing basis. Per point, per building, and per square foot pricing behave differently as a portfolio grows. Ask what renewal costs and what adding buildings does to the price.
• Deliverables that are not software. Require training for triage staff, written documentation of each rule deployed, and a support path when a rule misfires.

How to start

Pick a few buildings where BAS coverage is good and the complaint history is real. Inventory the available points and trends before procurement, so you can price the trending work separately. Run a limited term pilot, staff the weekly triage from the first week, and judge the result by faults verified and work orders closed, not by the dashboard. Local benchmarking ordinances and utility efficiency programs sometimes support this work, but terms and eligibility change, so confirm current rules with the administering agency.

HQT works with state and local agencies on data integration and analytics, including the data quality and workflow plumbing that decides whether analytics turn into completed work.

Frequently asked questions