What should be in your BMS O&M manual?

When a BMS engineer arrives at a site for the first time, the first thing they ask for is the documentation. If it’s complete and up to date, they can start fixing things straight away. If it’s missing, every fault starts with hours of detective work, and the client pays for every one of those hours.

Here’s what a decent BMS operation and maintenance (O&M) package should contain, and why it’s worth chasing at handover.

Control strategies (descriptions of operation)

A written description of how each item of plant is supposed to work: when it runs, what it controls to, which interlocks and safeties apply, and what happens on a fault. This is the single most important document. Without it, nobody can tell whether the BMS is doing the right thing or just doing something.

Points schedule

A list of every point in the system: name, type (input or output, analogue or digital), what it’s connected to, where it is, its range and its controller address. It’s what an engineer uses to find their way round the system and to check sensor readings against reality.

Schematics and wiring diagrams

plant schematics showing each sensor, valve and damper on the mechanical plant
panel wiring diagrams, as-built, with terminal numbers matching the labels in the panel
cable schedules listing every cable, its type, route and the devices at each end

As-built is the key word. Design drawings that were never updated after installation can be worse than nothing.

Network documentation

a network drawing showing controllers, routers, switches and how they connect
an IP address schedule
BACnet device instances and network numbers (see duplicate device instances for why that matters)
MS/TP and Modbus trunk layouts, with MAC addresses, baud rates and termination points
any integration points lists for third-party systems

Software, backups and licences

a current backup of the supervisor and all controller programs, stored somewhere other than the BMS itself
software versions and licence details, including when support or maintenance agreements expire
the programming tools needed to modify the system, or at least details of what’s needed and who holds them

Missing licences or tools can tie a building to one contractor for years, so check what you’re actually being handed.

Access and passwords

A secure record of administrator credentials and user accounts, held by the building owner rather than only by the contractor. Combine it with a clear policy on who has access and how it’s removed when people leave; see BMS cyber security basics.

Commissioning and test records

Completed point-to-point checks, functional test sheets, witnessing records, loop tuning settings, sensor calibration results and electrical test certificates. They prove the system worked at handover, and they’re a baseline to compare against when something goes wrong later. See BMS commissioning step by step.

Equipment data

Datasheets and manuals for controllers, sensors, actuators, valves and any other devices installed, with model numbers. They make replacement parts and like-for-like swaps much easier.

Operating and maintenance instructions

how to use the front end: graphics, alarms, schedules and trends
recommended maintenance tasks and frequencies, for example sensor checks, actuator checks and backups
who to contact for support

Training for the site team at handover should match these instructions.

Keep it alive

The O&M manual isn’t a one-off. Every time the system is changed, whether that’s a new controller, a modified strategy or a replaced sensor, the documents and backups should be updated too. A simple rule in the maintenance contract, “no change is complete until the documentation and backup are updated”, stops the slow decline that leaves so many sites with documents nobody trusts.

If you’re taking over a site with poor documentation

It’s worth paying to recreate the essentials: a current backup, a points schedule from the live system, and written control strategies for the main plant. It’s a one-off cost that pays for itself in faster fault-finding and fewer arguments about what the system is supposed to do.