What IoT Really Means  - and What it Doesn't

David Fisher, President, PolarSoft Inc.

The "Internet of Things" (IoT) is a marketing concept, not a specific technology. While it's important to talk about what IoT could mean to the Building Automation Systems (BAS) industry, it's even more important to realize that as yet, there is no standard or coordinated effort to define what IoT for buildings means, and how it should be implemented. Like most new things, IoT has a dark side where some companies and individuals exploit the promise at their customer's expense. The BAS industry has been here before. Let's take the time to speak thoughtfully about the problems, and benefits, and draw sharp distinctions between what is actual vs. what is possible but not yet here.

In the context of buildings and BAS, one of the new buzz-concepts is IoT. In theory, IoT is about making use of "the Internet" to provide better and richer access to your "things." I don't know about you, but the buildings we work with don't have things, they have expensive, energy-using equipment, and lots of it. That equipment contains many individual microcomputer-based control devices that control and manage all kinds of different physical, mechanical equipment, lighting, security, life-safety, laboratories, etc. All of these devices need to be carefully purchased, installed, commissioned, operated and maintained. Humans are involved in all of these steps, and that's not going to change anytime soon.

There's a common misconception about IoT that somehow it's a replacement for existing BAS. That's simply not true, and would be an epically bad idea. The BAS industry has labored for over 30 years defining standards that bring together all kinds of devices of every category. Although there are various standards in use, the best known is ANSI/ASHRAE 135-2016, also known as "BACnet," and as the international standard ISO 16484-5 (and -6). Today there are tens of millions of BACnet devices interoperating daily, and over a thousand vendors making BACnet products. These numbers continue to grow at a breakneck pace. There is also continuous extension and development of the BACnet standard, evolving to keep up with new technologies and shifting needs. BACnet is truly the Internet of building automation devices. A key factor is a widespread participation and adoption by actual makers of devices in the ongoing refinement and deployment of products using the standard. That "legacy" isn't a liability; it's the core strength that has changed interoperability from a concept to a daily reality, worldwide.

What this means is that it's common for buildings to have BAS, and overwhelmingly those BAS use BACnet. What it also means is that there is a treasure trove of valuable information available in nearly every building's BAS: operating information, historical trending, alarms, etc. And it's easy to access using an international standard. But BAS tends to be building or facility-centric. That's great for devices within the facility that need to interact with each other, and for systems and management local to that facility.

We can think of the facility and its buildings and systems, and the devices that implement automation, monitoring, and control as one huge container. As long as the interactions and use of those devices and their information take place inside the container, mostly everything works. Lately, there's been a lot of interest in how to best make use of this information outside of the container. The boundary that defines the facility has come to be called the edge and is the focus of this article and the crux of how IoT can be a big benefit.

So what is IoT? Generally speaking, IoT is the use of the public Internet to facilitate communication between "things" across diverse locations. In the context of buildings and BAS, on the one hand, we have a facility (or many facilities) that are self-contained in the sense that their BAS already operates and manages the facilities. What we would like to do is to allow programs outside of the facility to have access to information, and possibly even provide high-level goals, to controllers within the facility. In other words, to allow external programs to make use of our treasure of information. There are many applications for this kind of access: data mining, maintenance, optimization, planning, etc. The point of IoT is not to say what those applications are, but to enable the use of the Internet to gain access to it. By mitigating barriers of time and place, IoT enables the creation of new classes of applications that would have been extremely difficult or impossible before.

Why can't we just use BACnet to do that? Well, you can, but there are a number of issues. The most complex issue is information security. If the facility exposes its internal BACnet infrastructure to the public Internet, that means that anyone with sufficient knowledge could write programs to intrude into the BAS network, and possibly even cause disruption or damage, accidentally or by intent. There are techniques that can be used to mitigate this, for example using virtual private networks (VPN). But generally speaking, these are half-measures. There are some new additions to BACnet that are under development that will address this kind of security, but that's still only a part of the problem.

In order to use BACnet to do this kind of interaction, you have to have an expert level of understanding of BACnet. Even then, that only allows a client application to talk to a facility. When multiple facilities are involved, this quickly gets a lot more complex. In this regard, IoT can provide some significant benefits because its concept is to enable very secure communications between multiple entities across the Internet.

Let's consider an application for centralizing information about multiple facilities. A property management company operates multiple facilities, perhaps even in multiple cities. They have a centralized server that runs their applications, which makes use of IoT principles to communicate to each facility over the Internet. Maybe they want to gather operating information like average temperatures, runtimes and so forth. Maybe they also want to gather historical trend data. The point is that the applications are centralized, although the physical facilities are remotely located.

To make this work, somehow they need to "convert" the BACnet-based information from each facility into a form that can be conveyed using IoT principles. This is where edge controllers come in. An edge controller is a physical device located in the facility "at the edge." It connects to the BAS BACnet network to communicate with actual BAS devices and gather information, or perhaps relay control objectives like energy reduction levels. The edge controller also connects to the Internet and establishes communication with the applications in a central server using IoT.

