Welcome to Nexus, a newsletter for people applying analytics and other smart building technology—written by James Dice.

If you’ve been forwarded this email, you can sign up for your subscription here:

Sign up now

This is an experiment, and I’d love your feedback. If you have thoughts, questions, ideas or tips, join the discussion on LinkedIn or send me an email.

My latest ideas

+ Analytics: a human-in-the-loop technology—on the number one misconception about building analytics: that it will solve problems all by itself.

Or, as reader Blake Stoddard commented: that it is a "solution" when in fact it is a “tool”.

This post unpacks the confusion and provides a framework for operationalizing analytics. It’s also a great compliment to another essay: When Analytics Insights Fall On Deaf Ears.

News worth knowing

The best of what I’ve seen on the web lately…

1. Analytics

+ KGS’ Buildings Unique Approach to Fault Detection and Diagnostics (white paper)—I had a wide-ranging and enjoyable conversation last week with readers Nick and Alex of analytics software provider KGS Buildings. While I’ve implemented many types of FDD software, I haven’t yet implemented their Clockworks solution, so the guys introduced me to their approach. I felt like we barely scratched the surface, so look for more in the coming weeks as I unpack things.

For now, I want to highlight one thing that stood out: their unique approach to FDD. It’s summarized in their white paper, but let’s take a crack at boiling it down even further. They seem to be tackling three of the biggest challenges I’ve experienced with FDD:

1. Operator overwhelm—when you turn on the FDD software and 2000 faults pop out. Cue building operators’ eyes glazing over. One way I’ve dealt with this is to turn on just a few faults at a time and/or limit the types of equipment you’re looking at. Another way is to prioritize them.
2. Calculating savings—The ideal way to prioritize faults is based on energy savings, but it’s downright difficult to accurately calculate savings for each fault. It gets even more difficult when you have two or three faults that overlap, meaning you could be double- or triple-counting savings.
3. False positives—when the software identifies a fault that isn’t actually a problem. If operators’ eyes glaze over with too many faults, it gets much, much worse when many of them aren’t real. Cue some serious trust issues.

The Clockworks platform groups together similar faults in the same piece of equipment or system and layers them on top of each other in a hierarchy (see the ⭐ in the screenshot below). Downstream rules depend on upstream rules’ results. So if there’s something you could fix that would fix other faults, the system recognizes that and the downstream rules won’t show up. And since they group rules together, they can theoretically decipher the overlap in cost calculations leading to more accurate savings calculations (See the 💰 in the screenshot below).

Finally, their FDD algorithms depend on what they call the Parameters Library—“the variables that determine how a diagnostic runs”—designed to avoid false positives. Parameters are the static equipment information, system relationships, sequences of operations, and building-specific variables required to tune FDD rules to any real-world facility.

This means going far beyond just writing a simple FDD rule, such as simultaneous heating and cooling:

Do you have a replicable code set that can identify simultaneous heating and cooling while automatically taking dehumidification into account? Can it accommodate various types of coil bypass configurations? Can it handle freeze protection modes? Can it accommodate heat recovery configurations? Can it do this without the user having to decide which rules apply and which rules don’t apply on every given configuration?

Can you diagnose suboptimal economizer performance with the same code set when control is based on enthalpy, dewpoint, or dry bulb temp? When the sequence commands the economizer to control to SAT rather than MAT? When “or” logic instead of “and” logic is used and the economizer can be controlled based on a high limit temperature or differential enthalpy?

The parameterization approach allows Clockworks’ diagnostics to be customized to any building’s unique systems—an approach they liken to a concept called mass customization:

Mass customization...is not merely about tailoring a technology to the needs of the idiosyncratic user (which is the case with customization); rather, it is about pretailoring the technology to the idiosyncrasies of every user.

I’m still learning here, but this seems to differ significantly from the FDD approach I’m used to—which I’d describe as starting with a simple FDD rule (e.g. simultaneous heating and cooling) and data model (e.g. Project Haystack) and then adding exceptions (new lines of code and/or new custom tags) to treat new idiosyncrasies as they come up.

2. Smart Buildings

Lots of smart people have been summarizing the 2010s and predicting the outcome of the 2020s. While I like to dive into the weeds here on Nexus, let’s spend a minute this week absorbing where we’re at today as an industry.

The 2010s

When I started my career in 2010 as an energy engineer, the best practice was to install HOBO data loggers to understand how building equipment was operating. This was the process:

💻preconfigure the loggers at the office

🏢🚗make a site visit and install the loggers

⏳twiddle our thumbs for a month or so hoping to get enough data

🚗🏢make another site visit to retrieve the loggers

💻back at the office, load them into the HOBO software

📈then export them into Excel, where we analyzed them with a special macro-filled Excel workbook that looked for common energy conservation measures (ECMs) in the data

