The Journey to the Cloud So Far
There is much talk today in the BAS industry about “The Cloud.” In this article, I will lay out where technology is heading as far as using the Cloud for controlling and automating building systems, including HVAC, lighting, physical security, and other services now critical to smarter buildings.
Coined in the 1960s by J.C.R. Licklider, an American computer scientist, to describe a network of computers that would be accessible to users from anywhere in the world. The general public started to engage with The Cloud around 2000 with offerings from Dropbox, Flickr, and later Elastic Compute from AWS. This “Dropbox era” of the cloud was mainly about putting digital assets (files, photos, data, code, etc.) in the cloud. It viewed the Cloud as a vast resource we can tap into. We still do this today, but the Cloud is rapidly maturing beyond these functions fast!
In the 2010s, the Cloud morphed into the “SaaS era,” where multiple public cloud providers started to connect their services using technologies such as OAuth and Web Services to form valuable services offered in the Cloud to users worldwide. Many of these services centered around a single platform, such as Salesforce, LinkedIn, Yammer, Slack, etc. This era dramatically changed how we all think about creating, marketing, and buying software, sealing the end of packaged software products for good.
Today in 2023, enterprises are increasingly embracing the concept of Hybrid-Cloud, where an application can exist in an enterprise’s own private cloud utilizing data and services provided from their own private cloud, private partner clouds, and any number of providers such as Azure, AWS, and GCP, as well as open data sources such as NOAA, Data.gov, Wikipedia, and others. This architecture allows enterprises to scale up their applications’ use of data in the cloud while controlling the security and access within their own private cloud.
The Birth of Cloud-Native
As the tech world started to reap the benefits of the Cloud, The Linux Foundation saw a fundamental shift in computing architecture to leverage the Cloud as a global computing platform and created the Cloud Native Computing Foundation (CNCF). With this view, the Cloud ceases to be peripheral to a computer or application. Actually, it becomes the computer itself with IPOS (Input, Processing, Output, and Storage) located at the best location for that function, anywhere in the Cloud-Native environment.
IPOS is the core of all computer systems, from the earliest Apple computer, Commode Pet, BAS controllers, to today’s laptops and massive supercomputers. Computing is fundamentally about getting some Input (from keyboards, buttons, cameras, sensors, etc.) and Processing it in a CPU to produce Output (display, actuator, etc.). Also, the Input and/or Output (data and information) may be stored for later use. Instead of having IPOS within a single computer, Cloud-Native spreads the IPOS functions across the nodes of the vast Multi-Cloud, communicating with each other using standardized Cloud-Native protocols and techniques.
A key attribute of Cloud-Native is that it is dynamic, modular, and loosely coupled. When additional Processing is required, the system can be configured to spawn new Processing nodes and have them stand down after they are needed. For capabilities like this, a new term needs to be understood, Orchestration. An example of orchestration within data centers is a technology called Kubernetes, originally created by Google and placed into the public domain. It is now used by around 40% of the web servers in the world. If you used the Internet to read this article, the chances are that you used Kubernetes. Kubernetes is the orchestrator that automatically scales up the number of servers needed when Nike announces a new shoe that causes users to flood their websites.
Orchestration relies on metadata, something that this industry is now very familiar with, tagging data to provide it with meaning. Metadata is helpful in managing and analyzing data, as we see from efforts like Project Haystack, the Brick Schema, and others. In Orchestration, metadata provides systems and applications with a way to indicate their standardized capability to either consume or provide some specific service for a given context.
Imagine system A declaring metadata that it can control lights for space XYZ and system B declaring metadata that it has lights that can be controlled in XYZ. When this ontology is standardized, an Orchestrator automates systems A and B to be connected so lights can be controlled. Integration becomes a plug-and-play activity, and with Cloud-Native and IBB, this happens securely and dynamically across public cloud, private cloud, and on-prem systems.
The collective thinking of Monday Live! and the Coalition for Smarter Buildings (C4SB) propose that the future architecture of building systems will inevitably be Cloud-Native.
Bridging the Cloud with the Building
One of the challenges of bringing buildings into a cloud-native environment is connectivity. Many vendors providing FDD and analytics capabilities, including artificial intelligence (AI), start by installing a gateway (usually a “box”) on-site to connect to building automation system (BAS) networks and send data to their cloud. While some use standardized technologies, these “boxes” are fundamentally a proprietary way to connect a building to the vendor’s system. This creates the potential for vendor lock-in, making it difficult and expensive to switch vendors or upgrade systems in the future.
For buildings to participate fully in a Cloud-Native environment, the building itself must look “like a” Cloud provider, just like public cloud vendors and private data centers. This requires a standardized interface that performs the functions necessary between the cloud and on-prem systems. Historically the industry has been significantly held back by vendors prioritizing proprietary lock-in. It is vital that we make sure this doesn’t happen here. This interface has to be open and standardized.
It is with this in mind that C4SB and Monday Live! have been collaborating to create a standardized interface between the cloud and on-prem systems. We call this the Interoperability Building Box (IBB).
The IBB, when released, will be an open-source requirement specification document that details how to build an IBB product (hardware and software) and also how to create applications and services that can be installed and run on an IBB. The specification will utilize all of the leading IT data center practices.
While the final specification is not yet finalized, IBB will, in essence, be a small data center in the building. In practice, it could be a small- or large-sized device “box” provided by a BAS or IT vendor, or IBB can operate in a data center located in the building if one exists. The key is that IBB is on-prem and can access all of the systems in the building (southbound), and northbound, it can access services from the Public or Private clouds.
As far as capabilities, the IBB is designed to perform the following:
- Host control “heads” for building systems
- Manage secure communications with on-prem systems
- Manage secure communication to the Internet cloud
- Enable interoperation & message exchange between systems
- Provide local data storage to improve performance and efficiency.
Some example use cases for IBB is provided in the diagrams below.
Ending The Big BAS Debates
If you have been at a conference in the past few years or have read AutomatedBuildings.com, you would have noticed two debates lingering without any sensible closure. The first is the IT vs. OT debate, and the second is the Cloud vs. Edge debate.
Cloud-Native ends the IT/OT debate because our real objective is to make buildings smarter by managing and analyzing information about the building. Cloud-Native does this and is 100% IT. The OT part of the argument reflects the domain of information being controlled and managed. IOW, it’s not IT vs. OT; it’s IT being used in the context of OT. We (Monday Live!, C4SB) propose that Cloud-Native ends the IT/OT debate. A building becomes smarter when more information is available at the right granularity, coming from more sensors and controls, with more interoperability to be consumed by useful applications. Cloud-Native enables all of these trends to happen more easily, extracting OT data using IT methodologies.
Regarding the Cloud vs. Edge debate, the arguments have been about whether to have one or the other; the reality is that both are important to have, and they need to be securely and openly connected as a hybrid system, which is exactly the role of the IBB. One of the key aspects of edge-to-cloud is the latency and potential unreliability of the Internet connection; here, the IBB acts as an impedance-matching device as well as a place for information to be cached or buffered as needed by suitable applications.
Let’s Debate the Merits of IBB
At a technical level, we (Monday Live! & C4SB) strongly believe that the Cloud-Native and IBB approach is the right thing to do. The team working on the IBB would welcome any questions, suggestions, and contributions to make the IBB a better solution. Please email me directly to voice such thoughts.
We would also welcome thoughts on the business and adoption side of this issue. If you are a building owner, does Cloud-Native resonate with how you think of architecting your building system? It is likely that much of your enterprise architecture is going the way of Cloud-Native; how beneficial would it be for your real estate assets to be part of this broader view of the enterprise and be analyzed in a similar manner to all your other assets? Would you install an IBB when it becomes available?
As a vendor of hardware or software, how does this Cloud-Native and IBB approach fit into your plans? Does providing an open and Interoperable interface at the building-cloud layer help you deliver more value to your customers? Specifically, if you are a hardware vendor and offer a gateway box, would you be inclined to make such a product IBB-compliant so that your product becomes more valuable as it can be used by other applications? If you are a software vendor, would you enable your offering to run on an IBB since doing so would significantly reduce the effort in using your solution?
C4SB and Monday Live! believe that using information technology to make buildings smarter can invigorate the building industry and deliver significant value to existing and new buildings. This approach can help mitigate climate change by significantly reducing the resources consumed by buildings.
Please reach out to me on LinkedIn or via email at anto@padi.io.