This same strategy works when there are multiple facilities, and multiple clients are interacting with the same cloud server. All kinds of applications are possible, such as a smartphone app that can provide information about building operations, service technicians having access to historical information, as well as cloud server-based applications that can do complex activities such as data mining without requiring heavy-duty server hardware local to each facility. The possibilities are endless.

That's the "promise" for IoT for buildings: that we will be able to leverage the power of large centralized computing, and ubiquitous Internet access, to provide a rich over-layer for monitoring and operating facilities. Sounds great. But the devil is in the details, and today there are a number of issues that I've intentionally not yet mentioned. Just exactly how do those dashed red lines work, and who is standardizing how edge controllers and applications interact?

Wikipedia has a detailed article on IoT (https://en.wikipedia.org/wiki/Internet_of_things) that looks at IoT in a very broad context, and  specifically how it can be applied to BAS. As a new concept, IoT is already bumping into something that BACnet has known for decades. Jean-Louis Gassée (Apple initial alumni team, and BeOS co-founder) describes what he calls the "basket of remotes" problem. See the article in Monday Note, https://mondaynote.com/internet-of-things-the-basket-of-remotes-problem-f80922a91a0f. Does this picture seem familiar to you?

He predicts that we'll have hundreds of applications to interface with thousands of devices that don't share protocols for speaking with one another.

We all know this problem. Manufacturers of TVs, DVD players, cable boxes and so forth could never agree on a standard way to control their devices (and still haven't). What emerged was a "common platform" for infrared-based remote controls that essentially defined a small number of actually common ideas (volume up/down, channel up down) but most control uses a proprietary matching of buttons to functions. The remote actually has to know the vendor code, and what the vendor's proprietary meanings are. Since vendor A uses code 12 to mean open DVD tray and vendor B uses code 12 to mean display menu, the only way for them to coexist is through proprietary methods. This is the worst possible kind of standard because it just pretends that the devices are standardized even though they are hopelessly proprietary.

In contrast, although in some ways BACnet started out on this path, today overwhelmingly BACnet devices use standardized methods, objects, and procedures. More importantly, manufacturers agree voluntarily to use these standards, and there is a consensus-based standards organization (ASHRAE) and highly organized process for changes and revisions, and it is not pay-for-play.

The Wikipedia article goes on to point out: "…new technology leaders are joining forces to create standards for communication between devices. Manufacturers are becoming more conscious of this problem, and many companies have begun releasing their devices with open APIs. Many of these APIs are used by smaller companies looking to take advantage of quick integration." This points out three major obstacles for IoT, at least in the BAS market space:

1. The "new technology leaders" aren't manufacturers providing core products in use in facilities. That's a problem because those are the companies that must be the adopters in order for IoT to achieve any purchase in BAS. Otherwise, you'll need to have "converters" (what we would call gateways) between every kind of proprietary IoT mechanism and actual standards like BACnet. They are also reinventing the wheel, but without the 30 years of experience that existing BAS manufacturers have in developing and deploying and using BACnet. Good luck.
2. Having an "open API" doesn't help. We learned this over and over with BACnet. If it isn't a standard, where changes are controlled by a consensus process, then it's always going to be dominated by the 800lb marketing gorilla with the most money. Or each fad is going to go away along with your investment in products.
3. Quick integration is another promise, but may not be so easy in reality. Smaller companies can be nimble but are also easily overwhelmed by changes in direction and technology.

[an error occurred while processing this directive]Adoption is more important than openness although they aren't mutually exclusive. Unlike cell phones that seem to change concepts and features almost quarterly, controls in buildings have a long life. BAS owners and managers need to be careful about any technology that narrows the scope of flexibility they have once they buy-in to it. I'm not saying that IoT purveyors have evil intent, let alone an organized one. But unless the solution has widespread adoption, you could find yourself locked-in to particular manufacturers. It doesn't help that the BAS industry has a long history of exploitation of customers in exactly this way. A lot of companies are throwing around words like IoT as if that meant that the "things" are standardized as well as how they talk to each other and what they can say. They're not.

So what are the key messages about IoT applications for BAS?

• BACnet is going to be with us for a very long time, and it's already evolving in a successful and proven way;
• It's critical to embrace change that’s true world community-oriented and not serving a few special interests;
• It’s important to break the lock of outdated traditions that have long empowered abuses of owners and managers and even designers/appliers of BAS technologies, and to not repeat these sad lessons with IoT;
• There is an enormous bounty of information that is available from BAS devices and should be put to use;
• IoT is enabling technologies that are force multipliers that are changing the landscape;
• IoT companies should stop wasting time on "open APIs" and instead join the already open effort in BACnet to evolve IoT mechanisms that are part of the standard.

About the Author

David Fisher is President of PolarSoft Inc., a Pittsburgh-based company that specializes in BACnet software, tools, and education. Mr. Fisher has been very active in the development of the ANSI/ASHRAE standard BACnet since 1987, and has authored many BACnet products, tutorials, articles and made significant contributions to the BACnet standard. dfisher@polarsoft.com