🔍 Deep Dive: How to evaluate smart building technology 🔎

Happy Sunday!

Since around 2015, I’ve been keeping an Evernote notebook of products in the smart building marketplace. Whenever I see a new startup, which seems like it happens about once a week, I throw it on the list. When one company buys another, I update the notebook. When I see a product demonstration, I create a page in my notebook and add screenshots, capabilities, strengths, weaknesses.

The list has been growing and growing—there are now 100+ vendors! And this only includes a small portion of categories underneath the broad and ambiguous “smart buildings” umbrella.

Recently, I’ve had two realizations about my private notebook:

1. I need to share this list.
2. The list (and the marketplace itself) is overwhelming. We need a framework to cut through the noise.

#2 is the focus of today’s free deep dive. Before we get to that, let’s talk about #1.

“Comparing notes”

Just like I’ve been doing in Evernote, many Nexus readers have lists, spreadsheets, and notebooks of their own. At least 10 of you have reached out to me wanting to “compare notes”. I enjoy these conversations, but when viewed from my perspective, it seems like the industry is spending a lot of collective time on making lists and keeping them updated. This is time we could all be spending time on improving our products, services, and buildings.

My hypothesis: The Nexus Pro membership can be a place to share and compare our notes. Then we can focus on what truly matters: differentiating ourselves, creating partnerships, digitizing buildings, stopping climate change… that kind of stuff.

If you missed last week’s announcement of the Nexus Pro membership, here’s the short version: For just $19/month or $199/year, members get weekly deep dives, exclusive community access, and access to the Nexus vendor landscape.

If you sign up for Nexus Pro by April 30th, you lock in the early adopter’s discount:

Get 20% off forever

That third membership perk—Nexus vendor landscape—is my list… and it’s already live for Pro members. Here’s why I think you’ll like it:

• It doesn’t exist anywhere else (except for the personal notebooks of the top experts in the industry)
• It’s a living document—As the industry (and our understanding of it) evolves, the landscape will be continuously updated and improved upon. It will eventually evolve into a full notebook. Right now, we’re only at Stage 1.
• It’s a Nexus site index—it has hyperlinks to past Nexus newsletters and deep dives that mention each vendor so you can go deeper.
• Community feedback—You’ll be able to see other members’ comments and engage in discussions.

Regardless of whether you sign up for Nexus Pro and get access to the landscape, read on… this deep dive provides an introduction to the marketplace by explaining how I evaluate new smart building technology.

We’re talking in circles

I can’t tell you how many one hour meetings I’ve been in where the first 55 minutes is spent getting on the same page. What does the technology do? How does it relate to the technology we already have? How does it compare to the other technologies we’re evaluating?

This issue is further exacerbated when, even if we’re using the same terminology, we have differing definitions for the same words. What do you mean when you say analytics? Energy management system? Energy management information system? Building management system? Facility-related control system? IoT platform? Digital Twin?

Acronyms and names that can mean pretty much the same thing are getting lost in translation. Lots of time is being wasted because we’re talking in circles.

What is it?

Before getting into the landscape of smart building vendors, we need a common language for understanding what they do and how they relate to other technologies. It’s time for a new answer to the fundamental question:

“What is it?”

One common answer is what I call the standard EMIS framework. The acronym “EMIS”, short for energy management and information systems, is an umbrella term designed to wrangle together 5 technologies, separated by whether they focus on the “meter-level” or “system-level”.

• Meter-Level: 
• Monthly Energy Metering (MEM) – focused on analyzing utility bills 
• Energy Information Systems (EIS) – focused on analyzing interval meter data 
• System-Level:
• Building Automation Systems (BAS) – focused on controlling equipment 
• Fault Detection & Diagnostics (FDD) – focused on identifying, notifying and recommending solutions when a system or component is operating outside of expected performance criteria
• Automated System Optimization (ASO) – focused on supervisory control of systems 

