Smart Buildings: Three big questions for the 2020s

Lots of smart people have been summarizing the 2010s and predicting the outcome of the 2020s. While I normally like to dive into the weeds, let’s spend a minute this week absorbing where we’re at today as an industry. We’ll start with how far we’ve come in the last ten years, then look forward at where we’re going in the next ten.

Why We Need Digital Twins For Buildings

Note: This is part two in a series exploring digital twins for buildings. If you haven’t read part one on the modern definition of a building’s digital twin, you might want to start there.

I remember it vividly…

I was a senior in high school, the year was 2005. My soccer team had just won the state championship. As a result, I’d been invited to join a prestigious club team in a nearby city. I was giddy and nervous for the first practice with my new teammates and coaches.

As I gathered my gear preparing to make the 75-minute drive, I realized I had no idea where I was going. So I did what any tech-savvy teenager would do in those days: I went to the computer, typed in MapQuest.com, and printed myself the step-by-step driving directions to the soccer facility.

On the merits of an independent data layer

My conversation with KGS Buildings’ Nick and Alex continued last week. I’ve had a lot of fun nerding out with them and others who have reached out in the last few weeks. I want to share a brief nugget from our conversation on the merits of an independent, open data layer.

💭 Side note: I’m thinking about recording these types of conversations for a podcast. If you like that idea, let me know below. 🙏

Here’s a quick summary of the independent data layer concept:

When designing your smart building stack, you separate the Integration and Historian Layers from the Application Layer rather than choosing one vendor’s solution for the whole stack. See my What is EMIS? essay to understand this delineation in more depth. You may also see it referred to as a data lake or middleware. I’m sure there are new acronyms for it—our industry sure loves acronyms.

Defining the Digital Twin for Buildings

Houston, we have a problem.

Quickly after the oxygen tanks exploded early into Apollo 13’s mission in April 1970, the astronauts were fighting for their lives. The whole world held its breath as the now-famous rescue ensued. Engineers in Houston scrambled to sort through technical issues from hundreds of thousands of miles away.

The rescue was successful because back on earth there was an identical copy of the spacecraft—Apollo 13’s twin. The team could quickly test solutions on the ground without adding risk to the astronauts in space.

Almost 50 years later, NASA uses the same strategy to understand and manage systems and machines across the solar system. Except today, the twins are virtual and there’s a fancy buzzword to describe them: Digital Twins.

Analytics: a human-in-the-loop technology

The number one misconception about building analytics software is that it will solve problems on its own.

Yes… it’s an extremely powerful tool for building owners.

Yes… it can revolutionize how buildings are managed and operated.

No… it’s not capable of producing results on its own.

With the exception of automated supervisory controls, energy management information systems (EMIS) are human-in-the-loop tools. They help explore our data and find needles in the haystack, but they require regular use by a well-resourced team to fully convert data to information to insights to action to verified results.

I think the misconception is, unfortunately, caused by sales hype. Marketers are overselling their product or service with promises like “20% ENERGY SAVINGS”. Sorry marketers, but we need an asterisk:

*Analytics can help you achieve X% energy savings if you use the software and take action

Effective EMIS use requires integrating ongoing activities into the organization’s everyday operating procedures. I call this the “path to action”. The creation of operational processes requires thinking through how the team will:

Haystack 4.0 and the battle of open vs. closed ecosystems

I’ve been living in a bubble. My bubble has been burst.

This week, I was reading about the new version of Haystack, a data modeling standard I believe is vital for smart buildings and a must-have for analytics projects. Then I stepped into a meeting to discuss an actual project. Two different vendors are installing analytics software on the same building—one for monitoring-based commissioning (MBCx) and one for single-pane-of-glass (SPOG) and supervisory control. Neither vendor is using Haystack or any standard data model.

See ya later, bubble.

To me and my colleague, that was a huge problem and a huge red flag. But neither vendor saw it that way. The owner didn’t see it that way. Our questions got brushed to the side. Before I explain why that’s an issue, let’s back up a bit and discuss what Haystack is. Let’s take an example piece of building system data, “AI_3”, on the Haystack journey…

What is EMIS? We need a new answer.

In the last month, I’ve read over 50 research papers, blog posts, and articles on analytics software for buildings. I realize this would put most people to sleep, but I love it. It’s also part of my job. One thing I don’t love is the standard, copy-and-paste framework most people are using to describe analytics software. I think it’s confusing, outdated, and it’s inhibiting the adoption of this powerful tool.

It’s time for a new answer to the fundamental question, “What is it?”.

When analytics insights fall on deaf ears

Ouch. That deflated feeling when we uncover an insight using analytics and share it with our team or client and… nothing happens. Or we’re presenting a screenshot from the EMIS and the audience is unresponsive or just doesn’t get it. Blank stares. Or you send a report from your EMIS and no one responds. I hate that feeling.

If you’re finding cool shit with your analytics and it’s falling on deaf ears, it might be time to take a step back and consider this: EMIS is an exploratory analytics tool. We use it to find the needle in the haystack. To understand what the data is hiding in our buildings. But to get shit done, we need to transition to explaining what the data means, including who, what, where, why, and how.

What’s your favorite analytics software?

My colleagues, clients, and partners have always come to me when they have a question about deploying analytics software in the built environment. Without hesitation, the most frequently-asked question, especially for newcomers, is this:

What’s your favorite analytics software?

Or this:

What do you think of X software? Is it better than Y?

Lucky for me, I love answering this question. I have plenty of opinions on the merits of this or that brand. I love to go down a rabbit hole of the best energy data visualizations or fault detection algorithms. I love calling out vendors for bullshit marketing hype and selling nothing but smoke and mirrors.

But I can’t answer it. Not yet at least.