It Arrives Knowing Your Equipment: Inside the TwinWorX Fault Library
Most fault detection starts with an empty rule engine and a text box. Somebody has to write the rules before the system finds anything, and the somebody is usually a consultant on a change order.
TwinWorX does not start there. It ships with a library of more than 1,000 fault rule templates covering more than 120 classes of equipment, and the coverage goes well past the air handlers and chillers where most fault detection stops.
What the library covers
Air and water side: air handlers, VAV boxes, fan coils, chillers and heat recovery, boilers, cooling towers, pumps, heat exchangers, VRF.
Steam and electrical: steam plant, condensate and traps, pressure-reducing stations, switchgear, transformers, UPS and generators, fuel oil, and meters of every kind.
Medical and laboratory: medical air, medical gas and vacuum, anaesthetic gas scavenging, MRI cooling and helium quench, fume hoods, biological safety cabinets, RO water.
Critical spaces: operating rooms, isolation rooms, pharmacy clean rooms, and the pressure relationships between them.
And the rest of a working estate: kitchen, sterilizer, decontamination, welding and paint booth exhaust, sumps, lighting, lifts and escalators, EV chargers.
A hospital, a campus, and an industrial site draw on different parts of the same library. Switchgear, transformers, UPS, and generators are not building equipment, and neither are most of the medical and laboratory classes. Which parts apply to you is a scoping decision, not a different product. The coverage is the point, more than the count.
How a template works
Each template carries a documented algorithm, the conditions that raise it, the period it must hold for, the category it reports under, and the points it depends on.
The variable names are generic and role-based. A template refers to "supply air temperature" and "cooling valve command," not to one vendor's point names, so it works against any controller, and the mapping to your tags happens once, at deployment. One template applied across fifty air handlers is fifty live rules and still one thing to maintain. Adding a building means adding its assets to the list, not rewriting the library.
Rules can reason over history as well as live values: an average, a minimum, a standard deviation, or a rate of change, across minutes, hours, or months. A fault has to hold true for a set number of consecutive checks before it is raised, and hold false before it clears, so a single bad sample does not produce a phantom fault at three in the morning.
Every rule also carries what to do about the fault: a list of probable causes in priority order, and the first-line checks worth making, written by the engineer who built the rule. Your team can rewrite both to match your own procedures and equipment without touching the logic that detects the fault. The technician gets the investigation steps your organization would give them.
Extending it without a change order
The library is where you start. What you add to it should not need a vendor release.
An engineer describes the fault in plain English and the platform drafts a complete rule. The draft is constrained by the model, so it can only reference properties the asset actually has. A rule that asks for a damper position on equipment with no damper does not get written.
Then every rule, drafted or written by hand, runs against your historical data before it goes live. Months of operation are evaluated in seconds, so you can see that it catches the fault you meant and nothing else before it reaches anyone's queue. The engineer approving it approves evidence, not a plausible expression. The language model helps write the rule. It does not get to skip the checks, and it never acts on the building.
What it is not
The library is a starting point, not a finished deployment. Three things are worth stating plainly.
Which rules apply is decided with you during scoping. A university does not need operating room pressure rules, and a commercial office does not need RO water.
Timing values are tuned to your site, because sensor polling and equipment behaviour differ from one building to the next.
And rules that depend on timing need two to three months of normal operation before they are fully enabled. That is deliberate. Nuisance alerts in the first month cost you the operators' trust, and a fault detection system the operators have stopped trusting is one they switch off.
What the library buys you is a Stage 2 that is useful early. You are tuning and extending something that already understands your plant, not building it from scratch.
Bring your worst recurring fault.
Thirty minutes with one of our engineers, and we will show you how the platform would find it, trace it, and rank it.
