Why Building Automation Systems Demand a Structured Review
A facility review that skips a rigorous examination of the building automation system is an incomplete one. The mechanical, electrical, and control infrastructure that governs a building's performance often represents decades of capital investment, layered upgrades, and vendor-specific programming decisions that no walk-through observation can fully capture.
Defining Scope Before You Walk the Building
Before any review team enters a mechanical room, the scope of the evaluation must be defined in writing. That definition should specify which systems fall under the automation umbrella for this particular engagement: HVAC controls, lighting schedules, access control, fire-life-safety integration, elevator dispatch logic, and any sub-metering tied to utility cost allocation. Skipping this step means the review will drift toward the systems that are most visible or most recently serviced, rather than the ones that carry the most operational and financial risk.
The scope document should also name the decision the review is meant to support. A tenant considering a long-term lease needs a different depth of analysis than an owner preparing a capital expenditure budget for the next five years. Calibrating the review to its decision purpose prevents both over-analysis and the more costly problem of under-analysis in a critical area.
One practical method is to classify each system by its replacement cycle and its consequence of failure. A central plant controls upgrade that is seven years into a twelve-year cycle carries different urgency than a lighting automation retrofit that reached end-of-life two years ago. That classification becomes the prioritization map that guides where review resources concentrate most heavily.
Knowing who will use the report, what decisions it will inform, and what format those decision-makers can act on sharpens every phase of the work. Establishing that flow before the review begins is a discipline that prevents the scope from expanding mid-engagement without a corresponding adjustment in methodology and timeline.
Gathering Documentation Before the Site Visit
Documentation review is the first technical phase, and it should precede the physical site visit by enough time to generate informed questions for on-site interviews. The baseline document set includes the original sequence of operations for each automated system, any commissioning reports from initial installation or subsequent recommissioning, and maintenance logs that cover at least the prior three years.
Controls submittals and as-built drawings tell the reviewer what the system was designed to do. Maintenance records reveal the gap between design intent and operational reality. When those two datasets diverge significantly, the site visit becomes an investigation rather than a confirmation exercise.
Requests for documentation should go to both the building ownership team and the controls vendor or building management firm, because the two sets of records rarely match perfectly. Ownership records tend to reflect scheduled maintenance and capital projects, while vendor service logs capture reactive calls, sensor replacements, and programming patches that never made it into the formal project record. Both perspectives are necessary for an accurate picture.
Pay particular attention to any record of system integration events: moments when a new subsystem was connected to an existing building automation backbone. Each integration introduces the possibility of communication protocol mismatches, overridden sequences, or orphaned control points that appear on the front-end interface but no longer drive any physical output.
Understanding Control Architecture and Protocol Layers
A building automation system is not a single product; it is a layered architecture. At the field level, sensors and actuators convert physical conditions into electrical signals and mechanical motion. At the automation layer, controllers translate those signals into control decisions according to programmed sequences. At the management layer, front-end software presents the system to operators and logs performance data.
Each layer can use different communication protocols, and compatibility across layers is what determines whether the system functions as designed. Common open protocols include BACnet, Modbus, and LonWorks, while proprietary protocols are still prevalent in older installations or where a controls vendor locked the system to their own hardware and software. Understanding which protocols govern each layer is not an academic exercise — it determines upgrade options, vendor competition, and the cost of future modifications.
The reviewer should document which controller models are in service and whether the manufacturer still supports them with firmware updates and replacement parts. A controller that is functionally operational but commercially discontinued creates a hidden risk: the moment it fails, replacement may require a full re-engineering of that control zone, not a simple part swap.
Protocol translation gateways deserve particular scrutiny. These devices sit between dissimilar systems and translate one communication standard into another. When they fail — or when they are running outdated firmware — they create communication gaps that manifest as phantom alarms, incorrect setpoints, or entire system zones that appear to be operating normally on the front-end interface while actually running in an uncontrolled state.
Conducting the Physical Walkthrough with Measurable Criteria
The physical site inspection should follow a structured scoring framework developed before the walk begins. A scoring matrix that rates each system zone on a consistent set of criteria — sensor accuracy, actuator responsiveness, controller condition, network connectivity, and sequence adherence — produces a defensible record that can be compared across buildings or across review cycles for the same building.
Walking the mechanical rooms without a scoring instrument produces observations. Walking them with one produces a dataset. The difference matters when the review output must support a lease negotiation, a capital budget approval, or a building acquisition decision, because narrative descriptions of "aging controls" carry far less weight than a scored assessment that quantifies deferred maintenance risk.
During the walkthrough, test a sample of sensors against independent reference instruments. A thermostat that reads 72°F in a space that a calibrated probe reads at 68°F is not a minor discrepancy — it means the control loop is chasing a setpoint that does not correspond to actual conditions, driving unnecessary energy consumption and tenant comfort complaints. Sensor drift of this kind is common in systems that have not been recommissioned within the past several years.
Observe actuator operation directly where possible. Damper actuators on air-handling units should move through their full range of travel when commanded. Variable-frequency drives on fan and pump motors should respond to speed commands without hunting or lag. Any actuator that does not behave as commanded during the review should be logged with its location, the command issued, and the observed response, creating a punch list for follow-up verification.
Interviewing the Facilities Team and Controls Vendor
The people who operate a building automation system daily carry institutional knowledge that no document or sensor test can fully capture. Structured interviews with the facilities manager, lead technician, and controls vendor representative should be a formal component of any review methodology, not an informal conversation at the end of a walkthrough.
Develop a standard question set in advance. Key areas to probe include: which alarms are routinely acknowledged and suppressed rather than investigated, which zones consistently drift from setpoint, what workarounds have been programmed into the system to compensate for failed sensors or actuators, and what software licenses or service agreements are approaching expiration. Each answer flags either an operational risk or a near-term cost that should appear in the review output.
Ask the controls vendor specifically about the version of front-end software running on the system and whether it is current. Front-end software that is multiple major versions behind the current release may be unable to connect to modern field devices, may lack cybersecurity patches, or may lose vendor support entirely within the review horizon. Software upgrade costs and any associated hardware compatibility requirements belong in the capital cost projection.
The facilities team interview should also surface scheduling accuracy. A lighting control system running schedules that reflect occupancy hours from five years ago is wasting energy and creating tenant friction. Comparing the current programmed schedule against actual occupancy patterns is a fast diagnostic that reveals whether the automation system is working for the building or simply running on autopilot. Occupancy data from access logs, badge records, or space utilization sensors — wherever such data is available and has been retained — can inform that comparison directly.
Evaluating Cybersecurity Posture
Building automation systems are increasingly connected to IP networks, and that connectivity creates cybersecurity exposure that a facility review must address directly. The question of how to evaluate building automation systems during a facility review cannot be answered completely without assessing the network architecture that carries control traffic.
Review the network segmentation strategy. Control network traffic should be isolated from the corporate or tenant IT network on a dedicated VLAN or physical network segment. When building automation traffic runs on the same network as general internet access, the attack surface expands to include every device connected to that network. Confirming the segmentation configuration is a standard step in any responsible review methodology.
Check for default credentials on controllers, front-end servers, and any web-accessible interfaces. Default usernames and passwords that ship with control hardware are publicly documented and represent the most straightforward entry point for unauthorized access. Any device still operating with factory credentials should be flagged as a critical finding regardless of the overall system age or condition.
Ask whether remote access to the building automation system is enabled and, if so, what authentication method governs it. Vendor remote access for maintenance and troubleshooting is a legitimate operational need, but it should be managed through documented access controls rather than standing open connections. The review should document the remote access method, the number of individuals with credentials, and whether access logs are retained.
##
##
Building the Review Report and Decision Framework
The review report should follow a structure that serves multiple audiences simultaneously. Executives need a summary of findings ranked by financial and operational risk. Facilities managers need the technical detail to act on findings and manage vendor relationships. Legal and transaction teams need a record that can support lease negotiations or diligence disclosures.
Begin the report with a system inventory — a complete enumeration of the controllers, front-end software, protocols, and integration points identified during the review. That inventory becomes the baseline against which future reviews measure change.
Follow the inventory with the scored assessment organized by system and by zone. Each scored finding should link to the supporting evidence: the sensor test result, the maintenance log entry, the interview statement that corroborated a field observation, or the documentation gap that created uncertainty. This linkage is what makes the report defensible when findings are contested by a landlord or seller.
Close the technical section with the capital cost projection organized by time horizon, expressed as a range to reflect estimation uncertainty rather than a false precision that the available data does not support. A range of hypothetical estimated costs — clearly labeled as preliminary estimates pending detailed engineering assessment — is a more responsible and more credible output than a single number that implies a level of confidence the review methodology cannot deliver.
Using the Report to Drive Lease and Transaction Outcomes
The facility review report is not the end of the process; it is the input to a decision. How that input flows into lease negotiations, acquisition pricing, or capital planning determines whether the review investment generated return.
In a lease context, the report supports three specific negotiating positions. First, it provides the technical basis for landlord capital commitment requests, specifying what systems need investment and within what timeframe. Second, it informs the tenant improvement allowance request by documenting what tenant-side systems work will be necessary to connect to an aging or incompatible building automation backbone. Third, it creates a record that protects the tenant if automation-related service failures occur during the lease term.
Buyers in an acquisition process benefit from a parallel structure. The automation assessment translates into a price adjustment request, a repair escrow, or a seller representation and warranty covering the condition of the building systems as of closing. Each of those positions is stronger when supported by a scored, documented review than by general representations about system age or condition.
Establishing a Review Cadence and Continuous Improvement Protocol
A single facility review is a point-in-time assessment. Its findings begin aging the moment the report is delivered, because building systems continue to change — sensors drift, software versions update, vendor support statuses shift, and occupancy patterns evolve.
For most occupied facilities, an annual touchpoint review covering sensor calibration, software version currency, and schedule accuracy — combined with a full review every three to five years that repeats the complete documentation, walkthrough, interview, and financial modeling process — creates a defensible audit trail and catches deferred maintenance before it becomes operational failure.
About Advantai
Advantai is a commercial real estate intelligence and operations platform operated by ADVANTAGE AI LLC, a Delaware limited liability company. It connects client relationships, property research, documents and financial decisions in one workspace for commercial real estate teams — advisers and brokerage teams, occupier and facility teams, and portfolio teams. The platform covers CRM and origination, requirements and site selection, Property X-Ray (an interactive 3D building workspace), financial modeling and comparison, document intelligence, transactions and diligence, client collaboration, and portfolio strategy with critical dates. The optional Super Agent upgrade adds specialist, source-backed research and automated scenario analysis.
Get Started with Advantai
Ready to see your next move clearly? Go to advantaico.com, click Request a demo and tell us about your next project. Prefer to start with a single project? Visit advantaico.com/getting-started to plan your first one.