Selecting a building automation system is a staged evidence process. The project should move from verified conditions and owner requirements through representative demonstrations, comparable evaluation, contract commitments and acceptance testing.
Selection roadmap
- Survey Verify the live estate, documentation, condition, dependencies and unsupported assets.
- Specify Define outcomes, sequences, interfaces, data rights, cybersecurity and mandatory gates.
- Demonstrate Test difficult workflows, failures, recovery, exports and third-party exchange.
- Evaluate Normalize scope, evidence, lifecycle cost, delivery capability and exceptions.
- Contract Convert material promises into deliverables, service terms, tests, warranties and remedies.
- Accept and operate Commission, hand over owner access, train users and begin performance governance.
For: owners, facilities teams, designers, commissioning providers, IT and cybersecurity teams, procurement, legal reviewers and operational leaders.
Quick answer: how should a BAS be selected?
Select a building automation system by first documenting the facility, operating objectives, required sequences, interfaces, cybersecurity, owner rights and lifecycle support. Screen mandatory requirements before weighted scoring, test representative workflows, normalize whole-life cost and define acceptance before award. The process should select an operating capability—not simply a familiar vendor or feature list.
The BAS explainer defines the system layers, while BMS vs BAS vs EMS prevents naming ambiguity from entering the specification. This page owns the procurement and implementation route.
1. Establish governance and decision authority
| Role | Primary responsibility | Decision evidence |
|---|---|---|
| Executive or project sponsor | Outcome, funding, risk tolerance and decision gates | Approved project brief and escalation path |
| Facilities and operations | Operating needs, current problems, staffing and maintainability | Use cases, failure history, staffing model and acceptance needs |
| Mechanical, electrical and controls design | Sequences, interfaces, ratings, system architecture and code coordination | Owner requirements, design documents and technical evaluation |
| Commissioning authority | Testability, functional verification, issue tracking and acceptance | Commissioning plan, scripts and closeout criteria |
| IT and cybersecurity | Network, identity, remote access, logs, updates, recovery and incident roles | Architecture, security requirements and approval record |
| Energy and sustainability | Metering, baselines, optimization, reporting and performance review | Data requirements and value-measurement plan |
| Procurement, finance and legal | Competition, cost normalization, contract, warranties and risk allocation | Evaluation plan, TCO model and negotiated terms |
The team should agree who can approve changes to requirements, evaluation weights, bidder clarifications and exceptions. Undocumented decisions made during demonstrations or negotiation can undermine a fair comparison and create a live system that does not match the approved project purpose.
2. Survey the existing building and controls estate
- Verify equipment, controllers, sensors, actuators, panels, networks, servers, software, licenses and cloud dependencies.
- Compare as-built records, point lists, sequences and graphics with the live system.
- Review trends, alarms, overrides, comfort complaints, energy patterns, maintenance history and known failures.
- Identify unsupported products, shared infrastructure, proprietary tools and service-provider dependencies.
- Test representative devices and interfaces before assuming reuse.
- Record shutdown, access, safety, infection-control, production and seasonal constraints.
| Deliverable | Purpose | Failure if missing |
|---|---|---|
| Asset and version register | Defines what exists and its support condition | Bidders price incompatible assumptions |
| Network and data-flow diagram | Shows communication, remote paths and system boundaries | Cybersecurity and integration work remain hidden |
| Sequence and point-gap review | Shows behavior that is documented, missing or overridden | New controls automate an unclear baseline |
| Condition and reuse matrix | Separates reusable, remediable, unverified and replaceable assets | Lowest quote relies on optimistic reuse |
| Operational constraint register | Captures shutdowns, access, temporary operation and critical loads | Delivery schedule is not executable |
3. Define outcomes and mandatory requirements
Write requirements in terms of observable outcomes and evidence. Examples include stable temperature or pressure control, continued local operation during supervisory failure, owner-controlled backups, defined alarm workflows, successful export of trend data and recovery of a controller or server from approved files.
| Category | Examples | Acceptance evidence |
|---|---|---|
| Functional operation | Modes, sequences, setpoints, resets, safeties, interlocks and recovery | Functional performance tests and trend review |
| System scope | Plant, air systems, zones, lighting, metering, refrigeration and distributed energy | Responsibility and point/object schedules |
| Interoperability | Protocols, objects, services, commands, alarms, trends, APIs and metadata | Interface demonstration and witnessed test |
| Data and owner rights | History, units, quality, retention, export, configuration, tools and credentials | Delivery checklist and tested export/restore |
| Cybersecurity | Inventory, segmentation, identity, remote access, logging, updates and incident response | Architecture review and security acceptance test |
| Reliability and recovery | Local fallback, redundancy, backups, restore time and service response | Failure injection and recovery evidence |
| Commissioning and handover | Testing, training, documentation, seasonal verification and issue closure | Approved commissioning record and owner signoff |
| Lifecycle support | Licensing, escalation, supported versions, spare strategy, migration and exit | Multi-year commercial schedule and transition plan |
Mandatory safety, operational, cybersecurity, interface and ownership requirements should be pass/fail gates. Weighted preferences can then compare usability, analytics, delivery approach, service and commercial value.
4. Choose a procurement and implementation route
The route may be a competitive controls contract, a mechanical-project controls package, a master systems integrator model, a phased retrofit or an enterprise platform procurement. Each route changes responsibility for design, field devices, programming, integration, commissioning and long-term support. The Technology Procurement Process provides the wider governance sequence.
| Question | Why it matters |
|---|---|
| Who owns the sequence and final design? | Separates design responsibility from vendor product configuration |
| Who coordinates third-party interfaces? | Prevents gaps between equipment, controls, IT and analytics suppliers |
| Who provides independent verification? | Avoids the installer being the only judge of acceptance |
| How is existing-condition risk handled? | Controls allowances, investigation and change orders |
| Who supports the system after handover? | Aligns licenses, tools, response and owner capability |
| How can the owner change supplier later? | Tests portability, documentation and lock-in exposure |
5. Issue comparable bidder information
- Owner project requirements and decision outcomes.
- Existing-condition survey, asset register, drawings, sequences and known deficiencies.
- Required systems, interfaces, network and cybersecurity architecture.
- Point/object and trend requirements with data ownership and retention.
- Commissioning, demonstration and acceptance requirements.
- Commercial schedule for one-time, recurring, optional and change work.
- Required exceptions, assumptions, compliance matrix and evidence references.
- Implementation constraints, milestones, shutdowns and owner responsibilities.
Bidders should state every dependency on owner infrastructure, third parties, licenses, cloud services, utilities and proprietary tools. Silence should not be interpreted as inclusion.
6. Use representative demonstrations
A standard sales demonstration rarely reveals integration, recovery or operator friction. Provide a scripted scenario and require every shortlisted bidder to perform the same tasks using the proposed architecture or a technically representative environment.
| Scenario | What to observe | Required record |
|---|---|---|
| Alarm lifecycle | Detection, priority, routing, acknowledgment, notes, escalation and closure | Timestamped workflow and audit history |
| Schedule and setpoint change | Permissions, validation, effective time, rollback and history | Change record and resulting trend |
| Trend creation and export | Units, interval, retention, quality flags and usable format | Exported file and data dictionary |
| Server or network failure | Local operation, alarm behavior, buffered data and recovery | Failure and restoration timeline |
| Controller replacement | Backup, identity, configuration, testing and return to service | Witnessed restore procedure |
| Third-party integration | Object discovery, mapping, commands, alarms, units and communication loss | Interface test results |
| User removal and remote support | Account lifecycle, approval, logging and termination | Access record and log evidence |
7. Test interoperability claims
For BACnet interfaces, request the relevant device capabilities and conformance information, network design, naming, objects, services and acceptance tests. Verify command priority, writable properties, units, time synchronization, alarms, trends and behavior during communication loss. The term “BACnet compatible” is not an adequate requirement.
Semantic models and common naming can make portfolio analytics and integration more maintainable, but they also require governance. DOE’s current interoperability research highlights the value of machine-readable descriptions and testing frameworks; project teams still need to define the actual schema, ownership, versioning and acceptance.
8. Evaluate cybersecurity as operational risk
- Require a current inventory and architecture covering controllers, servers, workstations, gateways, cloud services and remote paths.
- Define role-based access, privileged administration, multifactor authentication where appropriate and account removal.
- Approve segmentation and each cross-boundary communication path.
- Control vendor remote access through approval, time limits, logging and termination.
- Define vulnerability intake, supported versions, testing, patch approval and compensating controls.
- Test backups and restoration for controllers, servers, databases, certificates and configuration.
- Coordinate incident detection, containment, safe operation and recovery between facilities, IT and vendors.
NIST SP 800-82 Rev. 3 is useful because it frames building management systems as operational technology. The evaluation should reject security claims that are not connected to the proposed architecture, product support model and recovery process.
9. Normalize whole-life cost
Compare equipment, field work, programming, graphics, integrations, commissioning, cybersecurity, training and documentation on one scope. Then model subscription, support, data, hosting, calibration, re-tuning, upgrades, replacement and exit over the same analysis period. The BAS cost guide provides the full boundary, and the TCO worksheet records the scenarios.
| Evaluation stage | Treatment | Example |
|---|---|---|
| Mandatory gates | Pass/fail before scoring | Required sequence, local fallback, cybersecurity, owner access or code-related interface |
| Technical fit | Weighted and evidence-based | Architecture, control performance, interoperability and maintainability |
| Delivery fit | Weighted with risk review | Team, schedule, phasing, existing-condition method and commissioning |
| Operating fit | Weighted with user evidence | Alarms, trends, workflows, staffing, training and service |
| Commercial fit | Normalized TCO and contract risk | Price, recurring cost, warranty, liability, change and exit |
| Confidence | Recorded separately from score | Demonstrated, documented, roadmap, assumption or exception |
Use the Technology Evaluation Scorecard for weighted criteria and the Vendor Comparison Worksheet for scope, evidence and commercial normalization.
10. Convert claims into contract and acceptance terms
| Proposal claim | Contract or evidence treatment |
|---|---|
| “Open system” | List delivered tools, files, credentials, interfaces, licenses and replacement tests |
| “High availability” | Define measured availability, excluded time, reporting, service response and remedy |
| “Energy savings” | Define baseline, assumptions, measurement, persistence, constraints and guarantee status |
| “Cybersecure” | Attach architecture, controls, support obligations, incident roles and acceptance tests |
| “Seamless integration” | Attach interface schedule, responsibilities, test cases and failure behavior |
| “Easy migration” | Define export formats, configuration delivery, assistance, fees and transition timetable |
Payment milestones should align with verifiable deliverables: approved design, equipment delivery, installation completion, point verification, functional tests, documentation, training, issue closure and final acceptance. Warranty should start at a defined acceptance point, not an ambiguous shipment or energization date.
11. Plan implementation, handover and operation
- Approve design, sequences, point/object schedules, naming, graphics, network and cybersecurity before programming is locked.
- Coordinate field installation, equipment startups, interfaces and temporary operation.
- Complete point-to-point, functional, failure, recovery, integration and security tests.
- Review trends and alarms over a representative period and complete seasonal testing where required.
- Deliver verified backups, source/configuration files, databases, credentials, licenses, as-builts, manuals and training.
- Establish access review, backup testing, alarm governance, re-tuning, patch review and performance reporting after handover.
Hard rejection conditions
Reject or pause the selection when
The procurement should not advance to award while any of these conditions remains unresolved.
- No verified existing-condition survey supports the proposed reuse and scope.
- Required sequences, interfaces, failure behavior or owner rights are undefined.
- A mandatory requirement is failed but hidden by a weighted score.
- Demonstrations use only vendor-prepared ideal data and avoid recovery or integration tasks.
- Cybersecurity claims lack architecture, support responsibilities and tested recovery.
- Recurring cost, licensing, end-of-support or exit cannot be modeled.
- Commissioning and acceptance are not defined before contract award.
- Material proposal claims remain outside the contract, test plan, warranty or remedy.
- The owner lacks a credible operating model, trained staff or service arrangement after handover.
Limitations
This guide supports structured procurement but does not select a vendor, approve a contract, provide a final design or certify cybersecurity, code or operational compliance. Obtain qualified controls, mechanical, electrical, commissioning, cybersecurity, procurement and legal review for the actual project.
Close the technical assumptions before award
Use the sibling pages to verify architecture, terminology and cost.
Understand the BAS
Review control layers, sequences, data, security and commissioning.
Clarify the platform boundary
Compare BAS, BMS and EMS labels by actual capability.
Normalize whole-life cost
Price implementation, operation, support, replacement and exit.
Return to the Building Automation and Controls hub for the wider cluster pathway, or use How to Compare Vendor Proposals for cross-technology evaluation discipline.
Sources and evidence
Primary and authoritative references used for this page are listed below. Recheck current editions, site conditions, contracts and jurisdictional requirements before a live project decision.
- Read-Only Versions of ASHRAE Standards and Guidelines — ASHRAE
- BACnet — Building Automation and Control Networking Protocol — ASHRAE
- Building Controls — U.S. Department of Energy Building Technologies Office
- About Building Controls — U.S. Department of Energy Building Technologies Office
- Commissioning in Federal Buildings — U.S. Department of Energy Federal Energy Management Program
- Re-tuning in Federal Buildings — U.S. Department of Energy Federal Energy Management Program
- Energy Management Information Systems for Federal Facilities — U.S. Department of Energy Federal Energy Management Program
- Semantic Modeling and Interoperability — U.S. Department of Energy Building Technologies Office
- BOPTEST: Building Operations Testing Framework — U.S. Department of Energy Building Technologies Office
- SP 800-82 Rev. 3: Guide to Operational Technology Security — National Institute of Standards and Technology
- Cybersecurity Framework 2.0 — National Institute of Standards and Technology
- Project Control authority: approved page map, complete page criteria and page-rules addendum — Future Green Technology
Reviewed and updated 29 June 2026. Recheck when standards, controls products, software support, cybersecurity guidance, procurement requirements, commissioning practice or owner operating needs change. Organizational author: Future Green Technology, published by Zenith Star Media.