To summarize, the standard EMIS framework answer to “What is it?” is this:

It’s is an EMIS. EMIS is a broad family of 5 technologies: MEM, EIS, BAS, FDD, and ASO.

The standard framework did the job we needed at the time—very well in fact. There were these five distinct-ish categories of energy management software on the market, and we needed a way to group them together because they were doing similar tasks. We needed common terminology to create clarity for industry professionals in hopes it would help people understand what they were buying. We needed that umbrella acronym, and those early contributors gave it to us. I’m grateful for their early leadership.

But here we are, many years later, and confusion about the offers in the marketplace – i.e. what is it? – remains one of the biggest barriers to adoption. I’ve seen the consequences first hand: When building owners are confused, they slow down purchases, do nothing, or purchase a lousy product that doesn’t meet their needs and sets them back for years. Let’s walk through the ways I think things have changed since that early framework was created.

1. No building owner wants to use 5 separate tools

They’re overwhelmed as it is. There are already have enough silos. It’s no longer good enough to just be an EIS tool. If one tool can’t meet all needs, we need interoperability between tools into one cohesive system.

2. It’s not extensible

The framework isn’t extensible to new types of capabilities. For example, where do new developments like machine learning fit in? Digital twins? LoRaWAN? VOLTTRON?

Similarly, the framework stops short of conveying the growing influence of technology beyond energy management. It leaves out technologies that don’t directly affect energy use at all. For example, EMIS is now used for predictive maintenance, which stretches beyond energy into O&M and capital planning. Occupant engagement is another example.

3. The boundaries are blurry between the “family members” and some members cross boundaries

The smart building software market is now too messy to divide into 5 distinct categories. For example, if an EIS tool pulls in only meter-level data but has FDD capabilities, I don’t know what to make of it using the standard framework. Many vendors are providing many of the categories and will continue to expand. Some “can” provide multiple categories, but not out of the box.

4. It’s difficult to compare vendors

Although it’s not intended to help select vendors, it often gets used for that. I find that with just 5 categories, it’s impossible to capture the nuances between vendors. For example, Automated Logic and SkySpark both provide FDD. And yet, they’re almost completely different use cases.

A new framework

Okay, so what would a new framework look like? We want something that is simple, stands the test of time, and promotes adoption. I think it starts with three questions:

• What are you actually doing with the technology? What are the use cases? These are the capabilities.
• What devices and other systems are you connected to? This is the scope.
• What combination of hardware and software are you using? This is the stack.

Let’s unpack each of them.

Capabilities

What does the technology actually do for the user? What “jobs to be done” does it support? Does it do these out of the box or does it need to be customized to handle them? Here’s a partial list of the capabilities in the marketplace:

• Centralize, Normalize, Process, Visualize Data
• Dashboards
• Key Performance Indicators
• Reporting
• Advanced Visualization 
• Applied Modeling
• Machine Learning
• Utility Bill Management
• Usage and Cost Tracking 
• Benchmarking
• Bill Processing 
• Interval Meter Analytics 
• Advanced Bill Processing 
• Visualization 
• Power Quality Monitoring 
• DER monitoring 
• Measurement & Verification (M&V)  
• IPMVP Option C 
• M&V with Interval Data 
• Operational Verification  
• Automated Fault Detection and Diagnostics (AFDD)
• Supervisory Control 
• Automated System Optimization (ASO)  
• Setpoint Compliance 
• Demand Management 
• Load-Changing Control
• Automated Performance Testing 
• O&M Optimization 
• Issue Tracking 
• Work Order Generation and Management 
• Condition-Based and Predictive Maintenance  
• And many more!

Scope

The scope is simple: What does the product connect to? The scope could be any of the existing systems in the building, plus any third-party systems. The integration with each system could be a one-way transfer of data or it could be a two-way communication stream. Here’s a partial list of potential scope systems:

