Across many industries, there is a current drive to adopt what is called “Semantic Modeling”. Words like Tagging, Data Modeling, and Ontology are starting to get their day in the sun. The Building Automation / Smart buildings industry is no exception. The idea of semantic modeling is not really a new one and has been used in web technologies for a while. Companies you are familiar with, like Facebook, LinkedIn, Youtube, and many others, use them directly in their products. Due to the usefulness and universality of semantic modeling, the rise of AI and machine learning, and the trend to converge IT and OT (Operational Technologies), it is making its way into many of the operational systems, for instance, the BMS systems running our commercial buildings.
Semantic Modeling, in its most basic explanation, is adding a standardized layer of data above your existing more basic data (e.g. a Signal’s value of 21) to add a description to the single units of data (for example, a BMS Datapoint), along with adding structure, hierarchy, and relationships between different units of data.
Applying semantic modeling helps achieve many goals, among which are normalization and consistency of data, which in simple terms, means that data from different sources should be identified in the same way and comparable to each other regardless of the source. This makes things easier for whomever (a person) or whatever (machine/software) needs to use the data.
Semantic modeling is being used by new or relatively new initiatives in the BMS world. Initiatives like Haystack, Brick Schema, RealEstateCore, and the upcoming ASHRAE Standard 223P, among others, use semantic modeling to describe buildings and their operations, of which BMS is a big part.
What is the status of the different initiatives/standards now?
There is not yet a standard to rule them all, and the fact is, there might never be one for different reasons, among them is the difference in scope of these initiatives. The official standard from ASHRAE 223P is not yet finalized. Many companies decided to move forward with other initiatives, either due to the competition and time-to-market worries or because 223P is likely to be more complex than the needs of many of the use cases these companies have in mind or simply does not fulfill them. The other initiatives like Haystack, Brick Schema, and RealEstateCore are not standards yet and are continuously and rapidly evolving, and as you can imagine, each has its pros and cons. As a BMS engineer, you may have already started seeing these Initiatives/Standards being adopted by some BMS and Building IoT manufacturers. In contrast, others might prefer to wait until the ASHRAE standard 223P is officially out or until a clear winner among these initiatives appears on the market.
While there are several initiatives on the market, the ones most relevant to BMS systems and Engineers are Haystack, Brick Schema, and RealEstateCore. Other initiatives on the market, like IFC and BOT, are less relevant to BMS or less active in the space, like Google Digital Buildings.
Some of these initiatives have very similar scopes, like Haystack and Brick Schema, focusing more on the technical side of things like Equipment types, Sensor types, and the like, while others, like RealEstateCore, focus more on the property management side of things while overlapping with the technical side as well.
To understand the differences between these initiatives from a technical point of view, it is important to understand the technologies behind them, like Tags and Ontologies / Graphs.
Tags
Let us start with tagging first, Tagging is basically adding textual descriptive Data to an existing “Thing”, similar to how you would stick a sticky note or a label on an object to say something about that object. To give an example outside the BMS world, If I want to “Tag” all the things in my kitchen, starting with the oven, for example, I would say first stick the word “Oven” to say what that thing is, I may also add another sticky note with the word “Cooking” to explain what an oven is used for, or the word “Electrical” to indicate that it uses electricity as opposed to gas for example, and add the word “Equipment” to say this is a type of a device not furniture and so on. If I do this for all the “things” I have in my kitchen, like my fridge, cabinets, etc, then anyone can go into this kitchen and understand what the “things” are and what they do without me having to do any explanation.
In BMS terms, these “things” might be your equipment, like an Air Handling Unit, Boiler, Chiller, or your data points, like supply air temperature, room humidity sensor, and exhaust fan command. Descriptions of these things, say your supply air temperature, might have the tags “Sensor”, “Air”, “Temperature”, and “Discharge”, while your humidity room temperature might have tags like “Sensor”, “Air”, “Room”, and “Humidity”.
Tagging systems follow a defined tagging vocabulary containing all the possible Tags in a certain domain or business area. Some of these Tags define a thing, some of its function, others its measured medium, and the like.
Some initiatives also have value tags or reference tags, which are more dynamic than the static ones mentioned above. These aim at not only describing what a thing is but also describing its relationships, like which VAV Box gets its air from which Air Handling Unit, and in some cases, live values, stepping into the communication protocol territory.
Applying tags to a BMS Project means defining equipment, spaces, data points, and other things in the building and adding Tags to them from a set of the vocabulary defined within a tagging system.
If software wants to find something, it has to search (filter) for a certain tag or a combination of tags, like Find anything that has the Tags “Sensor”, “Air”, and “Room”.
The Tagging approach is heavily used by Haystack, especially version 3.
Ontologies
While Tagging systems are very good at describing a thing, simple text tagging falls short when you want to put the “thing” into context. Putting something into context means describing the type of the thing and the relationships between the “thing” and other “things”, an example of this in the BMS world is when you want to describe the space or spaces that an Air Handling Unit supplies, if you think of the air handling Unit as a thing, and the served space as another thing, then you can say that the first thing (the Air Handling Unit) has the relationship “Feeds” to the second thing (the space). suppose you want to describe a more nested type of relationship, like describing an air Damper that is a part of an Air Handling Unit, which is located in a room, which is a part of a floor, which is, in turn, a part of a building within site. In that case, Adding Tags to all of these things (Damper, AHU, Room, Floor, Building, Site) to describe their relationship to each other is not exactly practical, this is where Ontologies can help.
A simple way to explain an ontology is the following: we humans tend to think of things in their classifications, i.e, what things are (types/classes/categories), and their relationships to other things. Taking another example outside the BMS world, If we start with the classifications first, and say you want to describe what a car is, you might start with the basics, for example, with the main type “machine”, under this main type, there can be several types, like manufacturing machines, Sport machines, Vehicles, etc…, going down the vehicles branch you may have different types (classes), Transportation vehicles, Agricultural vehicles, etc…, under the transportation vehicles, you might find land transportation vehicles, air transportation vehicles types, and under the land transportation you might find trains, cars, etc… You can imagine this as a tree structure starting with machines, down the tree to cars in this example. So, a car is a “machine”, a “vehicle”, a “transportation vehicle”, and a “land transportation vehicle,” all at the same time.
Ontologies describe all the possible types (classes) of things and all the possible relationships between them in a well-defined vocabulary and hierarchy in a certain domain.
In the BMS and smart building domain, ontologies focus on classifying equipment (Air Handling Units, boilers, chillers, smoke detectors, thermostats, etc…), BMS points like sensors (supply air temperature, room air quality, water return temperature, alarms, commands, etc…), as well as spaces (sales area, cafeteria, office room, etc…). They also define the possible relationships between these things, like feeds (air Handling Units feeds sales area), located in (light fixture located in Office), part of ( damper is a part of Air Handling Unit, Office room is a part of a floor, etc…) and other relationships as well.
Applying Ontologies to a BMS project means classifying all equipment, data points, spaces, etc… in a certain building and describing the relationships between these components following the classifications and relationships vocabulary defined in the chosen ontology.
For a specific project, the result is called a Graph, and it resembles drawing all the things (Equipment, Rooms, etc…) in your building on a whiteboard and linking them with arrows to indicate how they relate to each other. The software could query (ask questions to) this graph and get the desired results. For example, suppose certain software wants to visualize the values of the room temperatures in all rooms on a certain floor to show a simple dashboard. In that case, it will query the graph for anything that is classified as a “Zone Air Temperature Sensor” and look for any matches which have the relationship “Has location” with any of the rooms on this specific floor. The system will find out which rooms these are because they have the relationship “Part of” with the floor in question. The question the software might ask can even be more generic, as in Show me any sensor located on this floor, and it will still get an answer. This allows software products to ask many different questions in many different ways to the same graph and get the answer they need, covering many current and still unknown future use cases.
What is the difference between them?
The difference between Tagging and Ontologies may not be very apparent to a BMS engineer when applying them to a certain project and will depend on how a manufacturer will present these concepts to the BMS engineer, however, as explained above, the technology behind each of them is different. You can think of Tagging as adding sticky notes to something, while Ontologies are like drawing a network of nodes (Things) and connections between things (relationships). Tagging systems have the advantage of being easier to understand and apply, While ontologies have technical advantages and allow more freedom in how other systems can use the data and what type of questions (Queries) these systems can ask. Many initiatives like Brick Schema, for example, are natively Ontologies but provide Tagging systems within them as well.
Why not follow a good naming convention?
Many projects follow a strict naming convention (at least on paper, that is), which is really nothing more than trying to describe a thing and its relationships in the name of a data point. In the BMS world, you might have a name of a data point as follows:
If you are a BMS engineer, you can probably guess from the Data point name some of the equipment involved, served area, the controller where the control logic resides, and what the data point is, which is basically describing what a thing is and what relationships it has.
This naming convention approach has many issues, though, for starters, there is no real standard to follow for naming, and all are manually done on a project-by-project basis by different people, making the process inconsistent and prone to errors. From a technical point of view, most systems have restrictions on the length of the name you can give to a data point, which means either you cannot really say everything you want to say about the point or Equipment (all descriptions and relationships) or you have to use increasingly small and confusing abbreviations to keep the number of characters within a limit, leading to the confusion of other BMS Engineers, let alone facility operators. As you can imagine, if someone wants to use the BMS data for anything else than a tailor-configured BMS supervisor, these names and abbreviations will be a nightmare for the machine (or the person behind the machine) to decipher, making the process too slow, and not scalable if possible at all. Of course, this problem becomes even more obvious to Facility management companies if they want to introduce new software to operate multiple buildings with different technologies implemented by different system integrators, and god forbid, in different countries with different languages.
In short, naming conventions cannot handle all the needed descriptive data, nor do they provide scalable and consistent solutions to utilize the data for other purposes.
Are ontologies and tagging communication protocols like BACNET and MODBUS?
No, Tagging systems and ontologies are not communication protocols like BACnet or Modbus. They represent an extra layer of Data on top of the existing one. However, some initiatives like Haystack and REC (RealEstateCore) define both Tagging systems / Ontologie and ways to communicate between systems using APIs, which are usually meant for Server (Cloud) communication but some implementations use it on a field level (on the Edge) as well.
That being said, BACnet itself might end up including Tags, Classifications, and relationships within its specifications and objects in the future.
Why are we doing any of this?
The fact is, we, as BMS engineers, already do something similar, when we define our Data points, we need to give them names, and those names should somehow make sense. When we create graphical interfaces for our BMS Operator, we give names to pages, we may mention an AHU and its served area, and we create links between navigation pages to give context to the operator, for example, create links from a hot water circuit page to it’s served Air Handling unit page, or from an air handling Unit page to the floor plan with VAVs showing the temperature of the served rooms, etc…
We also do double work if you think about it, for example naming an Air Handling Unit in the logic Program and then adding a similar text again in the graphical interface page.
The promise of Semantic modeling within the smart building industry is consistency and the possible “Automation” depending on this consistency, along with the ability to use the data for many different purposes. So what does that really mean?
If you look at what BMS Engineers do at the moment, they Tailor-configure a BMS system (Hardware and Programming) to a project’s specific needs. As in tailoring a suit to fit a customer, the “style” of the Engineer will show in the BMS, for example, in the naming convention they choose or in the program logic they apply. This process is labor-intensive, slow, and produces inconsistencies across different customer sites, especially when different BMS systems are used. From a system operator point of view, especially ones with many sites to operate, this is problematic as they have to deal with unnecessarily different implementations of essentially the same thing. for example, if they need to use the data to produce a report on equipment performance or something as simple as temperatures across different sites, etc… they will run into trouble. This prohibits building any solution on top of the existing BMS as the data is almost not used anywhere else, not without a huge effort, at least. This also prevents the scalability of any solution, as scale needs consistency. If a clear data description is available, it is much easier to use it for other purposes.
This also opens up the potential for smaller innovative companies to create new solutions using the BMS data, as they can rely on the consistency of the data underlying their solutions. This also allows building operators to avoid the costly manual work involved in linking new systems that might use the BMS data. All of this creates more options for system operators and facility management companies to enhance their operations by choosing from a wider range of solutions available to them on the market to fit their exact needs, at the end of the day, the needs of a Hotel and how they might use BMS data for other purposes can be very different from how a retail store or a hospital might.
Which standard should I choose?
Suppose you, either as a BMS contractor or an MSI (Master Systems Integrator), find yourselves in a situation to choose between one of the initiatives to apply to a current customer project, you will have to take several things into consideration, like the application you have in mind. How many BMS data points does this application need, are you building this for future-proofing or just for a current specific purpose in mind, what technologies are available to you at the time, and the skills at hand?
In general, If you are looking for something which can be applied now and have a specific use case in mind, there are products on the market which support Haystack 3, and some even partially support version 4 (Although it has not been released officially yet, to my knowledge). Haystack 3 heavily depends on Tagging and is generally easy to understand, it also has the advantage of having an API specification already, which is helpful if you are required to connect to a 3rd party system through APIs (although, to be fair, some details of the API used are different from what many modern programmers are used to). Haystack also has the advantage of being older on the market, so you will probably see more products supporting Haystack than the other initiatives, although the others are also starting to catch up. Haystack 4 should include much more than only tags. It comes closer to the functionality available in Brick Schema, and probably edging it in some scenarios, only utilizing other technologies under the hood. There are efforts to harmonize Haystack with Brick, as well as they have very similar scopes.
If you are looking for a more modern and future-proof Ontology-based solution that can serve current and future use cases, have the patience to dig deeper into new territory. If you are a software developer or an MSI willing to invest in newer technologies (like new types of databases / Cloud technologies), I would either recommend Brick Schema, if the use case is more on the technical side of things like the details of Equipment, Sensors and data points and how they interact with each other, or RealEstateCore if the use case is leaning towards the business and property management side of things rather than a very technical one, especially if you are already using Microsoft Azure services and their implementation of digital twins. That being said, Brick Schema does support a Tagging system to describe things like Haystack does, and the recent Harmonization between Brick Schema and RealEstateCore will mean you will not need to choose between the two anymore as practically speaking, RealEstateCore is already using a big part of Brick schema into its Ontology and vice versa, and if you start with either of them, it will be easy to extend to include the other at a later stage if required by the customer and the use cases.
RealEstateCore also has a definition for an API to communicate with other software. Ontologies / Graphs, which is the technology behind Brick and RealEstateCore, also has a lot of open source tools (for example, to read and edit RFD files) which makes choosing them less of a pain and overall better prepared for future use cases considering the rising trend of Graph-based Machine learning and the use of Natural Language Processing to ask questions and give commands utilizing the knowledge held in these graph in a similar way to how you can speak to a virtual assistant like Amazon Alexa to turn ON/OFF the lights in your smart home.
The ASHRAE 223P working group is also in contact with Haystack, Brick, and RealEstateCore to harmonize efforts as well.
So, the good news is that whatever you end up choosing, chances are that your investment will be preserved in the future regardless of which initiative ends up taking which share of the market, as there are ongoing efforts to harmonize these initiatives.
Links and references
https://www.realestatecore.io/
https://bacnet.org/working-groups/si-wg/
#smartbuildings, #buildingautomation, #bms, #internetofthings, #proptech, #RealEstateCore, #Brickschema, #ProjectHaystack, #MSI, #bacnet
