The data point
nobody asked for

Why points lists keep growing from one project to the next — and how to build them the other way round.

The document nobody owns

In a building automation package, the points list is the most decisive and least discussed document. It fixes the hardware, the cabling volume, the number of supervision licences, the integration time, the commissioning effort and, for the next twenty years, what the operator will be able to see of the building.

And yet, in most projects, it has no author. It has an origin: the previous project. The file is reused, the designations are adapted, the new equipment is added. Almost nothing is ever removed — removing something requires a justification, keeping it requires nothing.

So the document grows with every round, and nobody ends up in a position to say this point is of no use.

What a useless point costs

A superfluous data point is not neutral. It costs money in five distinct places.

• At purchase. A physical input or output takes a terminal, space in the panel, cable, and an expansion module as soon as a multiple of eight or sixteen is crossed. Adding one more module costs far more than the point itself.
• In licensing. Most supervision platforms are licensed per point. The tiers are commercial, not technical: crossing a threshold of 250, 500 or 1,000 points triggers a price jump with no functional gain whatsoever.
• In integration. Every point has to be addressed, named, scaled and tested. The unit time looks negligible; multiplied by several hundred, it becomes a significant share of the integration line in a tender.
• In operation. This is the highest and least visible cost. A supervision screen that shows everything shows nothing. Unused points dilute the useful ones, lengthen the navigation trees, and — when alarmed by default — produce an alarm noise that ends up being ignored as a whole. An alarm list the operator no longer reads is an installation without supervision, however many sensors it has.
• In documentation. Every point appears in the schematics, the test records, the EDE export, the naming convention. Everything that serves no purpose still has to be kept up to date at every modification — or become wrong, which is worse.

The missing points are always the same ones

That is the paradox: these lists are at once too long and incomplete. The same omissions recur from one package to the next.

• Actual running status rather than the command. Knowing that the pump has been told to run is not knowing that it runs. A status feedback or a flow measurement changes the nature of the information.
• The effective position of the control device rather than the setpoint alone. Without it, a stable control loop cannot be told apart from a valve stuck at its end stop.
• Hour-run counters and start counters on rotating equipment. These are the cheapest predictive-maintenance data in the building: they cost nothing but a software variable.
• Return temperatures of the distribution circuits, essential to judge a heat pump, a condenser or a heat exchanger — and systematically sacrificed in favour of flow temperatures.
• Individual faults instead of one grouped fault per panel. A grouped fault turns a two-minute diagnosis into a site visit.
• Sub-metering split by end use rather than by electrical panel, the only way to tie a consumption figure to a decision.

None of these data points comes out of the controller catalogue. All of them come out of an operational question.

Reading the list the other way round

A points list should not answer the question what can this installation measure? but the question what do we need to know in order to operate it, tune it and bill it?

In practice, you do not enter the document through the equipment. You enter through the operational functions, and for each function you run through five questions:

1. What decision or action does this function trigger?
2. Which quantities are strictly necessary to trigger it?
3. Who reads those quantities — operator, maintenance technician, energy accountant, the control loop itself?
4. How often, and with what history? A value read once a year does not need the same treatment as an alarm value.
5. What happens if it is missing or wrong? That answer is what justifies redundancy, an alarm, or on the contrary a deletion.

A point that cannot be tied to a function does not enter the list. Nor does a point tied to a function but with no identified reader.

The matrix to reuse

The table below is the one we annex to our specifications. It is filled in together with the building owner and the operator, before any call for tenders.

Three columns do all the work: Reader, If missing or wrong and Alarmed. A row without an identified reader is deleted. A row whose absence has no consequence is deleted. A row alarmed by default with no known handler loses its alarm.

Writing it into the tender

A good points list is worthless if it binds nobody. Four provisions are enough to make it contractual.

• Annex the list to the specification, sorted by operational function rather than by panel, with the Reader column visible to the bidders. It then becomes a design document, not a bill of quantities.
• Forbid points with no attached function. Additions proposed by the integrator are welcome, provided they are documented in the same matrix.
• Require an EDE export matching the list at handover. It is the only way to verify objectively that what was installed corresponds to what was ordered — and to take the installation over later without starting from scratch.
• Reuse the list in the functional test record, function by function. You do not test points, you test functions; the matrix provides the structure of the protocol directly.

What it changes

The most immediate effect is budgetary: fewer inputs and outputs, one licence tier less, fewer integration hours. But that is not the main point.

The main point is that an installation where every data point has an identified reader is an installation somebody actually looks at. Drifts become visible, faults get handled, optimisations can be proven. Conversely, an over-instrumented building whose supervision nobody reads is exactly as blind as a building with no automation at all — with the invoice on top.

The question was never how many points to install. It is who reads them.