The number of connected devices in our buildings is increasing relentlessly. According to our research, the number of connected devices in operation in the commercial smart building will grow from 1.7 Billion in 2020 to just under 3 Billion by 2025 representing a CAGR of 10.8%. Per building, this means a big increase in devices, as each building system demands more visibility and control. It’s not just the number of devices either, but the type of data they produce too, with more and more detail bringing more and more complexity. The amount of data produced is accelerating faster than our ability to manage it and that is a problem as we strive towards better integration for smarter buildings.
Most buildings today operate a siloed approach, with each system vertical gathering the data it requires to run its own applications. Lighting infrastructure gathers occupancy data to recognize empty rooms so it can turn off the lights to reduce energy consumption. HVAC systems also gather occupancy data to adjust heating, cooling, and ventilation levels to match the people in the room. Each system demands more detail in its data, meaning more sensors for each system, and an exponential rise in the number of sensors in the building as a whole. There is clear value in the data of one system for applications in another, meaning there is clear value from integrating systems, but to do that in the accelerating data environment we must redefine the structure of smart technology in buildings.
“The way buildings are built and operated today is based on a siloed, ruled based approach with limited external data access and where systems integration is complex, insecure and non-scalable. It needs to be redefined to enable a secure, manageable and smart ecosystem, and it is argued that creating a technical architecture based on a horizontal layered approach will do just that,” says Sabine Lam, Google Building Operating Systems Global Lead for Real Estate and Workplace Services in an article for Automated Buildings “Horizontal infrastructure is technology agnostic, relies on open standards, open protocols and non-proprietary solutions, and achieves the goal of enabling any device to talk to any application, and vice-versa.”
One horizontal approach gaining traction utilizes Message Queuing Telemetry Transport (MQTT), an ISO standard (ISO/IEC 20922) publish-subscribe, lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. Its core design principles are to minimize network bandwidth and device resource requirements while ensuring reliability and assurance of delivery, making it ideal for M2M or IoT communications. Originally developed by IBM and Arcom (now EuroTech) to monitor oil and gas pipelines running through the desert, MQTT is increasingly being described as a more modern and cloud-centric method of integration than BACnet and could become one of the main protocols for IoT deployments in smart buildings.
“As an event-based protocol with low overhead, MQTT was designed to efficiently handle the high-volume, low-latency requirements of those environments. This means it can send a lot of data quickly without using too much bandwidth and has a smaller footprint than other protocols. All messages are transmitted over a single connection so there is no additional load on the network that would be created by opening multiple connections for each device,” explains Mike Poe of Cognex Corporation. “Not only does this make it very easy to scale from 1 device to a production standard, but it also reduces network strain while adding a security layer that tracks all connections while handling security credentials and certificates.”
Through a horizontal architecture approach, MQTT depends on open standards, open protocols and non-proprietary solutions, in order to allow everything to communicate with each other. The growing device layer of horizontal ecosystems, for example, require open communication and management capabilities like the Universal Device Management Interface (UDMI), a high-level specification schema that connects devices to the cloud in standardized and interoperable ways. In the cloud, data from all devices can be made accessible to applications for any building system to use. However, this creates a large pool of unstructured data, so ontologies are required to ensure any useful data can be found quickly by the requesting application for smooth and intelligent building operations.
Adopting this MQTT-enabled horizontal approach to building data management fundamentally changes the way we operate the IoT in buildings, however, significantly changing the role of Master Systems Integrators (MSI). The role of the MSI includes qualifying security for IoT devices, describing every point of the system in a human-readable data-serialization language, and registering devices and host telemetry data in the cloud, but in a highly integrated horizontal system that all becomes far too complex and time-consuming. For such an ecosystem, MSIs will require both OT and IT skills, to understand the basic building system as well as the IT security standards, networking, and cloud-based protocols a horizontally integrated system demands.
“The concern is that the need for MSIs will be exponential with the increased complexity of building control/IoT systems and the growing number of IP devices,” continues Lam in the article for Automated Buildings. “Today, the MSI is expected to deliver an accurate replica of the physical space in a digital format on the first day of business, but would also be needed throughout the life cycle of the building to properly represent any update made to the building. This is unsustainable, and a high level of automation will be required to ensure consistency, accuracy and scalability.”
A horizontal approach to the IoT, enabled by MQTT and UDMI, makes for smarter buildings but raises a key issue that has been holding back the industry for quite some time —the skills gap. While the technology required for these highly integrated facilities is rapidly developing, the talent required to bring this technology to a wide range of buildings is lagging far behind. Ultimately, however, the MSI will never feasibly be able to manage every aspect of increasingly connected future buildings, for that they will need the support of greater and greater levels of automation.
15 thoughts on “MQTT & the Horizontal Approach to Managing Smart Buildings”
Very nice and informative article. Are there any use cases where 100’s of buildings are starting to become horizontally integrated to manage energy consumption in order to rank building performance in terms of kWh/m2a?? If so, would love to explore collaboration in Asia Pacific in large real estate portfolios.
Thanks, interesting question. My feeling is that use cases are currently limited and where they exist would be 10’s of buildings not 100’s. The obvious place to begin would be with Google who are mentioned in the article and the MSI Buildings IoT.
Very good article, but unfortunately it is over-simplified. MQTT is one enabler, but it cannot be used as a generic mechanism in IoT. There are simply too many standards and too little bandwidth to run MQTT everywhere.
IoT is about LoRaWAN, Narrow-Band IoT, Z-wave, SigFox, ZigBee, BLE, and hundreds more. It’s about mesh networks. It’s about reusing existing investments in BACnet, Modbus, CAN, Wireless M-bus, etc.
Horizontal architecture is the only way forward, and MQTT is an important enabler for this. But, it does not solve all the challenges.
Thank you, useful comment!
MQTT will not fix the issue mentioned here. It will only add a new protocol to the long list already available on the market (bacnetIP, ModbusIP, LON, OPC UA …). In addition, people must know that unlike bacnetIP or LON for instance, MQTT :
– is a protocol without a data layer (data format is not provided). The data contextualization is therefore poorer than BacnetIP, LON … And without contextualization, you can’t do much with the data as you won’t understand what they represent (is it a temperature? From which room that data represent ? …)
– doesn’t have a network discovery feature that is more than required for automating the configuration of thousands of devices/sensors (would you imagine the cost of doing this manually!).
Integrating system and so data convergence is a real challenge of the smart building industry. The only solution today is to implement a data management layer (integration layer) which is able to contextualize all data (coming from any system/application) through a single source of truth (a unique building description).
Thank you. Again interesting comments here.
Perhaps you could elaborate on your specific point about MQTT being “a protocol without a data layer (data format is not provided). The data contextualization is, therefore, poorer than BacnetIP”.
Using Google’s example outlined here – https://www.automatedbuildings.com/news/may21/articles/sabine/210418015701sabine.html – and specifically the deployment steps they outline in their diagram. Why does it matter that MQTT is a protocol without a data layer? They specifically map data to their own ‘digitalbuilding’ ontology then validate it, which would provide all the contextualization they need, right? With this approach why do they need BACnetIP?
With this approach why do they need BACnetIP?
So that their laggard systems can continue operating.
Sure I can James. The point to taken into account here is that smart building not in a “single-actor” domain, but in a multi-actor domain. If everyone uses their own semantics, their own ontology, their own language, then all the equipment and systems will be specific and real interoperability will not be assured.
Bacnet offers a communication layer, which is now converging to IP, just like MQTT but with pulling principles on one side and publish/subscribe on the other side.
Bacnet also offers higher level features that are essential for industrial use:
– a “semantic description of variables (bool, Enum, Number, string…)
– a systemic organization of objects
– automatic discovery functionalities….
– and above all, these specifications are provided with the standard and can be implemented directly by the equipment manufacturers. Part of the work of specifying the ontologies is therefore carried out upstream of the construction
MQTT is just a very lightweight publish/subscribe communication protocol. It works on top of TCP/IP (like bacnet IP) but doesn’t provide any functionality or description of the transmitted data… you can put chinese, french or english in the message, no guarantee that the reader speaks the same language….
The benefits of MQTT is its capacity to receive a message only on modification of a data, without having to make the request. That makes it possible to limit the network flow (like all the other protocol publish/subscribe) because the customer is not obliged to ask the question every minute to know if there is a modification (pulling) it subscribes once and receives a notification only if the data value is modified. That is what our Building operating System does between our connectors and the datahub (the digital twin single source of truth).
Thank you! Really detailed and useful explanation!
Regarding the comment of Lyubomir:
My point is not to say that BACnetIP is better than another protocol like MQTT, ModbusIP … My point is to say that one protocol won’t fix the issue described in that article. BR
We have a large client with 100 large buildings connected to cloud using both MQTT & BACnet. MQTT for trend data & BACnet for bi-directional real time data.
Sebastien – yes MQTT needs a data description layer, we currently use Sparkplug B which is popular in the industrial IIoT space, but closely watched Google’s UDMI.
Very interesting exchange. Especially the comments enrich the depth of this article that oversimpliefies the issue. The challenge when you consolidate at a too high level is that you loose connection with the “knowledge level” that runs in a more siloed level. All levels and layers in a building require application specific access and intelligence. The technology in smart buildings has evolved here faster than the executive capability of defining their needs and understand the ROI/ ROS of a smart building.
Thank you! Inciteful Comment.
I agree for the most part about MQTT, but it was not meant to provide contextualization in itself, to use it effectively it should be used to send the data as it is created in the BMS world,
for example, 80 percent of our engineering systems use BACnet, it provides us with the information we need, we should take this information and put it into JSON as it is created in the BACnet world, which means also including the required properties when sending the BACnet parameter,
“event_state”: “BACnet_normal(plus various-reporting states)”,
The BMS graphic screens provide us with the contextualization that we need,
The metadata payload should be created from the BMS graphic screens, this will show us the relationship between Assets and Sub Assets, Sub Asset are JSON objects within the JSON that represents assets,
This can be applied to any of the telemetry protocols for example Modbus, Dali etc
Thanks! Interesting example.