A megatall tower has somewhere around 30,000 control points. That number is not a detail — it is an architectural constraint, because the field networks that carry them do not scale gracefully. Put 500 points on a single BACnet MS/TP trunk and a full poll cycle takes 3.6 seconds: fine for a room temperature, useless for a damper the fire strategy depends on, and disastrous for any control loop that needs to be stable. A 150-floor building needs on the order of ninety separate field segments, and how they are grouped, where they terminate and what rides on which one is a decision that has to be made in the concept design alongside the mechanical zoning — not left to the controls contractor after the risers are cast.
1 · What makes a tower's controls different
- Sheer point count. Thirty thousand points is a small industrial plant, not a building. Naming conventions, graphics, alarm philosophy and database structure all have to be designed rather than accumulated.
- The field bus is a physical, distance-limited network. BACnet MS/TP over RS-485 has a hard device limit per segment and a shared-token bandwidth that degrades with every device added. Ethernet risers and floor-level IP controllers are what make a tower work.
- Life-safety interfaces are real-time. Smoke control, stair pressurisation, lift recall and generator changeover cannot wait for a poll cycle, and in most codes they cannot depend on the BMS at all — they interface with it.
- Phased handover means phased commissioning of the head end. The system must be operable, alarm-managed and trending for occupied lower floors while the upper zones are still being installed.
- The building will outlive several generations of software. Open protocols, documented point lists and an owned database are what determine whether the system can be maintained in twenty years or has to be ripped out.
2 · Interactive: point count and network segmentation
A 150-floor tower at 200 points and 12 devices per floor is 30,000 points on 1,800 devices, needing at least 90 field segments. That is the number that decides the architecture: ninety RS-485 trunks cannot all be home-run to a basement head end, so the system becomes an IP backbone up the riser with floor- or zone-level IP controllers, each hosting a short local field bus. Design that hierarchy to match the mechanical zoning — one network zone per mechanical zone — so that a zone can be commissioned, isolated and handed over independently, which is exactly what phased commissioning requires.
3 · Interactive: why the field bus is the bottleneck
MS/TP is a token-passing bus: every device gets the token in turn, and the time to poll everything scales linearly with what is on the trunk. That poll cycle is the response time of every control loop that crosses it.
Five hundred points on a 76,800-baud trunk gives a 3.6-second poll cycle — acceptable for space temperature, marginal for a pressure loop, and unacceptable for anything that has to act. Drop the baud rate to 9,600, which one legacy device on the trunk can force, and the same trunk takes 29 seconds: a single incompatible device destroys the performance of everything sharing the bus with it. Two rules follow. Specify the minimum baud rate every device must support, and keep life-safety and fast loops off the shared field bus entirely — hardwired or on IP, never behind a token queue.
4 · The life-safety boundary
The most consequential architectural decision in a tower's controls is what the BMS is allowed to do:
- Fire detection and alarm is a separate, listed system. It signals the BMS; it does not depend on it. In most codes the fire system must be able to execute its cause-and-effect matrix with the BMS entirely out of service.
- Smoke control actuation should be hardwired or on a listed network. Damper and fan commands that form part of the fire strategy must not traverse a shared field bus whose response time depends on how many VAV boxes somebody added later.
- The BMS provides monitoring and normal-mode control, and hands over cleanly on alarm. Design the handover explicitly, including what happens on restoration, which is the case nobody tests.
- Lift, generator and fire pump interfaces are status-and-command boundaries with their own contractors; define every signal, its direction and its failure state in an interface matrix issued at design, not negotiated on site.
- Security and access control interact with egress. Fail-safe versus fail-secure on every door is a life-safety decision documented in the same matrix.
5 · Interactive: trending, and how much data that is
A building you cannot see is a building you cannot improve. Trending is what makes every diagnostic in this whole series possible — the approach temperature in water treatment, the return temperature in district cooling, the door differential in stack effect — and it has to be specified, sized and paid for.
Thirty thousand points at fifteen-minute intervals is 16.8 GB a year — 168 GB over a ten-year retention, which is nothing. Even one-minute sampling on every point is 252 GB a year, still trivial against the value it delivers. There is no technical reason to trend sparsely, and the usual reasons given are commercial rather than real. Specify comprehensive trending with long retention from day one, because the data you did not collect in year one is the data you will want in year five when somebody asks why the building uses more than it did. Use change-of-value logging for slow points to cut the volume without losing the record.
6 · Metering — the part that has to be designed, not added
- Meter to a hierarchy that closes. Utility intake, then plant, then zone, then tenant. Every level should sum to the level above within a stated tolerance; if it does not, the discrepancy is either a meter fault or a load nobody knows about — and both are worth finding.
- Sub-metering coverage is the single number that determines whether energy management is possible. Below about half the load metered, most consumption is unattributable and any efficiency claim is speculation.
- Meter thermal energy as well as electricity. Cooling delivered per zone is what exposes the low-ΔT problems that this series keeps returning to, and it is what makes tenant recharging fair.
- Match the meter to the contract. Where meters are used for billing they must meet the relevant accuracy class and be installed with the straight lengths and matched sensor pairs the standard requires — the point made in district cooling applies to every tenant meter too.
- Give every meter a network path and a name in the same convention as the rest of the system. A meter that has to be read by walking to it will be read once a year at best.
7 · Design, installation & handover
- Design the naming convention before the first controller is ordered. Building, zone, system, equipment, point — consistent, machine-parsable and documented. Thirty thousand inconsistently named points is a building that cannot be analysed, and renaming later is a project in itself.
- Write the alarm philosophy. Priorities, routing, suppression during known conditions and a limit on the alarms an operator can receive per hour. An unmanaged system generates thousands of alarms a day and is then ignored entirely — which is worse than having none.
- Specify open protocols and an owned database. Insist on documented point lists, exportable trend data and no proprietary lock on the graphics or the database schema. This is the clause that decides whether the system can be maintained or must be replaced.
- Segregate the network properly — controls on their own VLAN, no direct internet exposure, remote access through a managed gateway, and a documented patching responsibility. A BMS is an OT network and should be treated as one.
- Commission the sequences, not the points. Point-to-point checks prove wiring; only a functional test against the written sequence of operation proves control. Require the sequences as a written deliverable and test against them.
- Hand over the model, the database and the trends — not just drawings. The single most useful handover artefact is an exportable, documented point database with a year of trend data behind it.
- Plan for the head end to outlive its software. Budget a software refresh at ten to fifteen years and make sure the field devices will survive it.
8 · The design & installation checklist
- Estimate the point count early and design the network hierarchy to match the mechanical zoning.
- Keep field trunks short and specify a minimum baud rate for every device.
- Keep life safety off the shared bus, with an interface matrix issued at design.
- Design the naming convention and alarm philosophy as deliverables.
- Trend comprehensively with long retention — the storage is trivial.
- Meter to a hierarchy that closes, thermal as well as electrical.
- Specify open protocols, exportable data and an owned database.
- Treat the network as OT — segregated, managed and patched.
- Commission against written sequences, zone by zone, and hand over the database and the trends.
References & standards
- ANSI/ASHRAE Standard 135 — BACnet: A Data Communication Protocol for Building Automation and Control Networks, including MS/TP physical layer limits and device addressing.
- ASHRAE Guideline 13 — Specifying Building Automation Systems, and Guideline 36 for high-performance sequences of operation.
- ISO 16484 series — building automation and control systems: hardware, functions, project specification and commissioning.
- ANSI/ASHRAE/IES Standard 90.1 — metering, monitoring and control requirements; and ASHRAE Standard 224 / Guideline 36 for sequence standardisation.
- CIBSE Guide H — Building Control Systems and CIBSE TM39 Building Energy Metering.
- IEC 62443 — industrial communication network security, applied to building operational technology networks.
- EN 1434 / OIML R75 for thermal energy meters, and IEC 62053 for electricity meter accuracy classes.
- ASHRAE Design Guide for Tall, Supertall, and Megatall Building Systems, 2nd ed. — controls architecture and phased handover in tall buildings.