Nexus #20 (4/28/2020)

“Part of the problem is clearly foresight, a failure of imagination. But the other part of the problem is what we didn’t *do* in advance, and what we’re failing to do now. And that is a failure of action, and specifically our widespread inability to *build*.”

—Marc Andreessen, IT’S TIME TO BUILD

Happy Tuesday! Here’s an outline of this week’s newsletter:

1. 🤔 On my mind this week: COVID-19 impact updates
2. 📈Nexus Book Club: Data Science
3. 🧰 FDD Costs, Savings, and Benefits From 550 Buildings (Lawrence Berkeley National Laboratory)
4. 🔗 SkySpark’s Distributed Architecture (SkyFoundry)
5. 💵 Trove Consulting’s Tariff Builder Extension for SkySpark

Disclaimer: James is a researcher at the National Renewable Energy Laboratory (NREL). All opinions expressed via Nexus emails, podcasts, or on the website belong solely to James. No resources from NREL are used to support Nexus. NREL does not endorse or support any aspect of Nexus.

1. 🤔 On my mind this week

Like all of you, I’m continuing to track the impact of COVID-19 on our industry. Just like I did in the first Nexus Deep Dive, I’ll continue to share my thoughts here as I have them. If you’re looking for the signal in the noise, here’s the best COVID-19 content I’ve seen this week:

1. IT’S TIME TO BUILD (Marc Andreessen)
2. Empowering building engineers in digitized assets to respond to the COVID-19 crisis (InSite)
3. Social distancing in the workplace: the new norm (Buro Happold; check out these awesome data visualizations!)
4. Climate-informed HVAC increases in RH may fight pandemic viruses (Smith Group)
5. Forty Percent of Construction Firms Report Layoffs (Contractor Mag)

As usual, please add any signals you’ve seen to the comments.

2. 📈 Nexus Book Club: Data Science

I’ve been having so much fun with the Nexus Book Club. There are 6 of us spanning 3 different countries and 7 time zones and we get together over Zoom each week. We’re reading books that orient us on our industry’s digital transformation.

Do you want to join the group? We’d love to have you…

Thursday, we’re starting our next book: Data Science. Hit reply or email me at james.w.dice@gmail.com to join.

3. 🧰 LBNL’s latest paper on analytics

+ FDD Costs, Savings, and Benefits From 550 Buildings (Lawrence Berkeley National Laboratory)—LBNL has been a leader in the building analytics space for a long time—like before I even graduated from college. The team out of Berkeley has written 60+ papers on analytics. If you’re involved in fault detection and diagnostics (FDD), you should be aware of this latest paper. The paper is aimed at promoting and advancing FDD by answering two questions:

1. What does it cost and save? The authors summarized Smart Energy Analytics Campaign surveys on costs, savings, and common ECMs discovered through FDD.
2. What methods and datasets can be used to evaluate and benchmark FDD technology performance? The authors developed a method to evaluate and benchmark how well FDD algorithms perform, then used that method to evaluate 3 FDD software packages (2 commercial and 1 “research-grade” algorithm based on NIST’s APAR ruleset)

There’s a lot to it, so I’m not going to summarize the whole thing today. Here are my top two reactions:

First, the 27 building owners are paying a WIDE range of costs. Very wide.

I wish the paper would have explained the cause of the variance. Did I mention it’s massive? Look at the $/point column… $0.30/point—$72/point. 🧐

My hunch: it’s caused by four confusing aspects of purchasing FDD:

• There could be vastly different levels of FDD sophistication here, all grouped into one. You could theoretically provide FDD with a lot of data or very little data. More data costs more but provides a better outcome (e.g. when it’s used to prevent false positive faults). To illustrate, let’s look at some hypothetical levels, starting with the most simple:
• First level: under 100 points. Only AHU fan statuses. Faults simply check for HVAC schedules.
• Second level: A few hundred points. Only AHUs and the central plant.
• Third level: All the points, but simple rules.
• Fourth level: All the points and full diagnostics.
• One thing that might help would be to create a proxy for levels by defining a new metric: points per square foot.
• The unit cost ($/point or $/SF) heavily depends on the size of the project. In the surveyed projects, the number of points ranged from 300 to 200,000. The $/point base cost on a 300 point project is always going to be more expensive than a 200,000 point project because of economies of scale and fixed costs.
• I think there should actually be two buckets of annual labor costs. The authors grouped the following scope into this one bucket: reviewing FDD outputs, identifying opportunities for improvement, and implementing measures. The first two are relatively constant and predictable. The last one, implementing measures, is highly variable and dependent on what faults are discovered and many other variables—like what condition the owner’s equipment is in—meaning it’s not necessarily a reflection of the FDD cost.
• I think we need a “Total Cost of Ownership” metric added to that table. Here’s why: the cost buckets are different for different vendors. Some vendors have a larger deployment cost and a smaller annual recurring cost. Some vendors have zero deployment costs and a larger annual recurring cost. Some vendors don’t have an annual labor cost because it’s built into the recurring software cost. Some vendors have lower recurring software costs but higher annual labor costs to keep the software updated and running properly.