• Utility Bills
• Weather Data
• Static and Dynamic Facility Data
• Interval Meters or Advanced Metering Infrastructure (AMI)
• Building Automation Systems
• Distributed Energy Resources
• Electric Grid
• Internet of Things
• Electric Vehicle Charging Stations
• Geographical Information Systems
• Computerized Maintenance Management System (CMMS)
• Occupant Engagement Applications

Stack

A smart building product typically isn’t one singular thing or application. The stack is all of the devices, data services, and applications that meet the needs of the user. Depending on the implementation, the stack has many different layers:

• The integration layer is responsible for managing communication between the Scope and the historian layer or the application layer. It could include hardware and/or software and these components could be local or remote.
• The historian layer stores time series data and associated metadata in one or more databases, providing those data on request to applications.
• The application layer consists of all software applications that provide capabilities to the user and rely on data from and communication with Scope systems.
• The control layer supports applications that have a need to affect the operation of building devices in an automated or semi-automated manner.

The framework can be used to map almost any smart building technology and get everyone on the same page. I love to go to the whiteboard and sketch out the three levels:

Examples of the Framework in Action

Let’s do a few examples using technologies we’ve recently highlighted in Nexus newsletters. Using the framework, I mapped out the Brainbox AI product, which was recently described in Nexus #18, in 5 minutes. Let’s do it together.

When I work with clients, I like to start with the Scope because it’s grounded in the data and systems that are already deployed. This allows our understanding of the product to be built up in terms of what the building operators already know, use, and pay for.

Next, I like to jump to Capabilities. We don’t need to get too bogged down in the details of the stack until we understand what we hope to accomplish with the product and why.

As we covered in Nexus #18, Brainbox AI is focused on Advanced Supervisory Control using artificial intelligence. It pulls HVAC data from the BAS, runs some fancy algorithms, and then sends commands back to the BAS to optimize setpoints. The weather data is used in the prediction algorithms. The interval data is used in demand management algorithms.

Additional secondary capabilities include M&V (using the utility bills) and some simple data visualization.

And finally, how are these capabilities deployed in the real world? When describing the stack, you can get as detailed as you’d like. I typically keep it pretty high level, but I can imagine nerding out and drawing lines of connection between everything.

The BrainBox AI stack includes the “brainbox” hardware device, cloud-based apps and databases, and some third-party data feeds. The brainbox device is a locally-installed gateway, which provides two-way communication between the BrainBox cloud and the scope systems.

Here’s my quick rendition:

And now the product is mapped:

Once we map the technology using the framework, we can begin to group similar technologies together and look for nuances between them. For example, how does BrainBox AI’s supervisory control offering compare to Verdigris’ Adaptive Automation? And how do their business models differ?

Also, building owners can use the framework to map out their entire smart building stack and visualize where each vendor fits. For example, what if the building owner was also evaluating an IoT sensor platform like InfiSense (who we covered in Nexus #4)?

Perhaps the added sensor data could help BrainBox AI provide improved Supervisory Control and Data Visualization. Perhaps the BrainBox and InfiSense gateways could communicate and reduce traffic through the firewall or reduce costs by removing a redundant cellular modem from the stack? These are just a few ideas for thinking more strategically.

These are the ideas behind the Vendor Landscape. As it evolves, I think we’ll map out:

• Stage 1: What are all the technologies in this marketplace?
• Stage 2: How can we categorize them using the framework?
• Stage 3: What are the nuances that differentiate vendors in each category?
• Stage 4: How are the leading building owners deploying these technologies in an open ecosystem (e.g. All-Star Game)?

For many of you who don’t have time to keep up with market evolution, I think this ever-evolving resource will be worth the price of a Nexus Pro membership on its own.

If you sign up for Nexus Pro by April 30th, you lock in the early adopter’s discount, and you can access Stage 1 of the Vendor Landscape immediately:

Get 20% off forever

OK, that’s all for this week—thanks for reading Nexus!