How engineering firms run RCx, MBCx and data-driven maintenance on FDD

Ask a building performance engineer where their week went and the answer is rarely "fixing things". It went to investigation - pulling trend logs, chasing point names across three vendors, walking plant, reverse-engineering what a BMS has been quietly doing wrong for years. The findings are real. Finding them by hand is what consumes the margin.

That is the problem fault detection and diagnostics solves for service firms, and it is a different problem from the one it solves for building owners. An owner wants to know what is wrong in their building. A retro-commissioning firm, an engineering consultancy or a mechanical contractor wants to know how to deliver more engagements, more profitably, without hiring an engineer for every new site.

This is the practitioner's version of that answer: how the investigation phase changes, how the three main service plays work on live data, and what has to be true operationally for any of it to hold.

The assurance gap that makes the manual model unaffordable

Take one 200,000 sq ft office. Checking every system properly - every air handling unit, every terminal unit, every schedule, every valve - takes more than 1,000 engineering hours a year. A dispatch-based service model delivers roughly 300 of them. The other 700 do not happen, not because engineers are not good, but because the checking work is larger than any roster.

The consequence is measurable. Researchers at Lawrence Berkeley National Laboratory analysed multi-year monitoring data from more than 60,000 pieces of HVAC equipment and found that on any given day, 40% of air handling units carry a reported fault - many persisting for more than a fifth of the monitored period. Those are not breakdowns. They are the quiet faults that keep tenants comfortable while wasting energy, and they survive precisely because nobody has the hours to look.

Continuous fault detection and diagnostics closes that gap by running the checks every 15 minutes on every point, and handing your team a ranked, diagnosed fault list instead of a stack of trend logs. The hours do not disappear. They redeploy - from looking for problems to fixing them.

Detection is not delivery

Here is where most analytics programmes stall, and it matters more for service firms than for anyone else. A platform that stops at detection produces a list. A list is not a deliverable, and it is certainly not a retainer.

The engagement only closes when every fault travels the full path:

1. Detected - a rule fires the moment the data shows it, not when someone next visits.
2. Diagnosed and prioritised - ranked by energy cost, comfort impact and equipment risk, with probable cause attached, so scope conversations rest on the client's own data.
3. Verified in the field - an engineer takes the alert to the plant room and confirms or dismisses it. Engineering judgement stays with the engineer.
4. Evidenced - readings and photographs posted into the action from the plant room, so the record is complete the moment the work is.
5. Rectified - into the remedial workflow with a named owner and a service level, tracked to close-out.
6. Verified at the meter - the platform confirms the fix landed and held. If a saving does not appear at the meter, you see that too.

That last step is the one that separates a report from a retainer. The difference between "we recommended 31 actions" and "we resolved 31 actions, and here is the verified result of each" is the entire commercial argument for renewal.

It is also why the verification layer needs to be independent of the party doing the work. A contractor closing out their own faults in their own system is marking their own homework. For a good service firm that independence is an advantage, not a threat: verified data proves the value of the work in a way a service report never could.

What that looks like on a real site

The clearest example we have from the last year came from a room that started out sceptical. During an engineering team's first training session on the platform, an alert surfaced on a full fresh air handling unit: chilled water valve commanded to 0%, supply air running more than 3°C below outside air. Two of the engineers who had pushed back hardest took the alert to the plant room, measured the actuator, and found the valve stem sitting 40% open against a 0% command.

Ninety-eight minutes after the demo began, the diagnosis and photographic evidence were on the record, and the fault was in the remedial workflow. The full story is here: sceptical engineers confirm a £25,000 fault in 98 minutes. The point is not the speed. It is that adoption came from the engineers who tested it themselves, and that the evidence went on the record without anyone chasing it.

Play one: retro-commissioning, with the investigation already done

Retro-commissioning works, and it has a well-documented weakness: the investigation phase eats the budget, and the savings start decaying the day the engagement closes.

On an FDD platform the investigation arrives as an answer sheet. The platform connects to the client's existing BMS - any vendor, including legacy and serial estates - and returns a ranked, diagnosed fault list, typically two to eight weeks from data access depending on BMS accessibility and point naming quality. Subsequent buildings in a portfolio connect faster, because rules, tagging conventions and integration patterns carry across.

