Protocols

01Our starting point for choosing protocols

The goal is not for every system in the building to speak the same language.

A modern building will normally consist of several different communication layers. Some protocols work well between main systems and controllers, while others are developed specifically for lighting, meters or other field components.

The important thing is that the architecture is transparent, well documented and makes data accessible without unnecessarily tying the building owner to one vendor.

IP-based communication makes a good overall integration layer

Between main systems, controllers, gateways and data platforms, IP-based communication normally makes good sense. It makes the systems easier to connect, segment, monitor and integrate with other IT systems.

In classic building automation, BACnet/IP will often be an obvious choice, because the protocol was developed for building automation and is supported by many different vendors.

That does not mean all communication on the technical network has to be BACnet/IP. Modbus TCP, system-specific APIs and other IP-based interfaces can also be relevant.

But if you later want to be able to exchange data, for example with CX2, it is sensible to require one particular protocol. CX2 recommends BACnet/IP. In a new building that requirement belongs in the tender material, see Recommendations for new buildings.

Serial protocols have a natural place

Closer to the field equipment, serial bus systems are widespread and can be both simple and economical. DALI-2 for lighting and Modbus RTU for controllers, VAV dampers, meters and other technical components are examples of protocols often found at this level.

Running Ethernet all the way out to every sensor, actuator or meter is therefore not a goal in itself.

Sub-meters are a good example. Every building has a number of them, some used for billing and cost allocation, others for operational monitoring. M-Bus was developed specifically for remote reading of meters and is therefore a natural choice for heat, water and energy meters, particularly when many meters are to be gathered into a proper meter network.

The bandwidth, on the other hand, is limited. If the same bus serves many meters, the update rate can become so slow that it undermines the usefulness of the data when you need high resolution for operational analysis. Modbus RTU is very widespread in electricity meters and is also found in heat meters. It is possible in water meters, but rarely the cheapest solution.

Serial buses do have properties worth being aware of. Several components typically share the same bus and cabling. A fault in a cable, in the termination, in the addressing or in a single component can therefore affect communication with several devices, and take longer to locate than a fault on an individual IP connection.

How critical the function is should therefore also be part of the choice of architecture.

02Wireless communication can be the right choice

Wireless communication is particularly interesting where data volumes are limited, where the devices can work with relatively low update rates, or where cabling would be disproportionately expensive or difficult.

That can be, for example:

• sub-meters
• temperature and humidity sensors
• indoor climate sensors
• status and monitoring points
• sensors in existing buildings where new cables are hard to install

For meter collection and simple IoT purposes, both Wireless M-Bus and LoRaWAN are relevant technologies.

Wireless M-Bus

Wireless M-Bus is closely tied to the metering world and is available as a communication option in many meter products. If the task is primarily wireless reading of heat and water meters, Wireless M-Bus can therefore be a natural choice.

LoRaWAN

LoRaWAN is oriented more broadly towards IoT and can be used for many different types of sensors and devices. It can therefore be interesting if the same wireless network is to serve more purposes than meter reading alone.

There can be meters, temperature sensors, humidity sensors and other simple sensors on the same LoRaWAN infrastructure.

LoRaWAN can also be used actively, not only for reading. A relay on a LoRaWAN module can for instance cut the power to equipment outside working hours, so the standby consumption disappears, without pulling any new cables.

04IP-based and serial communication

The difference between IP-based and serial communication is not only about speed. The two architectures have different properties.

IP-based communication

An IP device is normally connected individually to the building's data network and can be identified and communicated with through the network infrastructure. That allows for:

• an individual connection to devices and controllers
• network segmentation
• central monitoring
• flexible communication between systems
• integration with servers and software platforms

In return it puts greater demands on coordination between automation and IT, including IP addresses, VLANs, firewall rules and access arrangements.

The fact that a protocol uses IP does not in itself mean that the communication is secure or encrypted.

Serial communication

On a serial bus, several devices typically share the same physical connection. That is the most economical solution, especially close to the field equipment.

In return the topology becomes more dependent on correct cabling, termination and addressing, and fault finding can be harder when many devices share the same bus.

We therefore do not see IP and serial communication as two alternatives where one should necessarily replace the other. They can be used to advantage at different levels in the same building.

05Open and proprietary interfaces

An open or standardised protocol typically makes it easier for different products and vendors to communicate. It can give:

• less vendor dependency
• easier integration across systems
• more freedom when products are replaced later
• better scope for using the data in third-party systems

But an open protocol does not automatically mean a good integration. The implementation matters at least as much. A BACnet system can be hard to integrate if the objects and metadata are poorly structured. Conversely, a vendor-specific API can be well documented technically and work well.

The essential question is therefore not only whether the protocol is open.

Does the building owner have stable and documented access to their data, also if the vendor is replaced later?

Local data exchange is attractive as a starting point, because it reduces dependency on external services. Cloud-based integrations can be necessary where the systems do not offer local exchange.

06Encryption and security

Many protocols in building automation were developed at a time when the technical network was regarded as a closed environment. They do not necessarily have built-in encryption or modern authentication.

Newer technologies can support encrypted communication to a greater extent, but security should not be judged from the protocol alone. Overall security also depends on:

• network segmentation
• firewall rules
• access control
• how remote access is handled
• updating of devices and software
• documentation of connections
• separation between data processing and critical building automation

An encrypted protocol can be an advantage, but it does not replace a well considered network architecture.

What that architecture looks like in practice is covered in Technical network and IT security and data.