BMS Software and Platforms: How to Evaluate

A building management system is really two purchases wearing one name. Underneath sit the controllers, sensors, valves and actuators that make the plant run, and they will keep running whether or not anyone is logged in. Above them sits the supervisory software: the graphics, the schedules, the alarm console, the trend database, the reports and the user accounts. That upper layer is what the operators touch, what the licence fee buys, and what almost nobody evaluates rigorously. Buyers spend their scrutiny on controller specifications and then accept whatever front end the vendor ships with them. Two years later the complaint is never about the controllers.

The message up front: evaluate the supervisory software as a separate product with its own requirements, its own demo and its own scorecard, because it is the layer that decides whether the system gets used or overridden, whether you can ever get your own data out, and what the upgrade will cost you in fifteen years. The controllers determine whether the building works. The software determines whether anybody can tell.

This guide assumes you already know what a BMS is. If you do not, start with the complete guide to building management systems and the companion piece on building automation systems, then come back. It also deliberately does not rank vendors. For that, see the Siemens vs Schneider vs Honeywell vs Johnson Controls comparison. What follows is the evaluation method you apply to whichever names end up on your shortlist.

1. Two layers, two purchases: what the supervisory software actually does

The single most useful thing you can do before an evaluation is draw the boundary between the two layers and write down which side each requirement falls on. It takes twenty minutes and it reframes every subsequent conversation.

The control layer is the field devices and the programmable controllers. A controller holds the sequence of operations for its plant: the chilled water reset logic, the economiser changeover, the interlocks that stop a fan running against a closed damper. Properly engineered, it does all of that standalone. Pull the network cable and the plant carries on.

The supervisory layer is the software above that. Its job is visibility, coordination and record. Concretely:

• Graphics. Plant schematics, floor plans, live values, and the navigation that gets an operator from a complaint to the relevant plant.
• Scheduling. Occupancy calendars, holiday exceptions, optimum start and stop, changeable without a programming tool.
• Alarm management. Collection, prioritisation, routing, acknowledgement, suppression and history.
• Trend logging. The historian: sampling, storage, retention, charts and export.
• Reporting. Scheduled and ad hoc reports on energy, runtime, alarm counts, setpoint compliance.
• User management. Accounts, roles, permissions, and an audit trail of who changed what.
• Integration. The interfaces by which anything outside the BMS reads from it or writes to it.

Notice that nothing in that list controls a plant item directly. The supervisory layer writes setpoints and schedules into controllers and reads values back out. That is the whole relationship, and it tells you what a software failure costs you: not a building shutdown, but a blind building.

2. The openness question and what "open protocol" means at the point of sale

Every BMS platform describes itself as open. The word has been marketed into near meaninglessness, so the useful question is not whether a product is open but what you will be able to do without the original vendor in the room. Openness has at least four separate dimensions, and a product can be strong in one and closed in the others:

• Protocol openness. Does it speak BACnet or Modbus natively, at what conformance level? A BACnet/IP interface exposing only a curated handful of objects is technically compliant and practically closed.
• Engineering openness. Can another competent contractor obtain the engineering tool, get trained, and modify your graphics and sequences? Or is the toolset restricted to authorised branches of one manufacturer?
• Data openness. Can you get trend history out in bulk, in a documented format, without asking anybody? The dimension most often quietly closed.
• Device openness. Is a third-party BACnet controller discovered, graphed and trended as a first-class citizen, or does it land in a reduced-function "integrated device" bucket?

The sales answer to all four is yes. The engineering answer varies, and the way to find it is to ask in a form that requires a demonstration: "show me a third-party BACnet controller from a different manufacturer on your live demo system, add a point from it to a graphic, and put it on a trend." That takes four minutes to satisfy if the claim is true.

The commercial reality worth naming honestly: open protocols reduce lock-in at the integration layer, but they do not remove it at the tool and licence layer, and no manufacturer has a commercial interest in removing it. Openness is something you extract through specification, not something you receive because a datasheet says BACnet. The specification clauses guide covers the wording that actually holds.

3. Graphics and operator usability: the thing that decides whether the system is used

I have walked into plant rooms where the BMS workstation was showing a screensaver and every air handling unit was in hand. That is not a control failure. It is a usability failure resolved, rationally, by the people who have to run the building. When the software takes eleven clicks to change a setpoint an operator needs to change twice a day, the operator goes to the panel instead, and from then on the supervisory system is a decoration. So graphics are not cosmetics: they are the interface through which every operational decision either happens or does not. What to judge:

