Complexity of Commercial Buildings a Challenge to IoT Applications

Developers of IoT applications strive to create plug-and-play software, so that a potential user can download the app and immediately begin using it. In the case of a Nest thermostat, or a Fitbit activity tracker, this is simple because the software only needs to know how to interact with a single device. If you compare this simplicity to the complexity found in a typical commercial building, the picture is far different.

A typical commercial building consists of a unique combination of mechanical and electrical systems, controlled by a random a la carte array of controllers, which in many cases have been uniquely configured by individual programmers. There is very little consistency, and as a result, it is impossible to create the world’s next greatest energy reporting app and expect it to be deployed quickly and inexpensively into a huge number of sites. For the typical economics of an “app business model” to work, the app must cost $5 or $10 or $50 and be downloaded thousands or millions of times. If weeks of custom data mapping by a specialist is required for each deployment in a building, we will never see the explosive growth of apps in commercial buildings.

To solve this problem and permit IoT concepts to allow our commercial buildings to realize maximum advantage requires that the data itself have meaning and context. To software developers, meaning and context around data is known as metadata, or “data describing data.” There are efforts underway today to formalize ways to encode metadata for our building systems. Project Haystack is one notable example of a community-based effort to devise a library of data tags and a method for consistently using those tags to describe the data. When Haystack tags have been properly applied to data, it becomes possible for a software application to gather data from a building and know what to do with the data. Applications could ask for a list of all air-handling units, or could ask for the reading of every space temperature sensor.

In the near future, we can expect commercial building systems to embrace better metadata. For example, the unique aspects of a chiller plant will be encoded in metadata at the time of installation, by specialists who understand the uniqueness of that particular chiller plant. Then the chiller plant operator can potentially select from a wide range of chiller plant optimization routines and analysis apps, which can be quickly downloaded and applied.

— Robert Knight

Central IoT Data Warehouse Can Solve Cost Problem

As the number of IoT solutions with APIs has grown, problems with scale have been revealed. The amount of complicated customization required to pull together various products can become prohibitively expensive when performed in a “one-off” manner. To solve this, some software developers and integrators in the IoT space elect to create a central data warehouse to receive inbound data, clean it, store it, and permit software applications to interface to this central location.

Assuming that the data warehouse is sufficiently open and transparent, the unique complexity of various IoT hardware and software becomes invisible to other hardware and software that wishes to collaborate or share data. Each product only needs to be mapped in or out of the warehouse. A data warehouse model enables app developers to more easily bring low cost and specialized apps to market.

For buildings, data warehouses are being constructed today, although they may be described with less glamorous terminology, such as “middleware.” When the number and type of integrations grow, there are clear efficiency gains from collecting and normalizing (i.e., standardizing) data from many sources into a single platform. As the IoT market grows, buildings will see a more pronounced push to adopt a central data warehouse architecture, and will benefit from a wealth of new software applications that solve specialized problems or use-cases better and less expensively than ever before.

— Robert Knight