Whew, I’m exhausted just thinking about it. The funny thing is I’m not done. If we found ECMs and the owner decided to implement them, we’d go back and install the same loggers AGAIN to verify they were implemented properly. Then repeat all the other steps. (Shout out to reader Kyle Pacatte, forever my data logger partner in crime.)

Now, many people are still using data loggers, and I get that. The key is we don’t need to do that anymore—for many reasons. Here’s what’s changed this decade:

1. Cloud and SaaS are mainstream—As the Switch Automation team reminds us, before cloud technology, we relied on data loggers, disconnected spreadsheets, databases, and inaccessible systems.
2. IoT devices are cost-effective—HOBO loggers can now be connected to the internet. Even better, open platforms like InfiSense are offering new sensor tech and serving the data via API.
3. Mobile apps for everything—this was the decade of the iPhone, bringing an “app for everything” mindset from building occupants and operators.
4. Smart buildings became a real thing—as the answer to siloed building systems, we started to connect everything. Simultaneously, we’ve seen an explosion of new solutions creating confusion in the marketplace.
5. State, local, and utility organizations started setting ambitious targets to tackle climate change—For the first time in my career, it feels like we started to give a shit about climate change. As discussed on The Interchange podcast, this is the age of 100, as public pressure and related goals set by local governments and private businesses are finally bringing some urgency to tackling the two types of greenhouse gas emissions caused by buildings: operational carbon (the emissions associated with energy used to operate a building) and embodied carbon (the emissions associated with materials and construction processes throughout the whole lifecycle of a building).

The 2020s

Let me start this with a disclaimer: I don’t pretend to have answers about the future—only questions (and excitement and a healthy dose of fear). Here are my top questions for the coming decade.

Will building technology catch up with other sectors?

First, let’s start the new decade by acknowledging how much room for growth there still is, despite the progress made in the 2010s. Building technology has fallen far behind what technology is capable of. For all the talk about new tech (AI, 5G, digital twins, extended reality, blockchain, etc.), even state of the art buildings are still pretty dumb. As my colleague Cory says below, Facebook knows every contour on my face, but the building where I work doesn’t even know I exist. We’ve got to make buildings less dumber.

As buildings become less dumb, one specific theme is emerging that we’ll be tracking on Nexus: Will the 2020s be the decade of the open ecosystem? One leading indicator could be the smart home market:

All the tech giants, as well as nearly all key players in the smart home market (…), have agreed that it makes more sense for all their products to work together rather than try to create their own closed eco-systems and battle it out.

Will the top smart building platform providers follow suit? I’m not sure.

Will our organizations catch up with technology?

Some may argue that we have the technology, but we’re behind in adopting it. We’ve got iPhone 11s in our pockets but we’re operating the building-equivalent of flip phones or even dial-up modems. I’ve been in hundreds of them. Will organizations catch up with technology? I think this is a far bigger question.

One theme that might help: turnover in the building operator profession—this could be a catalyst for digitization because younger people demand tech and owners want to attract them. As Pook Ping Yao said recently:

I do think new recruits will want to build bold new technologies. We might just hit two birds with one stone, by appealing to new talent with the promise of modern technology, and by leveraging this modern talent to design bigger and better new technology.

Another perspective comes from Antony Slumbers:

Knowing how to work together with the machines is the human’s killer app. Unless you learn how to enable technology to augment yourself as a human, you are going to lose to someone who can.

🤔

Will we radically decarbonize the buildings industry?

To keep average global temperature rise to less than 1.5°C—which the IPCC states is necessary to avoid catastrophe—we need to bring every building we touch, (likely about 5 million buildings per year in the US alone) to zero emissions in a way that is both cost-effective and supports decarbonization of the grid. That’s a heavy lift. To do it, here’s what we need to do:

1. We need laws like Local Law 97 in New York City to spread across the world.  They’re setting minimum levels of efficiency for each building type and creating requirements for new and existing buildings.
2. As RMI has laid out, we need to electrify everything, integrate smart buildings with the grid, and implement the low-hanging fruit—ALL OF IT. Analytics supports all three, especially identifying and maintaining the low-hanging fruit.

We need a new design and construction culture. As Stephanie Carlisle says, low-carbon architecture is ethical architecture.

We need to be as excited about decarbonizing the building sector as we are about making the tallest towers in the world, works of great cultural significance, or exquisitely crafted details.

3. Smart Humans

When thinking about the 2020s, especially given how much we need to change, it’s tempting to hang our hopes on big resolutions, goals, and detailed life plans. I think that’s a recipe for unhappiness—one that’s bound to let us down—and I agree with Sahil Mansuri:

Life is random. You didn't plan this (past) decade out. Neither did I. Let's just focus on enjoying the journey, not the destination.

While we have a long way to go this decade to get where we should and need to be, let’s take it one step at a time, my friends. 🙌

OK, that’s all for this week—thank for reading nexus!

If you have thoughts on this week’s edition, head on over to LinkedIn:

Comment on LinkedIn