
What a Building Management System Actually Controls
A building management system controls between 40 and 60 percent of a building's energy load, but most developments spec it like an afterthought. The systems it runs, the protocol it speaks, and the points it monitors are decisions made once at brief stage. They govern service costs for the next thirty years.
A building management system controls somewhere between 40 and 60 percent of a building's total energy load through its connection to the HVAC plant alone. Most residents never know it exists. Most developers treat it as a line item in the mechanical specification rather than a decision that will determine operating cost, service flexibility, and vendor relationships for the next thirty years.
That gap between what a BMS is and how it gets treated at brief stage is where most of the performance disappears. The technology is not the issue. The specification is.
The Control Layer, Not the Dashboard
A BMS is not a monitoring tool. Monitoring is what a dashboard does: it shows you what the building is doing. A BMS is the layer that controls what the building does.
It receives sensor data, runs that data against preset logic, and sends commands to physical systems. Open this valve. Dim these lights. Lock that zone. Trigger this alarm. Buildings designed with a monitoring mindset get dashboards. Buildings designed with a control mindset get a system that changes behavior automatically, around the clock, without anyone initiating it.
The systems a BMS coordinates depend entirely on what the brief required. In a well-specified mid-rise residential building, the BMS integrates HVAC plant, air handling units, fan coil units across every occupied zone, domestic cold water pumps, elevator signaling, common area lighting, access control, fire alarm coordination, and backup power sequencing. In a building where the BMS specification was handed to a subcontractor with no protocol requirement and no commissioning milestone, it likely controls the chiller and not much else.
What the Control Logic Actually Does
The intelligence in a BMS is rule-based, not artificial. If CO2 concentration in the lobby crosses 1,000 parts per million, increase fresh air supply. If occupancy in a zone drops to zero after 11pm, lower the setpoint by four degrees. If the primary chiller fails, start the standby unit within ninety seconds. These sequences are written by a commissioning engineer at handover.
In most buildings, they are never updated after that.
Updating control sequences is not a complex job. It requires BMS programming access, a current picture of occupancy patterns, and a few hours. What it requires most is a line in the service contract that says it should happen, and that line is rarely there.
A building commissioned at partial occupancy may have its HVAC sequences calibrated for 40 percent load. Those same sequences run at full load five years later because no one budgeted to revise them. This is not a BMS failure. It is a maintenance discipline failure that registers as a higher energy bill and a building that no longer feels comfortable at the temperature it once did.
Sensor drift compounds the problem without announcing itself. A temperature sensor reading two degrees above the actual zone temperature causes the system to overcool that space continuously, doing exactly what the logic says, against conditions it cannot accurately see. The resident experiences a space that fluctuates. The maintenance team adjusts the setpoint manually, masking the sensor error, and the loop runs wrong in a new direction.
In Phnom Penh's climate, these consequences sharpen. With ambient temperatures between 25 and 35 degrees Celsius year-round and relative humidity consistently above 70 percent, stale control logic generates condensation, indoor air quality drift, and overcooling that creates its own humidity load along the building perimeter. A BMS with well-maintained sequences manages these dynamics continuously. A building without effective control manages them reactively, after residents have already noticed.
The Protocol Decision That Outlasts the Warranty
Here is the decision that receives the least attention at brief stage and carries the most consequence over the building's life.
A BMS communicates between devices using a data protocol. BACnet, developed under the ASHRAE standard and ratified internationally, is the open protocol that allows hardware from any manufacturer to communicate with hardware from any other. A proprietary protocol does the opposite. It binds the building to one vendor's ecosystem for the operational life of the system. Every service call, every controller replacement, and every future integration must go through the original supplier, at whatever rate the original supplier sets.
Open protocol systems cost roughly 5 to 10 percent more upfront than a proprietary equivalent. That premium is recovered within the first major service cycle, when any qualified contractor can price the work competitively. Under a proprietary arrangement, competitive tendering is not possible by definition. The pricing power transfers to the vendor at the point of specification and stays there.
The protocol choice is written on one page of the mechanical engineer's brief. It governs the building's service economics for twenty to thirty years.
What the BMS Points Schedule Determines
A points schedule is the document that lists every sensor, actuator, and control point wired into the system. It defines what the BMS can see and what it can act on. A complete schedule for a 200-unit mid-rise residential building runs to several hundred individual points: zone temperatures, supply air readings, valve positions, pump flow rates, lighting circuits by floor, alarm states, and access control triggers.
A sparse schedule covers the chiller, a handful of zone temperatures, and the common area lighting. The system is technically operational. It just cannot do much, and it cannot tell the facilities team much either.
The difference between a building that manages itself efficiently at year ten and one that requires a facilities manager on-site every day often traces to this document. Dense, well-structured points enable remote monitoring, optimization without a site visit, and fault diagnosis before a minor issue becomes a service failure. A thin schedule transfers all of that management load to the person walking the floor.
For buildings pursuing LEED or EDGE certification, the points schedule carries one more function. BMS commissioning records and sub-metering data feed directly into the performance verification audit trail. A sparse points schedule cannot generate that documentation, regardless of what the design drawings intended.
What Breaks When the Brief Skips This
The failure pattern is consistent. A building opens with a BMS specified generically, installed by the lowest tenderer, commissioned over two weeks at partial occupancy, and handed over with documentation no one opens. By year five, the chiller runs at full load on a mild evening because no one updated the seasonal sequence. By year eight, two controllers fail and the original vendor has discontinued the model. The retrofit cost is several times what open-protocol hardware would have required at installation.
None of this is dramatic. It is grinding, cumulative, and entirely foreseeable from the brief.
The BMS does not earn its value from the platform name on the controller. It earns it from what was specified before the design was drawn, how the sequences were commissioned, and whether the protocol choice left the building's service economics in the owner's hands.
Owners who review the BMS specification before the mechanical brief is finalized tend to have more options, and lower service costs, at every service cycle that follows. The protocol decision in particular does not get cheaper once the building is commissioned.
At Imajineer, this review is part of how we approach the brief. The conversation is available when it is useful.
footer class="PhCafd B6ltWa"