Building Automation Systems Don’t Know HVAC Equipment Exist
January 10, 2025
By Nick Gayeski, Co-CEO, Clockworks Analytics
Among those who connect buildings to Clockworks every day, it’s no secret that building automation systems (BAS) don’t have a concept of what heating, ventilation, and air conditioning (HVAC) equipment they control.
A human being can figure out the equipment in a BAS from graphics, programs, device names, point names, and other clues. For example, the device name or BAS path could list the name AHU1, or a heating plant graphic could show HWP1 and HWP2, which makes it pretty obvious that there is an air handler and two hot water pumps to both a human being and to AI. But this information across BAS, even within a BAS, is never reliable or consistent. You could just as well find devices labeled AHU 1.1, 1.2, and 1.3 that all serve one large AHU or that represent three separate AHUs, 1.1 through 1.3! Who knows!?
What it boils down to is that the BAS itself can’t definitively tell you that there is an air handler called AHU1. You, a human, must figure it out or fix what AI guesses wrong.
I’ve spoken to many BAS manufacturers who are developing solutions to this issue, adopting ontologies through which to define equipment within the BAS and communicate, machine-to-machine, information about it—such as what points it relates to, what other equipment it relates to, and so forth. Clockworks creates this metadata when we onboard buildings and equipment, but it would certainly be easier if it were readily available for us to inherit from the equipment themselves or their controlling BAS. Unfortunately, it will be years before versions of BAS with inherent equipment understanding are common out ‘in the wild’ of real buildings. For the foreseeable future, we will be applying ontology to buildings, including specifying what equipment exists within them, after the fact.
“Unfortunately, it will be years before versions of BAS with inherent equipment understanding are common out ‘in the wild’ of real buildings.”
Fortunately, at Clockworks we have built tooling to help infer what exists within a building, extracting features from file structures and device names and so forth, and use generative AI and machine learning broadly to help do it. The metadata we create when we connect could easily be fed back to other enterprise facility or BAS systems to help fulfill other use cases, but can these facilities systems use that information? Are they ready for it?
There is a lot of noise in our industry about metadata. The software or hardware that are the ‘source of truth’ about equipment is unclear. There are many sources of truth. Computerized maintenance management systems (CMMS), integrated workplace management systems (IWMS), computer aided facilities management (CAFM), and capital asset management software all position themselves as a system of record for buildings and assets. They could be, of course, and yet anyone who has sifted through the swamp of a CMMS database knows there are a slew of issues, always – buildings missing, systems or subsystems not defined, all zone units missing, and so on.
Of late, there has been a lot of interest in the ‘independent data layer’ or IDL. It would be wonderful if someone else went through the trouble of assembling all the metadata required to define equipment, devices, and points and their properties sufficiently to fulfill any use case for a building such that when we connect Clockworks – it is plug and play. Utopia!! In practice, there is a danger of having yet another system where metadata and properties may or may not exist about an asset, a point, a device depending on how far an organization takes it and how committed they are to maintain it. All IDL companies will need to answer the question, how will their system adopted by portfolios that already have holes in their current “systems or record” solve that problem cost effectively? If there is a good answer, it’s good for all.
The BAS manufacturers are indeed developing solutions to internalize the definition of equipment and metadata within the BAS, meaning that the BAS will know that a certain program, graphic, or point definitively relates to an air handler called AHU1, even if that air handler is related to three controllers named AHU 1.1, 1.2, and 1.3. A system like Clockworks or anything else that could support it, whether it is another vendor’s application, the BAS manufacturer’s other products, or anything else, could then benefit from inheriting metadata from the source of data. But, how long will it take for these systems to be prevalent in the field? And as that future emerges, downstream devices like actuators, sensors, and other hardware will have their own embedded metadata to exchange.
My point really is that there are, and will continue to be, many different hardware and software systems that all contain metadata about equipment, points, and devices. There is value in the BAS, CMMS/IWMS, hardware, and perhaps other sources of asset information all being able to expose their metadata to truly allow interoperability. No one system is going to have it all. Consequently, we are staying focused first and foremost on the metadata we need to create value for our clients and partners, and the path of least resistance to utilize that data from client facility information systems.
We do anticipate this multi-modal nature of systems, and their metadata will persist, and so we collaborate with our partners, competitors, and coopetitors to foster a future of interoperability among these systems through Project Haystack and BRICK. For these standards to be successful, validation is the key. Hardware and software vendors need to define templates of metadata within the ontology, against which instances of buildings and equipment can be validated for interoperability, through work like Xeto.
Back to earth… for now, BAS still don’t know that equipment exist—meaning Clockworks can’t make a software request of a typical BAS to tell us what equipment it controls—because it doesn’t know. And, as we at Clockworks pick up the pace of connecting building portfolios all around the world we will continue to collect, document, and create metadata about building systems that, in the long run, will have value well beyond even the tremendous impact we are able to drive today.
Back to blog