This article is part 1/2 about the protocols, gateways, and data transmission methods (as well as wireless protocols) relevant in building state monitoring. But let's first start with the philosophy behind it all, which is mainly based on manufacturer independence and open systems.
As keywords, manufacturer independence and open systems have been a central topic in the field of building automation and building state monitoring for years. More and more suppliers are offering systems with standardized communication, such as the very popular BACnet. Products that conform to a standardized protocol enable the interoperability (connection) of different automation devices with little effort.
i😵 BACnet ... is a crucial network protocol for building management and automation. It stands for Building Automation and Control Networks and ensures interoperability between equipment from different manufacturers, on condition that all partners involved in the project agree on certain BIBBs defined by the standard. A BIBB – Interoperability Building Block – defines which services and procedures must be supported on the server and client side to realize a specific requirement of the system. The Protocol Implementation Conformance Statement (PICS) document associated with a device lists all supported BIBBs, object types, character sets and communication options.
The main focus of building state monitoring is, of course, a very practical one: it's all about
and much more. In addition to all these practical aspects, which we will not go into now, there are numerous technical interrelationships and also challenges that one should be aware of.
It is important to note that until relatively recently, there was no genuinely standardized industrial network protocol for building automation, and users had to choose between many different systems from multiple manufacturers. Proprietary communication was a consequence of the fact that there was no off-the-shelf communication approach. Today, we have reached a point where there are actually three interoperable standard network protocols to choose from. In addition to BACnet, which has already been discussed, there are Modbus, LonWorks, M-Bus, and others. All those protocols are widely used.
i😵 Modbus, LonWorks, and M-Bus The Modbus protocol was created for communication with programmable logic controllers. It's a communication protocol based on a master/slave or client/server architecture. I don't even want to go into the technical details of the Modbus protocol (including correlation with PRTG), as our founder Dirk Paessler has written an article about it that is hard to surpass. LonWorks (local operating network) as a communication network protocol is also useful for building automation applications and particularly designed for low bandwidth to network devices over power lines, fiber optics and other media. M-Bus (meter-bus) is a European standard for the remote readout of consumption meters (heat, gas, etc.) in homes and buildings. Don't get it confused with wireless M-Bus, which is not discussed here.
Here is a very concise side-by-side comparison of the four protocols, regarding costs, development, market, standards, and network interfaces:
| BACNet | Modbus | LonWorks | M-Bus |
|
| Costs | No fees | No fees | Costs are relatively high, though proprietary | No fees |
| Development | Starting 1987, ASHRAE | Starting 1979, Modicon (now Schneider Electric) | Starting 1990, Echelon Corporation | In the 1990s, University of Paderborn, in conjunction with Texas Instruments Deutschland GmbH and Techem GmbH |
| Mainly and/ or originally made for | Industrial IT, transportation and energy management sector, building automation and state monitoring | Lighting, HVAC, access controls, transportation and maintenance of any kind |
Industrial IT, transportation, public utility control networks, building automation and state monitoring |
State monitoring (water, gas, heat, and electricity, as well as valves and actuators), alarm systems, illumination systems |
| Standards | ASHRAE, ANSI, and ISO 16484-5 | IEC 61158 | ANSI/CEA-709.1-B; ISO/IEC 14908-1, -2, -3, and -4 | EN 13757-2 physical/link layer, EN 13757-3 application layer, EN 13757-4 wireless |
| 👍 | Open protocol; very user-friendly and widely adopted | Open protocol; de facto protocol in industrial applications; can easily be used over the Internet | Developed as a data protocol and an electrical standard for digital communications | A single cable can link all meters in a building; meters are individually addressable |
| 👎 | Many users must manage several different vendors on one site | Some customers have no choice of whether to use Modbus or not: the hardware constraints require it | It has a lower adoption rate compared to the other protocols, so there’s not the same support community | Data transmission is comparatively slow (2400 baud) and unsuitable for process control |
It's also worth noting that, more because of historical reasons than technical reasons, Modbus is more popular in the EU, while BACnet is more popular in the US.
I would feel bad about not mentioning two other important standards, so here is some brief information about KNX and DALI. KNX was originally created in 1999 as a combination of three previous standards – European Home Systems Protocol (EHS), BatiBUS, and European Installation Bus – it's not used in modern projects so much anymore. DALI (digital addressable lighting interface) is the leading protocol for the control of lighting in building automation. Developed by a group of manufacturers led by Phillips, the protocol was first drafted as an open standard in 2000 as an alternative to DSI (Digital Signal Interface).
This overview obviously didn't show all protocols that might be relevant in monitoring projects you might come into contact with, but it hopefully gives you a good first understanding of the mechanisms in place.
In part 2/2 we'll discuss the topics of gateways and data transmission methods.