Specifying an HVAC controls upgrade without a locked proprietary front end

Reference article · 5 min read

A controls upgrade arrives as a mechanical project with a capital budget and a mechanical engineer of record. What drives the agency's cost over the life of that system is not the equipment selection. It is the specification language deciding whether a second contractor can later log in, open the control programs, and bid the next phase of work. After commissioning, that language is close to impossible to renegotiate, because the leverage is gone.

Many agencies believe they have handled this by writing "system shall be BACnet." That sentence is necessary and nowhere near sufficient. A building automation system can speak a standard protocol perfectly and still be unserviceable by anyone except the company that installed it, because a protocol governs how devices exchange data. It says nothing about who may change the logic, edit the screens, or hold the license to the engineering tool.

Open protocol is not the same as an open system

Open protocol means devices communicate using a published, vendor neutral standard. BACnet, published by ASHRAE as Standard 135, is the common choice in public buildings. Modbus and LonWorks still appear at equipment or plant level. Requiring a protocol buys interoperability: a third party workstation can discover devices and read and write points.

Open system means the agency can perform the full lifecycle of work without depending on one company: editing control logic, modifying graphics, replacing controllers, commissioning new sequences, and extracting trend history. A contractor can deliver native BACnet on every wire and still hold the only license for the programming tool, lock the application program inside the controller, or supply graphics only their workstation renders. Specify both the protocol and the rights.

Conformance stated precisely. Name the standard, the device profile required for each class of controller, and third party conformance testing such as a BACnet Testing Laboratories listing. Standards and listing programs are revised, so confirm current versions before the specification goes out.
Native, not gatewayed. Require the standard protocol at the controller itself, not a gateway translating from a proprietary bus. Gateways become single points of failure and single points of control.
No hidden points. Require that every value used in a sequence, alarm, or graphic be exposed as a standard object, readable and writable at the same priority the vendor's own front end uses.

What the agency must own at closeout

State ownership in the contract, in editable form, not as read only exports.

Application programming. Source level programs for every controller, in the native format of the programming tool, with comments intact.
Graphics. Editable source files for every page, plus the symbol libraries, backgrounds, and floor plans used to build them.
Databases and configuration. The supervisory database, alarm and schedule configuration, trend definitions, and network addressing tables.
Tools. The engineering software needed to open all of the above, licensed to the agency, with installation media or download rights and documented versions.
Documentation. As built network risers, point to point checkout records, written sequences matching the delivered programming, and a controller inventory.

A clause granting the agency a license to use the system is not the same as a clause granting the right to modify it and to let a competitor modify it. Say both.

Licensing the supervisory software

The front end is where lock in usually lives. Address it directly in the bid documents.

License the supervisory software to the agency by name, not to the contractor, and make it transferable when the agency changes service providers.
Require that the agency keep full viewing, editing, and programming capability without a recurring fee. If the product is subscription based, evaluate the ongoing cost alongside the install price.
Require that software maintenance, where offered, be purchasable from more than one authorized dealer, priced as separate bid lines for the base and renewal terms.
Require disclosure of every feature, driver, or integration carrying a separate charge, including limits on points, devices, or users.

Naming conventions and point lists

Naming decides whether a future contractor can read the system or has to rediscover it. Issue the naming standard in the bid documents instead of accepting whatever the contractor uses in house. Define building, floor, system, equipment, and point abbreviations, and require those same names in the controller objects, the graphics, the trend logs, and the as built documents.

Make the point list a contract document rather than a submittal, listing every hardware and software point, its object type, units, and the equipment it serves. Reference an industry sequence framework where it fits, such as the ASHRAE guideline addressing high performance sequences of operation. If the agency plans to move data into an analytics platform later, consider requiring tagging consistent with an established semantic model, confirming its current status first.

Passwords and access at closeout

Require turnover of administrator level credentials for every controller, supervisory server, and engineering tool, plus a written list of all account levels and any factory or service accounts. Require that the agency change those passwords at acceptance and that the system keep working afterward. Coordinate with the IT organization early on network placement, segmentation, remote access, and logging. Tie a portion of retainage to credential turnover.

How to verify before you accept

Have agency staff or a third party connect an independent workstation and read and write points on a sample of controllers.
Open one control program and one graphic page using only the tools and licenses delivered under the contract.
Export a month of trend data in a documented, non proprietary format.
Change a password, then repeat the first two steps.

HQT advises public agencies on specification language and systems engineering for building technology and integration projects.

Frequently asked questions

Does specifying BACnet prevent building automation vendor lock in?

No. BACnet is a communication standard, so it governs how devices exchange data, not who is allowed to change the control programs or graphics. A system can be fully BACnet compliant while the programming tool, the graphic source files, and the supervisory license remain in the installing contractor's hands. Protocol requirements must be paired with contract language on ownership, licensing, tools, and credentials.

What is the difference between an open protocol and an open system?

Open protocol means devices talk using a published, vendor neutral standard, which lets another workstation read and write points. Open system means the agency can perform the whole lifecycle of work, including editing logic, modifying graphics, adding controllers, and pulling trends, without depending on a single company. Most lock in happens on the open system side, in tools and licenses rather than in the wire protocol.

Who should own the graphics and programming files for a building automation system?

The agency should own them, and the specification should say so in editable source form rather than as read only exports or printed documentation. That includes controller programs with comments intact, graphic page sources, symbol libraries, the supervisory database, and the engineering software needed to open all of it. Ownership of a license to use the system is not the same as the right to modify it or to let another contractor modify it.

Can an agency require the controls contractor to turn over administrator passwords at closeout?

Yes, and it should be a written closeout deliverable rather than an informal request. Require credentials at the highest access level for every controller, supervisory server, and engineering tool, along with a list of all account levels and any factory or service accounts. It is reasonable to change those passwords at acceptance, confirm the system still runs, and tie a portion of retainage to the turnover.

How do we test whether an installed controls system is really non-proprietary?

Test it before final acceptance, while payment leverage still exists. Connect an independent workstation and read and write points on a sample of controllers, open one control program and one graphic page using only the delivered tools and licenses, export trend data in a documented format, then change a password and repeat the first steps. If any of that requires the installing contractor's own license or account, the system is not open in practice.