How to Design Your Control System to Take Advantage of a Building Analytics Engine

Schoenfeld

So you got the green light to add a building analytics engine on your new project? Now it's time to get started on the control system design. Whether you’ll be applying analytics for a new construction project or as part of a controls upgrade, you have to keep the end-game in mind at every stage of the design process. The performance of your enhanced visualization, fault detection and diagnostics, or real-time optimization will depend upon the design of your control system. Here are a few design considerations to get the most out of your new building automation system and analytics engine.

Network Speed
It all starts with the speed of your network and your data throughput. Don’t get stuck using a straw when you really need a garden hose. How to design a fast, reliable network is a topic for another article, so we’ll just touch on a few basics here. One key pinch-point of any network architecture is the serial communication. Whether it's Lon or BACnet MS/TP, it doesn’t matter, the typical rule of thumb for the number of devices on network segment does not apply to your analytics project. Not if you want fast, reliable data from those VAV box or FCU controllers. Limit your serial network segments to around 15 devices and consider how many points are included in each device.

The other basic need for a building analytics project to thrive is a superfast IP backbone. That means no shared network with the IT department. For larger projects that also means fiber optic communication. The cost difference will be marginal, but the performance and increased lifespan will be significant. Your new building analytics project will need to process lots of data at impressive refresh rates. A limited device, OT-only network keeps data flowing securely without bogging down the IT network that your building is using on applications like email and public wifi.

Data Storage
Now that you have a fast, reliable network make sure you are equipped to take advantage of it. Data storage is cheap so don’t skimp. Specify a system that saves years of trend data for every single BMS point at intervals as small as one minute. A database with solid compression could keep two years of 1-minute interval data for 10,000 points in less than 20GB—you can get more memory on your next smartphone. If storing that amount of data seems excessive, consider the time- and money-saving of these real-world use cases:

1. To identify cycling compressors, valves or dampers your analytics engine will need high frequency data on the order of once a minute. Catching these issues before they cause mechanical failures will add years to the life of your equipment.
    
2. Your system can also tell you when it’s time to clean your condenser coil or change your fan belts, preventing failures and reducing unnecessary maintenance. But in order to implement this type of predictive analytics you’ll need many months, if not years of data to effectively develop robust performance predictions that take into account annual occupancy and weather patterns. 

Make Data Make Sense
Now that your OT network is securely processing building data at high speeds and your dedicated servers are saving the data at appropriate intervals, how do you make sense of all the zeroes and ones? How can all the information be organized in a way that is easy to review and search?

The fundamental concept behind any analytics engine is the data model. You don’t have to worry about this organization before your project starts, but you’ll save yourself a big headache if you do. Applying a data model and data analytics to a disorganized BMS can be incredibly costly, but specifying even a basic structure before your project starts can be fairly painless.

Specify the points list you want communicated from each device along with a strict point naming convention. While this might seem obvious, this is not included in the design on the vast majority of construction projects. There are even a few large and prominent control systems out there that don’t use point names at all, relying instead on a combination of letters and numbers to specify the software and hardware points of each controller, such as AI02 and BV12. Imagine trying to organize 10,000 point names like these.

If you’d like to take the additional step of completely specifying the data model at the outset of your project, don’t recreate the wheel. Instead, chose an existing methodology. We use the Project Haystack metadata tagging model. But just specifying this data model is not sufficient. We still must provide a list of points and the appropriate tags to limit costly integration issues on the back end. While you may have selected a great controls contractor, it is unlikely they are intimately familiar with the data model you’ve selected or understand the needs of your new analytics system. 

While there are many more details that make up an effective and powerful building control system, these three design considerations will make the implementation of an analytics platform a much easier proposition. You are now ready to realize the potential of that platform to improve occupant comfort, reduce utility costs and increase operational efficiency for years to come.

About the Author
Jon Schoenfeld is the director of Energy and Analytics at Kodaro.