Three practical notes from delivery:

• Old BMS estates are the normal case, not the exception. Serial networks are bridged with a router, closed systems are reached through a gateway or vendor interface, and read-only access means no control-system risk. An old BMS usually means more findings, not fewer.
• Cross-vendor from day one. One fault list across Siemens, Schneider, Honeywell, Trend and mixed legacy plant - no controller replacement, no per-site rebuild.
• Pre-visit triage changes the site day. Engineers arrive with confirmed targets rather than a blank clipboard, so site hours go to verification and resolution instead of discovery.

The cycle compresses accordingly. A manual RCx project, from kickoff to verified savings, commonly runs 12 to 18 months: site visits, data collection, analysis, reporting, implementation, then measurement. The same project on a continuous platform clears in three to five months, because investigation never stops and verification happens at the meter as fixes land. For a firm, that is the same engineers running three to four times the revenue or incentive cycles per year on the same client portfolio.

In many US utility territories that arithmetic gets better still. Programmes commonly rebate a large share of implementation cost and pay per-kWh incentives on verified savings, and continuous monitoring strengthens both sides of the claim - the savings are measured at the meter, and the evidence pack for the programme administrator assembles itself. In Europe the same economics arrive through a different door: energy performance regulation, ESG reporting obligations and green financing covenants all reward evidenced performance over asserted performance.

Play two: MBCx, and the renewal problem nobody names

Every RCx engineer has seen a successful project drift most of the way back within eighteen months. Overrides accumulate, schedules creep, setpoints wander, sensors fail quietly. Monitoring-based commissioning exists because drift is not an anomaly; it is the default behaviour of buildings.

The commercial problem is sharper than the technical one. A Building Commissioning Association market survey put the industry's MBCx contract renewal rate at roughly 10%. Nine contracts in ten do not survive to year two - usually because year two looks like an invoice with no new story. Spreadsheet-driven monitoring cannot keep generating visible value at a cost that leaves margin.

System-driven MBCx changes both the delivery economics and the renewal conversation:

• Drift is caught as it starts, not a quarter later, because detection runs continuously across every point.
• The quarterly statement assembles itself from live meter data rather than being rebuilt in Excel each period.
• The same team covers many more sites, because manual MBCx scales by hiring and system MBCx scales by software.

The benchmark for what the discipline delivers is solid: LBNL's survey of 26 organisations running continuous fault detection across 550 buildings found median energy savings of 8%. The document that renews the contract is short, and it is always the same four things - verified savings to date, actions closed and in flight, comfort trend against target, and ratings position re-estimated from actual metered data.

Play three: data-driven maintenance for BMS and mechanical contractors

The calendar does not know what is broken. Scheduled maintenance sends technicians to healthy equipment on a fixed cycle while real faults sit undiscovered between visits, and roughly 80% of standard maintenance task time goes to looking for problems rather than fixing them. The technician shortage makes that arithmetic worse every year.

Data-driven maintenance inverts the model: the building's own data decides where the hours go. For the engineers, that means BMS alarm floods become a prioritised, diagnosed action list; work orders arrive with the fault, probable cause and trend data attached; and an engineer who could properly cover around five large sites can cover several times that when the checking runs in software.

For the business, the billable logic is direct. Continuous detection surfaces the remediation work the team never had time to find. Service contracts anchored on a monitoring platform are renewed on evidence rather than habit. Visit fees stay; system fees and remediation work add to them, on buildings you already maintain.

There is a knowledge argument too. A no-code rules engine lets a firm capture its best engineer's diagnostic instincts as repeatable rules that run on every site, every 15 minutes. Institutional knowledge stops retiring when people do.

What has to be true operationally

None of the three plays work without four unglamorous things in place. In our experience these, not the analytics, decide whether a programme delivers.

