AutomatedBuildings.com Article - Best Practices for Building Analytics

The term “analytics” is thrown around a lot these days. From enhanced visualization to fault detection and diagnostics, analytics can be used to describe it all. And it’s all progress in our quest to make use of the data we collect from modern buildings. However, our ultimate goal is to generate the correct response from the data we’ve analyzed. Analytics that either inform an action of trained operators or automatically improve a system’s operation are called Responsive Analytics, and they’re the end game we’re all working toward. Responsive Analytics are those solutions that drive positive, productive change in our facilities. We use the following best practices to make our analytics more responsive.

The needs for each company, institution or municipality can vary. Even individual stakeholders may require different information or hold certain findings of higher importance than others. While some may focus entirely on energy usage, others are driven by occupant comfort or equipment reliability. Analytics can certainly provide insight for all, but weeding through what doesn’t interest you should not be a chore. The first step in a successful analytics approach is a carefully thought-out organization of the rules and reports that are actually needed so each company or stakeholder can quickly and easily find what matters most to them.

Beyond a classification of rules, there must also be a way to prioritize the findings of your analytics engine. Ideally, priority would be a proxy for the financial impact of the issue, but that’s not always possible. What’s the cost of uncomfortable tenants? And what is more important, the financial impact of a past event or the future impact if it isn’t resolved? However you evaluate priority, simply assigning a High, Medium and Low value to your rules will not suffice.

Consider this: You log in to your alarm console and look back at the past seven days. You see that a “Medium” priority issue has been happening 24 hours a day for the whole week. During that same week, your “High” priority issue occurred for only one hour. Which issue from that week would be your real highest priority?

It is better to identify five issues conclusively than to report 10 issues where two are false. Why? Because it is difficult to regain the trust of your facility staff once they’ve spent time investigating a false alarm.

The job of limiting nuisance and false alarms is not an easy one. In some cases, it’s a larger task than identifying the issue, to begin with. Poor data quality, communication problems, faulty sensors, data modeling errors, and controller failure can easily manifest themselves as some unrelated issue, sending your facility staff off on a wild goose chase. If your analytics provider hasn’t explained how they are going to address these concerns, it’s time to ask a few key questions:

A crucial step towards responsive analytics is providing a clear and useful message to the user. This starts with a succinct description of the observed conditions which resulted in the fault detection, followed by a list of possible causes and the recommended next steps to solve the problem. These messages should be as detailed as possible without drawing false conclusions. Here are some examples of the full spectrum:

The cooling command is on while the Space Temperature is less than the setpoint for two hrs. The cooling may be in override, the effective setpoint may be incorrect, or the control of the cooling command may need to be tuned. Check to see if cooling is overridden and that the effective setpoint is correct for the occupancy status of the AHU.

The cooling command is on while the Space Temperature is less than the setpoint for two hrs. The effective setpoint does not match the occupied cooling setpoint. Check to see if the occupied cooling setpoint and effective setpoint have been mapped to the correct point for the AHU.

The analytics community strives to create rules and algorithms that pinpoint the root cause of every issue, but in practice, the cause is not always so clear cut. Our last example is an illustration of how two analytics – one for unnecessary cooling and one for an incorrect setpoint – can be combined to get us closer to a root cause. But even with those two analytic points, we require confirmation of the real issue before a solution can be complete. Those who claim their analytics can nail the root cause in all circumstances probably do not have the experience to know why that’s not possible. Instead, your analytics should lead people toward the solution by telling them what additional information must be confirmed.

[an error occurred while processing this directive]If your analytics engine is worth its weight, it is likely going to produce a lot of findings, especially when you first turn it on. It is easy to be overwhelmed with a seemingly never ending list of action items and problems to investigate. A good system should throttle what is provided to the end user. Whether this comes in the form of targeted reports, advanced issue filtering, or user-defined views the action items for your team should be easy to find and limited to only what can be realistically accomplished. The prioritization mentioned above is a prerequisite for this type of reporting. It’s important to remember that our goal is to solve problems, not just to identify them, so a to-do list of 20 items when you only have time for five isn’t helpful. Especially when the list changes every week.

To be cost effective, analytics are developed in broad strokes so they can apply to many different systems, equipment types, and buildings. That doesn’t mean there isn’t a need to develop algorithms and rules that address the unique issues of your facility. A flexible platform that allows for customization provides the most assurance that you will get what you need from your analytics engine.

Most analytics packages on the market today are passive, rule-based engines that identify issues and propose solutions. There is significant momentum now for both real-time optimization and machine-learning that will change the way we think about analytics and FDD in the coming years. We’ve all got our eyes on the Responsive Analytics prize, but to get there, we need to establish a strong foundation for analytic understanding with a focus on the usability of the products as they stand now. The information needs to be relevant and readily available. Operators need to see the information improving work flow while managers need to see it impacting the bottom line, all without overloading anyone with information that’s not crucial to meeting those objectives. If your analytics engine is built correctly now, it will enhance workflows and support cost savings while being able to expand quickly as Responsive Analytics takes over in the not-so-distant future.

Jon Schoenfeld is Director of Energy and Analytics at Kodaro. He applies his deep technical knowledge of building system design, engineering and operation to Kodaro's growing list of analytics products and services. Schoenfeld has been an engineer in the renewable energy and energy efficiency fields for more than 15 years.

Events	Want Ads
Our Sponsors	Resources