Second, I love how the authors started the discussion around evaluating the effectiveness of FDD.

This is a huge issue in the field! I think the next phase of FDD is to start demanding better performance from the solution. More signal, less noise. More diagnostics, fewer alarms. This paper is the first place I’ve seen metrics listed out that could help us evaluate performance. Here they are:

True positive refers to the case in which the ground truth indicates a fault exists and the algorithm correctly reports the presence of the fault.

True negative refers to the case in which the ground truth indicates a unfaulted state and the algorithm correctly reports a unfaulted state.

False positive refers to the case in which the ground truth indicates a unfaulted state but the algorithm reports the presence of a fault. It is also known as a false alarm or Type I error.

False negative refers to the case in which the ground truth indicates a fault exists but the algorithm reports an unfaulted state. It is also known as missed detection or Type II error.

No detection refers to the case in which the algorithm cannot be applied (for example, due to insufficient data) or the algorithm gives no response because of excessive uncertainty.

Correct diagnosis refers to the case in which the predicted fault type (cause) reported by the algorithm matches the true fault type defined in the ground truth.

Misdiagnosis refers to the case in which the predicted fault type does not match the true fault type defined in the ground truth.

No diagnosis refers to a case in which the algorithm does not or cannot provide a predicted fault type, for example, because of excessive uncertainty.

I can imagine a future where we standardize around these terms and require a minimum performance on each of them. Leading vendors can include them in their marketing and proposals to differentiate themselves. Owners can include them in their contracts.

4. 🔗 Buzzword alert: the benefits of “edge-to-cloud” analytics

+ SkySpark’s Distributed Architecture (SkyFoundry)—The latest SkySpark Insider (issue 36) provides a great breakdown of one of the features of SkySpark I think is being overlooked in the marketplace: the "edge to cloud” distributed architecture. We talked about this briefly in Nexus #3, but the Insider goes deeper.

One of the best things about it: the ability to process the data as close to the edge as possible, then pass only the results (FDD or KPI calculation, for example) across the building’s network, firewall, and internet to the cloud. If the IT/OT network is traffic-constrained, that could be a game-changer.

Check out the rest of the benefits in the Insider.

5. 💵 Let’s automate utility cost auditing

+ Tariff Builder Extension for SkySpark—Trove Consulting just released an app for SkySpark that automates the tariff analysis process. Here’s why that’s important to everyone (not just SkySpark users): There are a ton of energy professionals across the world doing this manually in massive spreadsheets. Trove’s app lets you load in the RateAcuity database of 12,000 utility tariffs (US only, I think) and automates not only the tariff tuning process, but also lets you visualize and compare calculated charges (based on the tariff model) to actual charges from the utility bills.

The next step would be to combine this with an Automated Utility Data Acquisition feed (like from Urjanet or UtilityAPI) and then write some FDD rules that detect billing errors. Then you’d have a fully automated alerting system for utility cost auditing. Boom.

The next step after that might be to feed the tariffs back to the building to inform advanced supervisory control algorithms. For example, a grid-interactive efficient building (GEB) may want to weigh the pros and cons of shifting loads based on time of day.

If you’re new to the SkySpark ecosystem, it allows advanced users like Trove to build custom applications and then sell them in the Stack Hub marketplace for anyone to use. Then, any SkySpark user can add Trove’s app to their stack without the development costs of creating it on their own. For a few hundred dollars per year, you can automate everything I just described for one electric account.

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

Reminder: Starting Thursday, I’ll start sharing exclusive content and events for members of Nexus Pro. If you’re on the fence, here are 5 reasons you might want to join, plus answers to your FAQs.