Technology · Recommendations for new buildings
Recommendations for new buildings
If you are building new, you are right now making a number of choices that decide how easy or how expensive it will be to use the building's data in five years.
None of it is complicated or expensive to get right. But it has to be decided early, and it has to be required of the right parties.
None of this is technically hard. It is hard because it has to be decided before anyone misses it.
01Cheap now, expensive later
A modern building produces large amounts of data all by itself. The problem is rarely that the data does not exist. The problem is that nobody can see what it is about.
An electricity meter showing 12,480 kWh is not information. It becomes information when it is written down somewhere what the meter measures, which panel it sits in, and which area it serves.
A meter with no note of what it measures is a number that counts. That is not the same as knowledge.
It used to be a large job to map those connections afterwards. Today much of it can be done automatically, but only if the material hangs together.
The good news is that almost everything below costs nothing extra if it is in the tender. It costs a great deal to change once the building has been handed over and the people who knew have moved on to the next project.
The requirement texts below are written for Danish tender documents. The Danish version of this page has them in Danish, ready to paste.
02For the ICT consultants: the project material
The first requirement is not about technology but about language. The same thing has to be called the same everywhere.
An electricity meter should have the same number whether you look at the single-line diagram, the panel drawing, the equipment list or the building management documentation. It sounds banal. It is banal. And it is still surprisingly hard to enforce when the material comes from five different parties.
The second structure is the supply areas. It should be possible to see which system serves which room, without anyone following a heating pipe across a floor plan. Colour-coded areas per system solve it on one sheet.
Then the building model. An IFC model is a goldmine for both people and software, but only if rooms and systems are classified correctly and match the rest of the project. See IFC and building models.
For the specification
One consistent ID structure is used for all technical systems, components and meters. The structure is determined by the client at the start of the project and used unchanged in all deliveries, including deliveries from co-designers and sub-contractors.
The same ID is used in single-line diagrams, panel drawings, equipment lists, floor plans, the building model and the building automation documentation. The client appoints a responsible person who checks at each handover that the structure has been followed.
The project material must show unambiguously which systems and meters serve which areas and rooms. This is documented with floor plans where supply areas are colour-coded per system.
Building models are delivered in IFC and must match the rest of the project material. Rooms and technical systems must be correctly classified and uniquely identifiable by the project's ID structure.
03For the automation contractor: the protocols
Most building management systems use their own protocols internally, in whole or in part. There is nothing wrong with that, and it is rarely worth fighting.
Almost all of them also support BACnet/IP, which is open and standardised. The requirement should therefore not be about what the system does internally, but about what it makes available to the outside.
It is fine that the system speaks its own language at home. It just has to be able to talk to the neighbours too.
The same goes for the other technical systems. Central lighting control, solar shading and metering have exactly the same problem, and they are often forgotten because they do not belong to the building management contract.
Then the point list. It is cheap to require at handover and almost impossible to obtain afterwards. See Protocols.
For the specification
All data points must be exposed on BACnet/IP. This also applies to systems that use vendor-specific protocols internally, and to the other building services systems, including central lighting control, solar shading and metering.
The points must be readable and interpretable without the vendor's involvement and without the use of vendor-specific tools.
As part of the handover, a BACnet point list is delivered, stating for each point:
- object name and object identifier
- object type
- unit
- a short description of what the point measures or controls
The naming of the point must follow the project's ID structure, so that the point can be attributed unambiguously to the system and component it belongs to. Device instance numbers are assigned according to a plan determined by the client and must be unique throughout the building.
04For electrical and IT: the technical network
The technical network is the discipline that most often has no owner. The electrical contractor pulls the cables, the automation contractor puts the equipment on them, and the client's IT department only finds out when someone asks for an internet connection.
The result is a network that has grown system by system. It works, right up until it does not.
The requirements here are not advanced. They are about the equipment being manageable, standing somewhere that is locked, and there being a drawing of it afterwards. See Technical network and IT security and data.
For the specification
The technical systems are connected through a dedicated technical IP network, which is either physically separated from the rest of the building's network or established as a separate VLAN.
Technical systems are as a rule connected directly to managed switches. The use of unmanaged switches or daisy-chained controllers may only occur inside panels and must be stated in the documentation.
Central switches are placed in locked technical or server rooms. Unused ports are disabled at handover.
At handover, network documentation is delivered, covering:
- network topology and VLAN division
- IP plan with fixed addresses for controllers, gateways and meters
- an overview of which device is connected to which port
- the connections opened between networks, and the reason for each of them
05For the client: what nobody else can decide
Three things no consultant or contractor can decide on your behalf, because they are about what you want to own afterwards.
Who owns the network architecture? There has to be one function with the overview of the IP plan, the division and which systems may talk to each other and to the internet. It can be your own IT department, an operations organisation or an external partner. What matters is that there is one.
Where does the data live, and who can retrieve it? Deciding that operational data is collected and stored locally in the building is also deciding that access to the history does not depend on a subscription payment. See Edge server and architecture.
What happens when the contract ends? It is a question that is easy to answer while the contract is still being written, and embarrassing to ask three years later.
For the specification
The client appoints one person responsible for the architecture of the technical network, including the IP plan, the network division, firewall rules and which systems may communicate with each other and with the internet.
Operational data is collected and stored locally in the building. The building owner has full and continuing access to both raw data and history.
The data collection must as a minimum ensure:
- consistent time stamping with a common time zone, so that data from different systems can be compared
- a resolution matching the purpose of the point, and meeting applicable requirements for data collection
- history kept for an agreed period and in an open, documented format
- backup of both data and configuration
The building owner must be able to export the data themselves, in an open and documented format and without the use of vendor-specific tools. Interfaces to the data must be documented.
On termination of the contract, data, configuration and documentation are handed over to the building owner in a format that can be read without the vendor's involvement.
06The test that reveals everything
There is a cheap test that catches most of it, and it can be run long before handover.
Find someone who has not been involved in the project. Give them the material and three questions:
- Which air handling unit serves room 2.14?
- Which electricity meter measures the kitchen?
- What is the room temperature sensor in room 2.14 called in the building automation system?
If it takes more than ten minutes, the explanation is rarely that the person is too slow.
The test is not a check of the material. It is a dress rehearsal for every operational task over the next thirty years.
Run it at concept design, at detailed design and again at handover. The three runs cost half a day in total, and they are the closest thing there is to insurance against the documentation only becoming a problem when it has to be used.
07In short
Four requirements to four parties, and the rest follows:
- The ICT consultants: one ID structure all the way through, colour-coded supply areas, and an IFC model that matches the rest.
- The automation contractor: every point on BACnet/IP, and a point list with unit, type and description.
- Electrical and IT: a dedicated technical network on managed switches in locked rooms, and a drawing of it afterwards.
- The client: one person responsible for the network, data stored locally in the building, and an agreement about what happens on termination.
None of it requires you to know what you will use the data for. That is exactly the point: these requirements are about keeping the option open, not about choosing a solution.
Shall we look at your tender material?
Book a 45-minute meeting. We look at what you have and tell you what is missing.