Clockworks Information Model
May 4, 2021
Consistent Building Analytics at Scale
Last week’s post, SH*TTY DATA IN ≠ SH*TTY DATA OUT introduced Clockworks’ dynamic information model and the approach that makes it the most robust and conclusive in the industry. That’s a bold claim, and this blog backs up our boldness. We’ll dive deep into each component of the information model and show why it’s required to enable successful fault detection and diagnostics (FDD).
Before we begin, let’s start with an analogy for how the building industry is currently classifying data from a Building Management System (BMS). Consider the English language. Project Haystack provides the equivalent of a dictionary. It gives you words and, to an extent, the definitions of those words. It’s mostly limited to nouns: coil, fan, point. Brick Schema gives you words too—it provides the verbs in the dictionary. For example, this thing feeds air to this other thing. Or this thing feeds water to this other thing.
Unfortunately, we need more than just nouns and verbs to speak English. We need additional rules to make our words form sentences and convey meaning. Taking it back to modeling building system data, FDD requires an information model that is built to convey this extra meaning in a consistent and machine-readable format. Clockworks’ information model does just that, enabling our analytics to scale up without relying on human translators.
To begin, let’s introduce the five parts of the Clockworks Information Model one by one and show how they’re applied to a standard air handling unit (AHU), AHU1 with 14 simple analog input (AI) points from a BMS controller.
1. Equipment Templates
Clockworks defines equipment, such as an air handling unit, by a name, such as ‘AHU1’, but also by a predefined equipment template, which is described by its class and type.
For example, AHU1 would belong to an equipment class, such as ‘Air Handling Unit’, and an equipment type, such as ‘Air Handling Unit with Economizer’.
Classifying the equipment in this way aligns it with a predefined template in Clockworks. The template implies certain expected behaviors such as that it delivers air, that it has an economizer, that it may perform heating and/or cooling, that it has fans, and that it should be associated with specific components and data points.
With the template applied and data points discovered, we can now analyze those data, right? Not so fast. The problem with buildings is that they’re all snowflakes. There is no golden template for any of our equipment types, so we must get more descriptive.
2. Equipment Variables
In the real world, we might need to manipulate the equipment template to say, “well, maybe this preheat coil is actually over here in front of the mixing box.”
Something as simple as shifting that coil location could completely change the way this piece of equipment needs to be analyzed. The way the air is moving throughout this unit and the position of every single component really matters to the FDD analysis.
That’s where metadata we call Equipment Variables come into play. These variables can be configured to define geometry, as shown above, or represent concepts like the expected behavior and engineering characteristics of the equipment, as shown below.
As shown in orange, equipment variables could define the rated air flow of the air handler in cubic feet per minute (CFM) or the expected discharge air temperature control strategy such as ‘Reset by Return Air Temperature (RAT)’. These are important properties that can be represented by predefined equipment variables such as ‘HasSupplyTempRAResetSchedule’.
3. Point Types
Similar to equipment templates, Clockworks defines points, such as a ‘SA_Temp’, by a predefined point class and point type. For example, the ‘SA_Temp’ may belong to AHU1 and be of type SupplyAirTemp in the class Temperature. Point types are integrated into the equipment templates so a user can direct the discovered data points from the BMS to reserved spots within the template, as shown below in blue:
In other words, the specific combinations of point types uniquely identify the point and define its purpose within the equipment operation. This is analogous to Project Haystack’s concept of point prototypes.
As you can see, even with points mapped to a specific equipment template and variables applied, there are still many gaps in the data model that need to be filled in to enable robust and scalable FDD. Let’s proceed.
4. Relationships
Relationships between objects exist to define how points, equipment, and systems are related and should be expected to behave.
Within a piece of equipment like an AHU relationships can exist between components of the AHU itself to determine how individual setpoints and sensors control the valves and dampers providing heating, cooling, and ventilation. Relationships between sensors, setpoints, and the logic embedded within the controller itself must be included in the information model to accurately model the equipment operation.
In Clockworks, relationships can be automatically inferred based on the equipment template and point types selected. In the example below, Clockworks will infer the AHU is utilizing a differential drybulb economizer sequence based on the selected equipment type (AHU with Economizer) and the combination of Point Types selected (no enthalpy points available, but return and outside air temperature are available). Clockworks will also infer the unit is designed to dehumidify by cooling/reheating based on the user-provided ReturnAirRHMax Equipment Variable and a lack of alternative dehumidification points on the unit.
Physical relationships also exist between the AHU and other equipment in the building. These relationships define how hot and chilled water is fed to the AHU from the chiller and boiler plants, and how the air from the AHU is fed to the various VAV boxes throughout the areas the AHU is serving. Clockworks models these physical connections as well, allowing users to create parent/child relationships between equipment and uses those relationships to improve the analysis capabilities on each piece of connected equipment automatically.
In the AHU example below, the Chiller/AHU, Boiler/AHU, and AHU/VAV parent/child relationships are established:
In some cases, defining relationships among equipment can signify a system. For example, a chilled water plant can be created as its own ‘system’ level equipment which contains child equipment such as chillers, pumps, heat exchangers, cooling towers, and hydronic loops.
5. Automatically Calculated Points
Finally, Clockworks calculates the remaining gaps in the equipment template automatically. It uses logic to combine what we know about the piece of equipment to create new data points that look and feel just like actual control points and help us do a better analysis, as shown in green in the figure below:
This includes data like the real-time power on a fan when it’s not being measured. Or the energy load on a coil. We calculate these points because the typical building management system (BMS) isn’t going to produce these more advanced outputs on its own, and yet, they’re vital for a higher level engineering analysis.
This approach, built up over a decade of deploying FDD at scale, goes far beyond simply tagging points from the BMS. The flexibility and comprehensiveness of the information model within Clockworks enables our FDD analytics to run across 400,000,000 sq.ft. of buildings everyday—without having to write custom fault rules or equations to deliver consistent diagnostic reports.
As you can see, the Clockworks information model—which combines equipment templates, point types, inferred relationships, and calculated data— provides the most robust and holistic approach to data modeling in the industry. As we mentioned at the start, it is still an important step for the broader industry to develop a standard data “language.” We have participated in the ASHRAE Standard 223P committee, and are excited to work with Project Haystack and the Brick Consortium to continue to share our dynamic approach to information modeling to help drive the industry toward a universal standard. For Clockworks Analytics, accelerating data interoperability standards underscores our commitment to help the industry-at-large turn operational data into real-time insight for healthier buildings in a scalable way.
Back to blog