Yes — you can add AI-driven fault detection to an existing Trend IQ system without ripping out the controllers. The analytics layer sits above the BMS, pulling point data over BACnet or the Trend network, then running rules and pattern analysis to flag plant operating outside expected parameters. The IQ controllers keep running; the intelligence is added on top.
AI fault detection, or FDD (fault detection and diagnostics), is the process of automatically identifying when building plant is operating outside expected parameters — and, ideally, telling you why. Most buildings already generate the data needed to do this. The Trend IQ controllers in your plant rooms have been logging space temperatures, valve positions, fan status and setpoints for years. The problem is nobody is looking at that data until a tenant complains or a piece of plant fails. That is the gap analytics fills, and the good news is you rarely need new controllers to close it.
We get asked this constantly by FM teams and building owners sitting on a Trend estate that works, more or less, but burns energy and throws the occasional alarm nobody trusts. They have heard the words "AI", "machine learning" and "digital twin" thrown around by software vendors, and they want to know what is real, what it costs in disruption, and whether their existing kit can take it. Here is the honest version from the plant room.
Strip away the marketing and FDD is mostly pattern analysis on top of point data. The software ingests your BMS points — sensor readings, setpoints, command states, runtime hours — at regular intervals, then compares what the plant is doing against what it should be doing. Some of that comparison is simple rule logic: if the heating valve is commanded shut but the flow temperature is still climbing, something is passing. If a fan is commanded on but the differential pressure across the filter reads zero, the belt has likely gone or the status is lying.
The "AI" part comes in when the software learns a building's normal behaviour over time and starts spotting drift that no fixed rule would catch — a chiller whose approach temperature is creeping up week on week, an AHU that takes longer to reach setpoint each morning, a zone that has quietly started fighting itself because someone left a manual override in. These are the faults that never trip an alarm but quietly cost you money and comfort. Properly applied, FDD does what a very good, very patient commissioning engineer would do if they could watch every point on the system, all day, every day.
Crucially, none of this requires the analytics to control anything. It reads, it analyses, it reports. The Trend IQ controllers stay in charge of the plant. That separation is what makes it safe to bolt onto a live building.
In almost every case, yes. The Trend IQ range — IQ3, IQ4, and the older IQ2 still soldiering on in plenty of plant rooms — exposes its data in ways that modern analytics can read. IQ4 controllers speak BACnet/IP natively, which is the cleanest route: the analytics platform connects as a BACnet client and subscribes to the points it needs. BACnet is standardised under BS EN ISO 16484-5 (the same standard as ASHRAE 135), which is precisely why a third-party analytics tool can talk to Trend hardware without a proprietary handshake.
Older IQ controllers on a Trend current-loop or Ethernet network typically need a supervisor or a protocol gateway in between. A Trend 963 supervisor, or an IQVISION front end, can act as the data source, and many analytics platforms will pull from it directly or via a BACnet conversion at the network level. The point is that the controllers themselves do not change. You are adding a read-only data tap, not re-engineering the control strategy.
Where it does get involved is point availability and naming. A controller that was set up fifteen years ago might log a space temperature but not the valve position you need to diagnose a passing valve. Sometimes the data is there but buried under cryptic point names that make automated rules impossible until someone tidies them up. This is the unglamorous reality of FDD on legacy estates: the controllers can take it, but the data layer underneath often needs a proper survey first.
The most common failure is treating FDD as a software purchase rather than an engineering exercise. A vendor connects the platform, switches on a generic rule library, and the building owner is hit with several hundred "faults" on day one — most of which are not faults at all. They are the analytics misreading a point, flagging plant that is off out of hours as if it were broken, or applying a rule that does not match how that particular AHU was designed to run. Trust evaporates within a week and the dashboard never gets opened again.
The second problem is polling the BMS network too hard. If the analytics platform hammers a Trend network with aggressive subscriptions, you can load the supervisor, slow down graphics, and in bad cases cause comms dropouts that look like controller faults. The network was sized for control traffic, not for a data-hungry analytics engine pulling thousands of points every few seconds. This needs designing in, not assuming.
Then there is the data integrity issue. FDD is only as good as the sensors feeding it. A space temperature sensor reading two degrees high, a flow sensor that was never commissioned properly, a status point hard-wired to always read "running" — feed any of those into clever analytics and you get confident, well-presented nonsense. We have walked into buildings where the analytics was blaming a chiller for a fault that was actually a duff sensor the FDD had taken at face value. Garbage in, garbage out applies just as hard to AI as to anything else.
We'll assess your controls and provide a detailed quotation.
Good FDD starts with a survey, not a login. Before any analytics goes live, you want a point-by-point check of what data each IQ controller exposes, whether the sensors feeding those points are trustworthy, and whether the network can carry the extra read traffic. CIBSE Guide H, the reference for building control systems design, is clear that a control system is only as effective as the quality of its sensing and its commissioning — FDD does not override that, it depends on it.
Good FDD is also tuned to the building. The rule set should reflect how your specific AHUs, FCUs, chillers and boilers were designed to operate — including their real time schedules and out-of-hours behaviour — so the platform is not screaming about plant that is simply doing what it was told. Faults should be prioritised by cost and comfort impact, so the FM team sees the three things worth fixing this week rather than three hundred noise items. And the output needs to land with the people who can act on it: a clear diagnosis, the affected plant, and ideally an estimate of what the fault is costing in energy or comfort terms.
Done properly, this ties directly into energy compliance. The MEES Regulations 2015 (as amended) set a minimum EPC rating of E now, tightening through the decade, and CIBSE TM54 covers evaluating a building's actual operational energy performance rather than its design intent. FDD is one of the few tools that exposes the gap between the two — the failed economiser, the simultaneous heating and cooling, the optimum start that never got commissioned — which is exactly the low-cost, high-impact stuff that moves an EPC and cuts a bill without major capital works.
If you are running a Trend IQ estate of any reasonable size — a multi-floor office, a campus, a portfolio of buildings — and you are relying on alarms plus the occasional reactive call-out, you are almost certainly leaving energy and comfort on the table. Alarms tell you when something has already failed. FDD tells you when something is starting to fail, or quietly running inefficiently, while there is still time to act cheaply. That difference is the whole argument.
It is especially worth doing alongside other works. If you are already upgrading controllers, refreshing a supervisor, or carrying out a retrofit, that is the natural moment to sort out point naming, fix dud sensors, and design the analytics layer in — because the survey work overlaps. Adding FDD as a standalone afterthought is possible, but you lose that efficiency. It is also the right call if you are under MEES pressure or chasing a net-zero target and need to prove operational performance, not just design ratings.
What it is not is a silver bullet you can buy and forget. The value comes from the engineering underneath — clean data, tuned rules, and someone who understands both Trend and the building responding to what it finds.
You do not need to rip out your Trend IQ controllers to get AI fault detection. The analytics sits above the BMS, reads the data your controllers already generate, and flags plant drifting out of spec before it becomes a failure or a tenant complaint. The controllers stay in charge; the intelligence is added on top. The catch is that FDD lives or dies on the quality of the underlying data — the sensors, the point naming, the network headroom — so a proper survey beats a quick software switch-on every time.
If you are sitting on a Trend estate and want to know what your existing system can actually support, that is exactly the kind of thing we survey and scope in plant rooms every week. Get in touch or request a quote and we will give you a straight answer on what is worth doing and what is not.
Specialist BMS installation, commissioning, and maintenance across London and the South East. SafeContractor Approved, BCIA Member.
Our team of building automation specialists is ready to help you optimise your building's performance and efficiency.
Get in Touch