• Depth to reach anything. From the home page, how many clicks to a specific AHU's supply air temperature? Three is good. Six means nobody will go there under pressure.
• Live values with units and status. A number with no unit, no timestamp and no indication of whether the point is stale, overridden or in fault is worse than no number.
• Override visibility. Every manual override should be findable from one screen. Overrides left in place for months are a common cause of quiet energy waste, and if the software cannot list them, they stay.
• Who can edit graphics, and with what. An editor an in-house engineer can be trained on changes the economics of every minor change. Where adding a point to a page is a chargeable site visit, pages stop being updated.
• Mobile and tablet behaviour. Not a marketing app, but whether the actual graphics render usefully on the device an engineer carries around the plant.
• Response under load. Page load times on a fifty-point demo system mean nothing. Witness a system with a point count comparable to yours.

Graphics quality is only partly a product attribute; most of it is delivered work, and a capable platform badly graphicked is the normal outcome when nobody specified the screens. The commissioning, graphics and operator dashboards piece covers what to specify and how to witness it.

4. Alarm management, and how an unfiltered alarm list trains operators to ignore alarms

Ask to see the live alarm list on any BMS that has run three years without alarm rationalisation. You will typically find hundreds of active items, most permanently active, many from plant that was decommissioned. The operators have learned that the alarm list carries no information, and they are correct. That is the most consequential failure mode in the whole supervisory layer, because a genuine critical alarm then arrives in a stream nobody reads. The software cannot prevent it alone, but it either gives you the tools to manage it or it does not. What to look for:

• Real priority levels, and routing that respects them. Not just a colour. A critical alarm should page or email a different recipient list, at a different time of day, from a low-priority advisory.
• Delay and deadband per alarm. Most nuisance alarms come from points crossing a threshold briefly. On-delay, off-delay and hysteresis are basic, and their absence guarantees noise.
• Suppression tied to state. When a chiller is off, its flow and temperature alarms should suppress automatically, not be manually disabled and forgotten.
• Shelving with expiry. An operator needs to silence something for a shift. If the only options are permanent disable or nothing, they will permanently disable it.
• Acknowledgement with a comment, held in history. Who acknowledged, when, and what they did: the raw material of every useful post-incident review.
• Alarm analytics. Can it show your top ten most frequent alarms this month? That one report starts every successful rationalisation exercise, and a surprising number of platforms make it hard.

The discipline is borrowed from process industries, where alarm flooding is consequential enough to be codified. The reference framework is ISA-18.2 . You do not need to implement it formally in a commercial building, but its central idea transfers exactly: every alarm should require a distinct operator response, and anything that does not is not an alarm, it is an event, and belongs in a log.

5. Trend logging, retention and export: the capability discovered missing too late

This is the section I would read first if I only had time for one. In advisory work the most common late-discovered gap in a BMS is not graphics or alarms. It is that somebody wants to do analytics, answer an energy question, or investigate a comfort complaint from six months ago, and finds the data is not there or cannot be got out. The failure has several standard shapes:

• Trends were never enabled. Logging is off by default on most platforms and configured point by point. If the commissioning scope did not say which points to log, a fraction of what you assumed is recorded.
• Retention is short or circular. Controller-resident buffers are small and overwrite. If the supervisory historian is not collecting them on a schedule, your history is days, not years.
• Sample interval is too coarse. Fifteen-minute samples suit energy totals and are useless for diagnosing valve hunting or short cycling. Interval is a per-point decision and must be specified.
• Export is manual and screen-limited. A comma-separated dump of what is on the chart is not data access. You need bulk, scriptable, by-date-range extraction.
• The database is proprietary and undocumented. The data exists, on your server, and you cannot read it without the vendor's tool.

So the questions to put, in these words: which points are logged by default and which require configuration; how long is data retained at what interval; is there a documented database or API route to bulk history; and can you demonstrate exporting one year of one point at one-minute resolution right now. That last one is the whole section compressed into a single request, and the response to it is diagnostic.

None of this matters until it does, which is why it gets deferred. But every analytics and fault-detection initiative is built on trend history, and no platform can retroactively create data it did not record. If energy optimisation, fault detection or analytics is anywhere in your five-year plan, the trend and export capability is not a nice-to-have in this evaluation. It is the constraint that decides whether that plan is possible.

6. Multi-site, remote access and the architecture question underneath it

A single building with a workstation in the plant room is a solved problem. An estate is where supervisory architectures diverge, and where the licensing model starts to matter as much as the features. Three broad patterns:

• Independent systems per site. Each building has its own supervisory server, and central oversight means logging into each in turn. Simple and resilient, but past a handful of sites nobody does it.
• Central server, remote sites. One system reaching across the network to controllers at each site. Gives genuine estate-wide views, alarms and trends, but makes the network a dependency and concentrates the failure.
• Hosted or cloud supervisory. The supervisory layer runs off-premises with a gateway at each site. Removes server maintenance, and introduces a subscription, a connectivity dependency and questions about where your data lives. Treated properly in cloud BMS and building management as a service.

