Untagged Data
Most often, a BMS contains data objects that are untagged and named in a variety of ways. Examples of untagged data you may run across in a BMS are:
When an outside observer comes into BMS 1, it can be hard to tell exactly what you’re looking at, although you can make some inferences. We can know by looking at BMS 1 or 2 above, that there is likely an air handling unit and there is probably a discharge air point, a supply air temperature point and a supply air temperature setpoint. But those are best guesses. And, are those actually the same point? We can’t be sure.
If a person wants to know anything about that information, like “Is my air handling unit supplying air at the correct temperature?” it’s difficult to provide an answer with any certainty, given only the information in the above, untagged BMS examples.
Adding meaning to data with tags
By adding meaning to the data with tags, we can be better prepared to answer that and many other questions.
These tags also make these data objects machine readable, meaning we don’t have to leave it up to a human to come into a BMS and decipher what’s going on with the equipment it’s connected to.
In the example systems shown above, once we’ve applied the tags we can see that we are looking at the same points with four different names. With tagging, naming conventions don't matter.
Now that we know what the equips and the points are, we can better answer the question “Is my air handling unit supplying air at the correct temperature?”
What does OAP enable?
Analytics and the ability to programmatically apply them.
Tagging enables you to compare points on a specific type of equipment and to create rules that compare data across equips, point sets or many other combinations of information.
Automated visualizations in Noda.
If you look at Noda, you’ll see all graphics and widgets are built dynamically based on a consistent data model. For example, data like Zone Temperature in equipment tables throughout Noda are pulled in and shown in specific areas of the application based on tags that are on that point data object in the BMS. All data shown in the Noda application is reliant on tagged data from the BMS. That means if everything is tagged properly, the equipment tables and widgets in Noda basically stand themselves up automatically.
Troubleshooting and maintenance.
When we’re all speaking the same language, it’s a lot easier to do this work across systems and across contractors. Having a standard makes it quicker for anyone working on the BMS to identify the root of the problem, without wasting time deciphering equipment or point names. The tags and the standard they come from allow the data and everyone who interacts with it to speak the same language.
Dashboards and rollups.
If a user wants to determine which VAVs are supplying air to spaces within a certain range, based on the model, that user could go through the system and pull together a report or a dashboard that displays all of that data collectively.
With a consistent tagging and data model, from project to project, customer to customer, all of these benefits can be applied across the board, quickly and uniformly.
Using the OAP to apply tags
The Ontology Alignment Project (OAP) is an openly available tagging and modeling system that algins the current building automation tagging standards into one easy to use ontology. The website is available at https://oap.cloud.buildingsiot.com/1.1/.
Anyone with an interest in applying tags can follow the OAP site and apply it by hand to their integration frameworks. For Noda users and partners, additional tooling is available in SkySpark to automate this tagging process. That tooling is covered in a separate article.
If in the course of working through the OAP website you are looking for an asset or point that is not modelled there, you can collaborate with the OAP working group via this form.
Relationships in a data model
Typically when a system integrator comes into a project all they have is a bunch of data pieces in separate controllers. The first step in integration is to link that data together and make a cohesive model of all the relevant information.
The data modeling starts with the references. For example, putting an Air reference on a VAV. This tells a machine that this equipment gets air from an air handling unit. Completing the relationship model adds detail to identify which air handling unit is supplying that air to that VAV. Analytics systems and integrated user interface applications can then create intelligence around this relationship or display it in a dashboard in a meaningful way.
Fitting it all together
An OAP integration starts with the MSI and carries through to all aspects of the deployment.
MSIs are pros at understanding all the different building systems and how they work at the edge, what kind of data we expect from them and how to model the data so that the systems work properly. Integration platforms and their cloud-based applications rely on this foundational work done by the MSI in order to be used effectively by the systems up the chain.
The software development team relies on the building systems being modeled to a consistent standard so that the usage of that data can be programmatically applied rather than tailor-made to each individual customer.
Building operators rely on the data model to monitor, operate and control their equipment via the software that is built on top of the data model.
Things to note
The OAP is a live ontology with an active working group constantly expanding the assets and points that are defined. The HVAC section is the most well-developed and as such contains most of the points that are necessary for modelling those systems.
From an integration standpoint, if a point definition is not in the OAP that doesn’t always mean the point is not valuable to integrate. The point could be valuable from a troubleshooting or configuration standpoint so it could still be brought into the system. The fact that it is not included in the OAP just means that it doesn’t need to be modelled – in other words it doesn’t need a widget in Noda and/or it isn’t needed for any analytics.
For those points that are important for troubleshooting or configuration but not needed for front-end applications or analytics applications, ad-hoc tags should not be added. Points that have incorrect tags applied are at risk of being included in a query for which that point was not intended. Tags should only be applied to the points that are specified in the OAP or through the automated process created in SkySpark (covered in a separate article).
Within the Noda UI, the section called “Cx Points” shows the full list of all points that have been integrated but not tagged/modelled. This is helpful for users who want to see all points beyond those that are necessary to fuel the widgets and analytics.