Typical symptoms
- Offline devices, drift, recurring alarms and overrides accumulate
- Graphics remain while data, programs and field equipment diverge
- Individual faults are closed without backups or continued follow-up
Where these symptoms may come from
Equipment, records and use all change
Sensors, actuators, controllers, schedules and building use change at different times; without records and ownership, temporary fixes gradually erode capability.
Diagnostic sequence
- Baseline controllers, networks, critical points, alarms and overrides
- Prioritise plant, air systems and important zones
- Work from field evidence through points, programs, communications and platform
- Set recovery priority by continuity, safety impact and affected scope
Safe checks you can prepare first
These checks collect evidence without bypassing interlocks, forcing outputs or changing critical protection.
- Preserve current programs, databases, graphics and key parameters
- Record the reason, owner and recovery condition for overrides
- Compare selected platform values with field evidence
- List recurring alarms and offline devices
The symptom: automation disappears one exception at a time
BMS degradation is rarely one total failure. A few drifting sensors, stuck actuators, offline controllers, old schedules and temporary overrides accumulate until operators manage the building device by device. The platform still exists, but its automatic behavior no longer follows current use.
Trust then falls. If a room value does not match field conditions, a command produces no feedback or alarms recur without resolution, operators turn to manual control. Manual intervention may be necessary, but without a reason, owner and recovery condition it becomes another permanent exception.
Common causes across five layers
Field equipment changes first: sensors drift, actuators bind, selectors move and feedback stops representing the device. Point mapping and communications may remain online despite incorrect values. Programs, setpoints and alarms also change through unrecorded temporary work.
Building use evolves as equipment is replaced, spaces change and operating hours move. If points, sequences, graphics and records do not change with it, the delivered control assumptions become obsolete. Missing ownership and backups then make every recurring fault a new investigation.
Diagnose from the field outward
Create a baseline of controller and network health, critical panel modes, forced points, major alarms, schedules and abnormal trends. Focus first on central plants, air systems, pumps, ventilation and important terminal areas rather than trying to inspect every point at once.
Verify critical measurements and feedback against field evidence before changing control parameters. Then move through equipment, points, local logic, supervisory presentation and maintenance records. This order helps separate a field fault from a mapping, sequence, network or operating problem.
Restore by priority and keep a record
Address conditions affecting safety, continuity and critical environments first, followed by broad outages, persistent manual operation and recurring alarms. Record the symptom, impact, likely cause, action and verification for each issue. Open items still need an owner and next check.
Back up programs, point databases, graphics and key parameters before and after changes. Review every persistent override: retain it only with a current reason and recovery condition. After restoring automatic control in a limited area, observe commands, feedback and environmental trends before expanding the change.
Boundaries and upgrade decisions
Older records may not match field wiring or programs. Confirm equipment condition, current use and a rollback path before acting, especially in healthcare, laboratories, data rooms and continuously occupied buildings. Do not force critical equipment merely because a graphic looks wrong.
Degradation does not automatically require full replacement. Some systems need field repair and program recovery; others need controller or platform modernization. The decision should follow evidence, compatibility, spares, maintainability and operational impact—not the age label alone.
How the same issue differs by setting
Continuously operated buildings
Recovery should be phased and reversible; a graphic anomaly is not authority to force critical equipment.
Information to prepare before contacting us
- Screenshots and alarm records from the time of the issue
- Platform name, version and normal access route
- Controller, gateway and relevant field-device models
- BA point schedules and network or bus information
- When the issue occurs, how long it lasts and what repeats it
- Low-risk checks already completed and the observed result