Technical
There is a simple test for a supervision tender. Take the document, strike out every mention of a brand, and ask yourself how many suppliers can still answer it honestly. If the answer is one, the competition is decorative: the two other bids will serve to justify a decision already made, and the building owner will pay, for fifteen years, a price that was never negotiated.
This is almost never deliberate. It is the result of a sequence. Supervision is often the last package addressed in an automation project, at a point where the programme is tight and a product datasheet is the only available document that describes functions in concrete terms. It gets copied, it gets called a specification, and the tender closes in on itself.
One ambiguity has to go first, because it poisons any comparison of bids: the supervision layer controls nothing. Control runs in the controllers and the local regulators, and it must keep running with the server switched off. Supervision is the layer above: graphics, alarms and their acknowledgement, trend curves and historical data, schedules and calendars, setpoints, user management, reports, remote access.
That boundary is not theoretical. If it is not written down in black and white, one bidder will price a supervision system that displays and another one that drives sequences — and the second will be more expensive for good reasons, with no way for anyone to demonstrate it at award stage. The split belongs in the responsibility and demarcation matrix, drawn up before pricing, not during.
The licence line attracts all the attention because it is the only visible figure when the bids are opened. Over the life of the installation, it is rarely the dominant one.
What dominates is the unit cost of every future change. Adding a floor, renaming a zone, creating a view, extracting three years of data for an energy audit, correcting a graphic after a floor is refitted: these jobs come round every year for fifteen years. Their price does not depend on the product selected. It depends on a single question, and the tender has to answer it: can the operator have this work done by someone other than the company that installed the system?
The answer sits in five clauses.
Licences. The exact model must be imposed, not described: number of points, number of concurrent client sessions, named or concurrent users, perpetual licence or subscription, cost of the annual software maintenance agreement and its indexation formula, price of the next expansion tier. And above all the holder: the licence must be issued in the building owner’s name, be transferable, and the certificates handed over at acceptance.
Protocols, on the client side. “BACnet compatible” says nothing about the side that matters, and we have set out elsewhere why the word guarantees nothing. What must be required is the PICS of the supervision workstation, the target device profile, the supported BACnet revision and the list of services actually implemented — reading and writing properties, COV subscription, event and notification handling, reading device-resident trend logs, writing to schedule objects. The same applies to Modbus, KNX, MQTT or OPC UA where they are present.
Engineering data. Native project file, a complete cross-reference table between supervision points and field points, the naming convention applied, an ETS project without password protection for the KNX part, Modbus register tables, controller backups. These are contractual deliverables, due at acceptance exactly like a schematic.
Historical data. Format and location of the database, read access by a third party, retention depth, the aggregation rule over time, a normalised export or a programmable interface. Without this clause the building’s consumption data belongs, in practice, to the product that stores it — and the first serious energy audit turns into a chargeable service.
The engineering tool and the rights. Who can modify a graphic, add a point, change an alarm threshold? If the configuration tool is only available under a manufacturer partnership agreement, the operator is locked in whatever protocol openness is advertised. The tender must state the level of rights handed to the operator, the training that goes with it, and how the tool is obtained. At bottom, this is the question of who really holds the keys to the building.
A requirement only exists if failing it can be established at acceptance. The table below sets out the most commonly encountered wordings and what to replace them with.
| Intention | Common wording, unenforceable | Enforceable wording |
|---|---|---|
| Openness | “Open system, BACnet compatible” | PICS supplied with the bid, profile and revision required, services listed, interoperability test with a third-party client during acceptance |
| Ownership of the system | “Licences included” | Licences in the building owner’s name, transferable, certificates and keys handed over at acceptance |
| Expandability | “Expandable system” | Unit price of an additional point and of the next licence tier, committed for five years, carried in the pricing schedule |
| Documentation | “Full documentation” | Itemised list of deliverables, native source files, ETS project without password, controller backups, handed over before final payment |
| Data | “Trend logging of measurements” | Database readable by a third party, depth and aggregation defined, normalised export demonstrated at acceptance |
| Cybersecurity | “Secure system” | Named accounts with no shared account, patching policy, no service exposed to the internet, IEC 62443 principles applied to the perimeter |
| Acceptance | “Commissioning and testing” | Individual tests, then integrated functional tests against the points list, with a record signed point by point |
None of these wordings names a product. All of them are verifiable. That is precisely what makes it possible to receive three different bids and compare them.
A supervision tender prices badly because its line items are not naturally homogeneous. Imposing the structure of the pricing schedule — and forbidding undivided lump sums — is what makes the bid opening usable: server hardware and client workstations, licences broken down by type, graphics engineering by number of views, integration by number of points and by protocol, commissioning, training in hours, documentation, then the annual maintenance agreement with the services it includes and its response times.
The maintenance agreement deserves to be requested with the bid rather than negotiated after award. Discussed once the system is installed, it is negotiated with the only possible counterparty.
The revision of Swiss public procurement law moved the emphasis from the lowest price to the most economically advantageous bid. That still requires the award criteria to be published with their weighting, and to be scored against documents the bidder actually produces.
For a supervision system, the criteria that really discriminate are the degree of openness demonstrated by the documents supplied, the whole-life cost over the period considered — licences, maintenance and expansions included —, the availability of alternative maintenance providers on the market, references on comparable installations that have been in operation for several years, and the quality of the takeover of the existing system where there is one.
Explicitly allowing a variant bid is often the best investment in the whole procedure: it lets architectures surface that the specification had not considered — provided you have decided beforehand which requirements are not negotiable.
It does not remove dependency, it moves it. An operator who obtains the licences, the source files and the engineering tool remains dependent if there is nobody in house able to use them: the training clause and the level of competence targeted are part of the arrangement, otherwise the deliverables stay in a drawer.
Nor does it guarantee interoperability from reading documents alone. A compliant PICS has never proved that one system talks correctly to another. Only a real integration test, during acceptance and on the real points, demonstrates that — which is why it has to be written into the tender, with the time and the access needed to carry it out.
Finally, it assumes preparatory work that is not in the tender itself: the points list and the responsibility and demarcation matrix. Without them there is no basis on which to price an integration, or to sign an acceptance record.
The supervision vendor describes its product — that is its job, and it does it well. The integrator answers what it is asked. The general contractor wants the package closed within the time it was given. None of these parties has any reason to write a document that increases the number of competitors able to answer it.
That is the role of an independent engineering practice: to write down what the building must obtain, before the market decides what it will get. At Workswell we write tenders for BMS supervision and integration, we produce the points list and the demarcation matrix that make them priceable as part of MCR/BMS design and planning, we assess the bids against a scoring grid set before opening, and we run the functional acceptance under owner’s engineering. We sell neither licences nor integration — and we hand the documentation, the licences and the control of the installation to whoever operates it, every time.
In public procurement, no: the specification must be technology-neutral, and a reference to a product is only admissible as an indication, together with wording that allows an equivalent. In the private sector it is possible — but it amounts to giving up competition, voluntarily, on the longest-lived item in the installation.
Both approaches can be defended. A single package simplifies responsibility when something goes wrong; two separate packages preserve competition on supervision and make it easier to replace later — provided the boundary between them is specified precisely and the exchange protocols are imposed.
By imposing a common reference scenario in the pricing schedule: number of points, number of client workstations, number of users, calculation horizon, and the expansions to be priced. Each bidder prices its own model against that scenario, and the totals become comparable again.
A survey of what is there, before anything is written: protocols actually in service, controller revisions, points genuinely wired against points documented, current licences and who holds them. That is the purpose of a preliminary MCR/BMS audit. Taking over an existing system is the line item that spreads bids furthest apart, and the only way to make it priceable is to document it in the bidders’ place.
Also worth reading
It is not a question of competence, still less of honesty, but of position. For whoever programmed the installation, observed operation is the intent — and an audit is precisely the exercise of telling the two apart.
Placing one master on each floor instead of grouping all three in the panel takes the powerline out of the risers. Same hardware, same catalogue limit, a radically different installation.
Two devices that are both “BACnet compatible” can still work together very poorly. Two documents, requested before you place the order, save weeks of rework at the end of the site.
A first conversation is usually enough to define the potential and the scope of the mandate.
