It’s Tuesday at 8:32 a.m. Sarah, a facilities manager, is darting off to work. She offers a quick goodbye to her twelve-year old daughter who’s texting a friend and listening to music on her Bluetooth headphones. Sarah gets into her EV, which automatically connects to her phone and begins playing a song from her 80’s playlist. Upon Sarah’s entry, the car adjusts the seats and steering column height according to her preferences. On the drive to work, she uses a virtual assistant to call her husband to remind him of a dinner commitment that night. Finally, Sarah gets to work and wants to run an energy consumption report for two of her buildings. However, her submeter app and her energy dashboard don’t connect natively. Frustrated, Sarah calls her integrator for help. They give her an estimate of a week.
Most of us understand Sarah’s frustration. It’s almost absurd how much connectivity, personalization, and power we possess in our ordinary lives that isn’t translated to working with buildings. Like Sarah, we often think: “Why the hell is this so hard to do, when using our personal devices is so easy!”
There’s a reason why Sarah and many of us in the automated buildings industry have this experience. All our everyday gadgets and technology today use cloud-native architecture. Imagine if your building gave you as much power to connect, to manage and to create as your smartphone did. In general, the automated buildings industry has been slow to adopt cloud-native technology and our buildings and stakeholders like Sarah are paying the costs. But there’s a way for the industry to embrace the power of cloud-native and transform our properties into powerhouses of integration and automation. It’s the Interoperable Building Box or IBB from the Coalition for Smarter Buildings (C4SB).
Why Do We Need an IBB?
Today, the smart buildings industry is facing an onslaught of challenges and disruptions from multiple sides. Building information systems are getting increasingly complex—more sensors, more points, more systems, AI, and digital twins. We have a flood of information, streams of data, yet no single nozzle that will do the work of putting out the fire. We also have incredible applications that do wonderful things but getting them to work and communicate with each other seems to always be a Herculean task. The amount of effort and time is a major pain point for folks like Sarah, who expect things to work as easily as everything else in their lives. For most, the benefits of integration only just outweigh the level of effort. This is the main reason for the slow adoption rate.
The industry’s slow shift to cloud-native is revealing a serious skills gap. Cloud-native has been the standard architecture for IT departments for years now, and the onboarding of OT into the cloud-native space is beginning to blur the lines between the two. IT and OT are converging, and knowledge of both is becoming a prerequisite. Today, it’s difficult to find enough workers with the skills and knowledge level to tackle both.
All these challenges hobble the goal of delivering smart technology at-scale. Overcoming these obstacles requires technology that facilitates app integration while also improving the experience of industry stakeholders like Sarah.
Instead of retooling our entire workforce, we can retool the way we interface with building systems.
What is an Interoperable Building Box or IBB?
Let’s start with a technical definition: The IBB (Interoperable Building Box) is orchestration software running on a physical or virtual machine that exists on-prem; the IBB acts as a standardized interface to connect a building’s local network to the Internet Cloud. The IBB runs containerized cloud-native applications and services based on the Open Container Initiative (OCI) standard. The IBB makes deploying and managing containerized software easier and more secure and provides an automated way for systems to discover and connect with systems having matching capabilities both within the IBB or in the Cloud in a plug-and-play manner.
The purpose of the IBB is to make a building inherently cloud native. That is, all its technologies and apps are built to work within (i.e., “native to”) a cloud environment. It must also support standard cloud functionalities like containerization, dockers, and orchestration (Kubernetes). By functioning like a standard cloud provider, the IBB allows the building to reap the advantages of localized control, namely better resiliency, security and faster access.
Imagine “A Smartphone for Your Building”
In a way, you can think of the IBB as a “smartphone for your building”. Consider all the ways your phone expands your capacity to do things. You can talk to anyone, anywhere, at any time. You can download, install, and run almost an unlimited number of apps. You can connect to the internet, access cloud storage, store local data, share files with your computer, and connect to wireless devices.
In the same way, the IBB expands your building’s potential by providing it greater power to communicate and connect. Overall, your property becomes exponentially more efficient and productive. And because the IBB is located on-prem (i.e., in your building’s “pocket”), it can reliably deliver secure local storage of sensitive data and low latency times.
For example, data from equipment sensors need not make the long, round-trip to a cloud platform and back again. Data storage and computation is already in the building. Such local processing makes storage of sensitive information more secure, while low latency times help protect critical systems and sensitive equipment, this while the cloud connection automatically creates a copy of such data for backup and analysis in the cloud. This is analogous to you taking a picture on your smartphone, you can see the image immediately, and it is also stored in your cloud photo album.
Parts of the IBB
At the heart of IBB is containerization—a cloud-native technology for packaging, distributing, and managing applications in a self-contained unit (i.e., “containers”). Containers house everything an app needs to run, and this isolation makes them light weight, portable, and consistent. Since multiple containers can run on the same IBB, they share the required computing resources (CPU, memory, etc.).
The IBB consists of three main parts: Operating System (OS), Administration, and IBB Apps. These parts function together to make deploying and managing containerized apps easier and more secure.
(OS) Operating System
Like a great deal of cloud-native computing environment, IBB runs on Linux, either on bare metal hardware or on a suitable Virtual Machine. The OS layer of the IBB also includes the open-source Kubernetes (often known as k8s) orchestration platform that manages IBB App containers. The OS layer of the IBB also includes other open-source software to further automate the management of IBB Apps.
Administration
The admin area of the IBB provides the tools for administrators to install and manage containerized applications. This includes software for the management of IBB Apps installed in the IBB, as well as user access and security policies and management. These admin tools provide admins access to the IBB remotely, using secure proxying mechanisms.
IBB Apps
These are the Apps and services provided by Independent Software Vendors (ISVs) that are installed in the IBB by admin users using the Admin tools provided. Each IBB App exists in its own container environment and thus operates separately from other containers (as if in its own hardware environment). Each IBB App communicates with other IBB Apps using IP networking, with the help of IBB orchestration.
Improving Stakeholder Experience
IBB implementation improves the experience for all stakeholders because it simplifies the integration process. Currently, building owners and managers like Sarah need to employ capable folks with specialized knowledge to get things to work together. The process is complex, time consuming, and expensive. The IBB takes complexity out of the process by facilitating plug-and-play workflows. Let’s see how this works by following the process of installing and configuring an IBB using two different personas.
IBB Installation
Both HVAC and IT engineers can use familiar workflows and tools when installing and configuring an IBB. Here are the steps for installing an IBB for an HVAC Engineer and a DevOps:
- Jake (HVAC Engineer)—Jake is tasked with installing a physical IBB device. He orders a suitably specified IBB compatible device from his trusted vendor (CPU, memory, storage, etc.), takes it to the site, fastens it to a wall, connects it to the network, and on his browser, navigates to the IBB’s address and the IBB “Welcome” page.
- Mandy (DevOps)—Mandy is tasked to install an IBB in a Virtual Machine on-prem. She navigates to the IBB repository on GitHub, looks over the IBB installation instructions, downloads the code, installs the IBB in the VM using her standard DevOps tools, and navigates to the IBB’s address and to the IBB “Welcome” page.
Both Jake and Mandy were able to work in ways comfortable with their respective experience and skillset to achieve similar results; Jake through physical “box” installation that he’s comfortable with, and Mandy, using online “virtual” tools she uses daily. These flexible workflows and tools speed up the integration process.
IBB Configuration
Once installed, Jake and Mandy will need to configure the IBB to their specific needs for the building. On the IBB “Welcome” page, Jake/Mandy find a list of management platforms that support the IBB. They select the platform being used for their building project. In this example, they choose Acme X Cloud. Next, they login into the Acme X Cloud portal. The IBB is now installed and configured to the appropriate Acme X Cloud management platform.
Now, let’s continue the configuration considering Jake’s workflow.
App Installation
Once the configuration is complete, Jake can install and manage applications. He begins by choosing the “Install IBB App” option in the management platform (i.e., Acme X). Next, he selects the app he wants to install. In this case, he wants to install a Haystack IDL (Independent Data Layer). Jake configures the app as necessary. The IDL app is installed, and Jake is presented with its UI.
App Integration
Next, Jake wants to install a dashboard required for the IDL. He uses the same IBB management system to install and configure the dashboard. The dashboard is then automatically connected to the IDL and running the way Jake configured it. That is, the dashboard is running in the IBB, and it’s also connected to the IDL because they have compatible capabilities.
Both Jake and Mandy can work efficiently and productively using their own skills and knowledge. Jake knows the apps he installed are compatible and already comply with IT policies. Mandy knows that the IBB is either a well-managed physical device or a virtual device she herself can oversee. More importantly, both engineers work within the purview of their own skill set. That is, they need not know anything about what the other does. In this way, the IBB helps ameliorate the industry’s skills gap.
Instead of retooling our entire workforce, we can retool the way we interface with building systems.
Vendors and End Users
As was stated earlier, the idea of cloud-native architecture and containerization isn’t new; it’s only newly applied to the building automation industry. For years, app developers and the IT industry have built massive ecosystems that support and expand these technologies. Every time you use the Internet or your smartphone, you are using cloud native. Everyone benefits, and now buildings can reap these benefits with the IBB.
For example, mobile app developers follow common standards and protocols within both the iOS and Android platforms. The standards give developers dependable and consistent guidelines that make app deployment easy. Moreover, markets like Apple Store and Google Play ensure these standards are followed. Customers who download these apps can trust they are secure, reliable, and compatible with their devices. There’s no need to call someone to integrate your Instagram app to your iPhone. It just works.
Now, contrast the above with today’s automation industry workflows, where thousands of vendors and developers create apps built with a disparate collection of proprietary standards, protocols, and guidelines that run on different platforms. Some are cloud-native, most aren’t. With the support of vendors and the automation community, we can adopt the IBB and cloud-native architecture to create a collaborative ecosystem that would unleash the functionality and creativity for the entire industry.
Conclusion
The IBB not only holds the promise of streamlined integration and enhanced efficiency for the smart buildings industry, but it also addresses the very frustrations experienced by stakeholders like Sarah. For her, the dream of plug-and-play apps for her building is in reach. The IBB will result in a disruption to the entire industry by changing the way we develop, deploy, and manage our apps and data. Cloud-native offers the freedom and power our industry needs to leap forward and meet Sarah’s expectations. Moreover, the IBB’s benefits ultimately trickle down to the building’s users, the tenants, and occupants.