Most products claim all three, so the questions that separate them are about the consequences:

• Is there a genuine cross-site alarm console and trend comparison, or a launcher that opens each site separately?
• When the WAN link drops for a day, does the site buffer and backfill, or is there a hole in the record?
• How is remote access provided? A browser client over a VPN is manageable. A vendor-hosted tunnel with a permanently open path into your control network needs security sign-off, not an IT afterthought. See BMS cybersecurity for connected buildings.
• How does licensing count? Per point, controller, site, concurrent user, named user? This is where the estate-wide total diverges sharply between products that looked similar on one building.

7. User roles, permissions and audit

The default state of a great many BMS installations is one shared login with full engineering rights, known to everybody including the contractor who left years ago. It is convenient, and it means you can never establish who changed a setpoint. What a serious supervisory product should give you:

• Role-based permissions with real granularity. View-only, operate within limits, full operate, engineering, administration, and scoped by area so a tenant's team sees their floors and nothing else.
• Setpoint limits enforced by role. An operator who can move a zone setpoint within a bounded range is more useful, and safer, than one who either cannot touch it or can set anything.
• Directory integration. Accounts tied to your corporate directory, so a leaver loses access on leaving rather than when somebody remembers.
• A complete, immutable audit trail. Every setpoint change, schedule edit, override, acknowledgement and configuration change, with user, timestamp, old and new value. Retained for years, exportable, not clearable by a normal user.
• Override accountability. It should answer "who put this valve in hand, when, and did they say why" without guesswork.

The audit trail is what converts the BMS from an operational tool into evidence. For regulated environments, tenant disputes, energy performance claims and incident investigations, an unattributable change history is a real liability.

8. Integration interfaces: BACnet, API and database

Sooner or later something outside the BMS needs to talk to it: a CAFM or CMMS raising work orders from alarms, an energy platform pulling meter data, a tenant billing system, an analytics tool. The supervisory layer is where that happens, and the available routes have very different characteristics.

The practical point: live values and history are different integration problems, and a product can be good at one and poor at the other. BACnet gives excellent live access and, in most implementations, no useful bulk history route. If your integration is "raise a work order when a critical alarm fires", BACnet or an API is enough. If it is "analyse a year of chiller performance", you need the history route, and that is the one most often missing. Establish which you need before the demo, not after the contract.

9. The upgrade and obsolescence path, where the real money sits

BMS lifecycles are measured in decades, and controllers routinely run for twenty years. The supervisory software will not: it depends on an operating system, a database engine, a browser technology and a licensing server, and all four will be out of support long before the plant is. This is the largest cost driver in a BMS and it is almost never examined during selection, because it sits outside the capital budget the evaluation is attached to. What to establish, in writing, before you buy:

• The version history and support policy. Release cadence, support window per version, and what actually happened to customers on versions from ten years ago.
• What a major upgrade involves. Do graphics migrate or get rebuilt? Does trend history carry across? Do existing controllers stay supported, or does the software upgrade force a hardware programme?
• The backward compatibility record. A current version that still speaks to controllers three generations back has demonstrated something a roadmap cannot promise.
• Perpetual or subscription, and what lapsing means. If maintenance lapses, do you keep running, lose upgrades only, or lose function? Get that from the licence terms, not the salesperson.
• The operating system dependency. A product that only runs on a Windows version approaching end of life is a migration project you have not been told about.
• Discontinued product lines. Ask which supervisory products the vendor has discontinued in the last decade and what those customers were offered. Every major manufacturer has done it; the informative part is how.

The pattern to guard against hardest is a software upgrade you need for a security patch obsoleting controllers that work perfectly well. That converts a maintenance item into a capital programme, and it is how BMS estates end up running unsupported software for years, which is precisely how they end up compromised. The maintenance, servicing and lifecycle piece covers the ongoing side of this.

10. The systems-integrator dependency, which you are also selecting

A BMS platform choice is inseparable from a delivery partner choice, and in my experience the partner determines more of your day-to-day satisfaction than the product does. The same platform, engineered by a careful integrator with disciplined naming conventions and graphics standards, and by a rushed one working to the lowest tender, produces two systems that do not resemble each other. So evaluate both, and ask the partner questions the datasheet cannot answer:

• How many organisations can service this system in your market? One authorised branch is a monopoly with a contract wrapped around it. Three or more independent integrators holding the tool and the training is a competitive position.
• Who owns the engineering database and the source? Controller programs, graphics sources and configuration backups must be contractually yours, delivered in usable form at handover. Put it in the specification. Systems where the only copy of the graphics source sits on a contractor's laptop are commonplace and indefensible.
• What can your own team do without a call-out? Setpoints and schedules, certainly. Add a trend? Edit a graphic? Add a user? Define the line, and price the training that moves it.
• What is the response model, and who answers at 2am? A local engineer or a ticket queue in another time zone.
• Can you speak to two clients with systems three or more years old? New installations always look fine. Ask about year four.

11. The capability checklist

Issue this to shortlisted vendors, requiring each line answered as standard, configurable, chargeable or not available, and anything marked standard demonstrated.

12. A scoring approach, and the scripted demo that does the real work

Weighted scorecards are easy to fool yourself with, so use one but keep the evidence column stricter than the score column. The weighting below reflects where I see regret concentrate, not where evaluations usually spend their attention.

The scripted demo

The vendor demo, left to the vendor, shows a polished sample building and a rehearsed path through it. It is designed to avoid the awkward parts, and it succeeds. Replace it with a script you write, run against your own material, with your own operator at the keyboard. Send it in advance so the vendor can prepare: the point is not to ambush anybody, it is to make the demonstration about your work rather than theirs. A script that has served well, timed at roughly ninety minutes:

• Build one of our graphics. We supply one real AHU schematic and its points list in advance. Show the finished page, then your engineer adding a point to it while we watch, and tell us honestly how long the page took.
• Navigate it cold. Our operator drives. From the home page, find that unit's supply air temperature, change the setpoint, and find the last time it was changed and by whom.
• Change a schedule. Add a public holiday exception to one zone, in the operator role, with no engineering tool open.
• Configure an alarm end to end. High supply air temperature, priority two, five-minute on-delay, two-degree deadband, suppressed when the fan is off, routed to one recipient list in hours and another out of hours. Trigger it, then show the acknowledgement and history entry.
• Show a real alarm list. Not the demo system. A three-year-old customer site, top twenty alarms by frequency, name redacted. If it cannot be produced, note that.
• Export a year of data. One analogue point, one-minute resolution, twelve months, to a file we take away. Then the same by script or API rather than by hand.
• Integrate a stranger. A BACnet controller from another manufacturer, discovered, graphed and trended, during the session.
• Break the link. Disconnect the site for ten minutes. Show what the controllers keep doing, and the trend record backfilling on reconnection.
• Create a restricted user. A role that sees two floors, can move zone setpoints two degrees and no further, and cannot touch anything else. Log in as them and prove the limits hold.
• Produce the audit trail. Export everything the session just did, with users, timestamps, old and new values.

Every item on that list is something a competent platform and integrator can do inside a demonstration, so the value is in the pattern of what gets deflected. In my experience the deflections cluster in two places: the year of data at one-minute resolution, and the real customer alarm list. Those two requests tell you more than the rest of the evaluation combined.

If you want a template for turning the checklist and scorecard into a document vendors must respond to line by line, the structural approach in how to write a CAFM RFP transfers almost directly; only the requirement content changes.

The idea to walk away with

The supervisory software is a distinct purchase from the control system beneath it, with a different failure mode, a different lifespan and a different cost profile, and it deserves its own evaluation. Judge it on four things above all: whether an operator will actually use it, whether the alarm list will still carry information in three years, whether you can get your own history out in bulk without asking permission, and what happens when the version you buy reaches end of support. Features below those four are largely comparable across serious platforms; those four are where outcomes diverge, and they are the four that vendor demonstrations are built to skate over.

The corollary is that the evaluation is mostly a matter of insisting on demonstration rather than description. Every important claim in this category can be shown in under ten minutes on a live system, and asking for that, politely and in writing, is the whole method.

Final thoughts

BMS procurement has an unusual asymmetry: the decision is made by a project team measured on capital cost and handover date, and the consequences land on an operations team measured on comfort complaints and energy, fifteen years later, when nobody from the project is still in the organisation. That is why obsolescence paths and data access go unexamined, and why they are where regret concentrates. If the operations team is not in the evaluation, the evaluation is incomplete however thorough the scorecard looks.

None of this requires deep controls expertise. It requires a clear boundary between the two layers, a checklist you hold to, an insistence on live demonstration over datasheets, and a willingness to ask the unwelcome questions about discontinued products and upgrade histories while you still have commercial leverage. Once the contract is signed, those answers cost money instead of nothing.

Related reading: Building management systems: a complete guide, Siemens vs Schneider vs Honeywell vs Johnson Controls, BMS specification clauses, BMS commissioning, graphics and operator dashboards, BMS energy optimisation, FDD and analytics, Cloud BMS and building management as a service.