1. Someone owns the list. A named individual with time in their week and a fixed review cadence. The most common failure mode is not technical: faults arrive, nobody owns triage, the list grows, people stop looking.
2. The maintenance contract covers analytics-driven work. If resolving a fault needs a contractor who is not contracted to respond to analytics-generated tasks, the diagnosis was wasted. This is a variation, not a renegotiation, but it needs doing before the backlog builds.
3. Verification is contractual, not optional. Without confirming faults cleared in the data, you cannot distinguish a working programme from an ignored one, and every savings claim rests on assumption.
4. The client's IT team is engaged in week one. Building owner IT teams push back on new platforms, and they should. Have the answers ready: read-only access with no control capability, an edge device with documented network architecture, and independent third-party security testing. Bring the security documentation to the first conversation, not the third.

What it looks like when it works

Aero Performance Group, a division of the Hill Group, has been one of the leading RCx and MBCx providers in its utility programme since the programme began, saving clients more than $26.5 million in energy costs. Before adopting a platform, its engineers reviewed BMS data manually. Running commissioning across its US portfolio from one platform, Aero grew its active project portfolio 50% without additional resourcing, and now verifies around 6 million kWh of energy-saving incentives a year for clients.

If you want the practitioner conversation rather than the vendor version, Aero's commissioning manager talks through how FDD changed their RCx and MBCx delivery in this joint webinar with the Smart Buildings Academy.

The build-versus-buy question

Most firms that get this far ask whether to build the capability or licence it. The honest framing is that the analytics engine is the least differentiated part of the offer. What clients buy from an engineering firm is judgement, delivery capacity and accountability - and those are exactly the things a platform cannot supply. We have written about how to weigh that decision, including what to look for and what to be sceptical of, in partner, tool or competitor: how engineering firms should choose a building analytics platform.

The bottom line

The manual model was never limited by engineering skill. It was limited by hours, and by the fact that the investigation phase - the least differentiated work an engineering firm does - consumed most of them.

Continuous fault detection moves those hours to the work clients actually value, compresses the RCx cycle from years to months, and turns MBCx from an invoice into a scoreboard. The firms that get there share one habit, and it has nothing to do with the software: they close the loop, and they check that the fix held.

Frequently asked questions

How does FDD change a retro-commissioning engagement?

It removes most of the investigation phase. Instead of weeks of manual trend-log analysis, the platform connects to the existing BMS and returns a ranked, diagnosed fault list, typically two to eight weeks from data access. Engineers arrive on site with confirmed targets, so site hours go to verification and resolution rather than discovery. The full cycle from project start to verified savings commonly compresses from 12 to 18 months down to three to five.

What is the difference between RCx and MBCx for a service firm?

Retro-commissioning is a fixed-term project that returns systems to intended performance; monitoring-based commissioning leaves the analytics running afterwards so drift is caught as it appears. Commercially, RCx is project revenue and MBCx is recurring revenue. The strongest model runs RCx first to recover performance, then MBCx permanently to hold it, which is why many firms now sell them as a single continuous engagement.

Why do most MBCx contracts fail to renew?

A Building Commissioning Association market survey put the industry renewal rate at roughly 10%. The usual cause is that year two arrives with an invoice and no new story: spreadsheet-driven monitoring cannot keep surfacing visible value at a cost that leaves margin. Renewal follows from a short quarterly statement showing verified savings, actions closed, comfort trend and ratings position, generated from live data rather than rebuilt by hand.

Can FDD work on an old or mixed-vendor BMS estate?

Almost always, and it is the normal case rather than the difficult one. Serial networks are bridged with a router, closed systems are reached through a gateway or vendor interface, and equipment outside the BMS can be covered with sensors. A single fault list can span Siemens, Schneider, Honeywell, Trend and mixed legacy plant without controller replacement. An older BMS usually means more findings, not fewer.

How many buildings can one engineer cover with continuous monitoring?

Under a manual model, an engineer can properly cover around five large sites. With continuous monitoring doing the routine checking and work arriving pre-diagnosed, that figure multiplies several times over. The constraint shifts from investigation capacity to resolution capacity, which is the capacity a firm can actually sell.

Does the client need to buy new sensors or replace the BMS?

Usually not. Most value comes from data the BMS already collects, accessed read-only with no control capability. Targeted sensor additions such as valve position feedback and sub-metering on major plant extend what can be diagnosed and are best decided after the first round of findings rather than as a precondition.