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

2 · Interactive: point count and network segmentation

Points, devices and field network segments
BACnet MS/TP allows 32 devices per segment without repeaters (127 addresses maximum). Segment count is the minimum implied by the device count; practical designs use fewer devices per trunk to protect response time.
Occupied floors carrying field devices.
VAV boxes, FCUs, valves, sensors, meters and lighting interfaces.
Physical controllers on the field bus.
Design limit. The code allows 32; using fewer protects the poll cycle.
Total points
30,000
Field devices
1,800
Field segments
90
Points per segment
333
Architecture

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.

Field bus poll cycle against points per trunk
Cycle time ≈ points × bytes per transaction × 8 / baud rate, with an allowance for token passing overhead. The dashed line is the response time your slowest acceptable control loop needs.
Total points polled across all devices on one segment.
MS/TP runs at 9600, 19200, 38400 or 76800 baud. Use the highest every device supports.
Request plus response, including framing and token overhead.
Slowest acceptable loop response on this trunk.
Poll cycle
3.59 s
Max points allowed
278
Trunks needed
2
At 9600 baud
28.7 s
Verdict

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:

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.

Trend data volume by sample interval and retention
Samples = points × (60/interval) × 8760 per year; storage at the stated bytes per sample including timestamp and quality flag. Change-of-value logging reduces this substantially for slow points.
Not every point needs trending — but every point you will ever be asked about does.
15 minutes suits energy analysis; 1 minute is needed for control diagnostics.
Long retention is what lets you compare this summer with the first one.
Value plus timestamp plus quality, before compression.
Samples per year
1.05 G
Storage per year
16.8 GB
Over retention
168 GB
At 1-minute
252 GB/yr
Assessment

Thirty thousand points at fifteen-minute intervals is 16.8 GB a year168 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

7 · Design, installation & handover

8 · The design & installation checklist

The one-line summary Thirty thousand points is a small industrial plant, and the field networks that carry them do not scale: 500 points on one MS/TP trunk is a 3.6-second poll cycle, and a single legacy device forcing 9,600 baud makes it twenty-nine. So the architecture is an IP backbone with zone-level controllers whose boundaries match the mechanical zoning, life safety kept off the shared bus entirely, and short field trunks with a specified minimum baud rate. Then spend the effort on the three things that decide whether the building can be managed for sixty years: a designed naming convention, a metering hierarchy that closes, and comprehensive trending with long retention — which costs 168 GB over a decade and is the only reason any of the diagnostics in this series are possible at all.

References & standards

  1. ANSI/ASHRAE Standard 135 — BACnet: A Data Communication Protocol for Building Automation and Control Networks, including MS/TP physical layer limits and device addressing.
  2. ASHRAE Guideline 13 — Specifying Building Automation Systems, and Guideline 36 for high-performance sequences of operation.
  3. ISO 16484 series — building automation and control systems: hardware, functions, project specification and commissioning.
  4. ANSI/ASHRAE/IES Standard 90.1 — metering, monitoring and control requirements; and ASHRAE Standard 224 / Guideline 36 for sequence standardisation.
  5. CIBSE Guide H — Building Control Systems and CIBSE TM39 Building Energy Metering.
  6. IEC 62443 — industrial communication network security, applied to building operational technology networks.
  7. EN 1434 / OIML R75 for thermal energy meters, and IEC 62053 for electricity meter accuracy classes.
  8. ASHRAE Design Guide for Tall, Supertall, and Megatall Building Systems, 2nd ed. — controls architecture and phased handover in tall buildings.
#BMS #BuildingAutomation #Controls #BACnet #MSTP #ASHRAE135 #Guideline36 #TallBuildings #MegatallBuildings #PointCount #NetworkArchitecture #IPBackbone #PollCycle #BaudRate #LifeSafetyInterface #CauseAndEffect #InterfaceMatrix #Trending #DataRetention #ChangeOfValue #Metering #SubMetering #ThermalMetering #EN1434 #NamingConvention #AlarmPhilosophy #OTSecurity #IEC62443 #Commissioning #MEP #BuildingServices