A BOS is a core platform integrating data from heterogeneous sources into a single unified interface. It's easy to say, but a few concepts and principles are necessary to understand.
Merging Static & Dynamic Data
Static Data
A physical representation of a building, an HVAC architecture or a submetering hierarchy have all something in common, they are all Static data models which is by definition information that doesn't change over time (apart from physical changes...). The static data models are very useful to understand the relationships between different assets of a building (spaces, equipment...). They provide insights to help third parties (human or digital) to understand a building's philosophy and get over its complexity. The relationships between assets can describe physical inclusions, fluid and relations that describes the interactions
Dynamic Data
In another world, we have various systems in the building that produces real-time data such as temperature, pressure, valve positions... Dynamic data is a value varying over time. Dynamic data is produced from BMS/BAS equipment (HVAC, lighting, meters...), from IoT devices (people counting, air quality...) and also from silos like access control, lifts or even third parties. Dynamic data can take the form of a primary values such as numeric, a boolean or be more complex (JSON, csv...).
A dynamic data is usually acquired from a traditional BMS/BAS protocol (BAcnet, Modbus...) or from APIs.
Getting a context
A Dynamic value has a very limited use on its own (it is just a value varying over tile). Most of the traditional BMS/BAS systems applies a simple label to a dynamic data (like a temperature) and displays it to a synoptic with the single purpose to provide a technical interface for a Facility Manager. But there are many applications out there looking for intelligible data from buildings to improve their service. It is really hard for a third party which gets data from a system like a BMS and to automatically understand which equipment it comes from, what kind of interactions it has with other systems, where is it located in a building etc. It is usually solved with a lot of manual engineering and guess.
This is precisely why Dynamic Data are merged to Static Data into a BOS. It brings a context to the values, and from a simple value, it becomes an intelligible piece of information to be shared with third parties (analytics, tenant app, CMMS...). A BOS makes the life easier for services so they don't concentrate on how getting the data but on their core added value. It's seamless to the revolution brought by any OS that handles hardware. App developers can easily use a GPS information without the need to decode raw data from the sensor.
Knowledge graphs
This Boiler brings hot water to this AHU, which brings itself recycled air to terminal units, that delivers themselves a couple of different spaces. What happens when the boiler is malfunctioning, which rooms are impacted? Is there any impact on the air quality? Is the number of people in the zone critical? While integrating both static & dynamic data, a BOS platform creates a knowledge graph that provides a more easy way to represent complex systems such as buildings. A building is made of floors, spaces and equipment that produces a lot of data. There are different angles to represent interactions and relationships between assets. A global knowledge graph of a building allows any third party to understand all the subsystems and assets involved from a practical way. Of course visualizing the graph on the BOS platform UI is not the most beneficial feature but sharing this graph easily with third party (API, Connectors...) is the most valued one.
The power of hiding OT complexity
Hardware agnostic
A building is complex by the quantity of systems it uses to provide confort to its occupants, to ensure safety, to measure its impact on the environment, to be maintained... This is achieved using many different technologies and hardwares from various manufacturers. A BOS creates a convergence of the many systems, no matter the hardware being used (controller A, B...), the communication technology (API, BACnet, Modbus, proprietary...) or the targeted silo (HVAC, Energy, Access control, IoT, Lockers...).
A BOS is hardware and solution agnostic, meaning that:
- The BOs is not tight to a specific hardware (and therefore a specific manufacturer)
- The BOS is independent from any hardware it integrates
- The installation of a new hardware has no impact on the way a third party interacts with a BOS
We can definitely use the analogy of a computer or mobile OS that can be installed on different hardwares with a capacity of communicating with external devices (printers, keyboard, GPS sensor, docks...) from almost any manufacturers, the third parties being the applications installed. Each application doesn't need to create their own specific driver, the OS plays the intermediary role to simplify data accessibility to apps. In a similar way, a BOS has this capacity to collect data from any devices, translated it to a unique language, enrich it with a context and share it to third parties.
As a natural evolution, a BOS extends the original purpose of a BMS/BAS (integrating usually HVAC, lighting and energy systems) to a broader perimeter (there are new other concepts and challenges to consider as well...).
The abstraction layer
Think about a service that needs to collect data from a building to provide energy insights, or from an analytics platform that needs to monitor all the equipment valves position. The developers/integrators in charge of collecting data don't really mind whether values are obtained through a series of gateways, the use of two communication protocols or by room controllers from brand A and B. What they seek about is the associated consumption values (with some context) or the valve position values. Their interest should be focused only on the data itself, not on its acquisition method (which needs to be as easy as possible). This is precisely one of the main role of a BOS: hide the acquisition complexity to highlight exchanged data.
A BOS creates an abstraction layer between heterogenous systems (data producers) and services (primarily data consumers). This layer hides complexity and simplifies data access to third parties. It works both ways, it's easier to collect data from the building, but it is also easier to apply control-command.
To hide the complexity, there are several levels:
- Level 1: a BOS provides a representation of data unrelated from the acquisition hardware but divided into individual equipment. To illustrate it, a single controller may acquire data points that are related to several equipment (different lights, a VAV, two multi-sensors...). The BOS will model each equipment and present the data to third parties accordingly. In some cases an individual equipment may contain data points acquired by several hardwares (and even from several communication protocols), having a single equipment representation simplifies a lot the understanding of the system.
- Level 2: a BOS provides a representation of a higher abstraction through syntheses and global commands, most of the time from a spatial perspective. To illustrate it: each office of a building may have 2, 3, 4... different lights to control. One way for a workplace app to control lights is to send a command to each light (through the BOS API or through a BOS connector). Although it would work, it requires the third party to learn the number of lights per room, to register for changes... Alternatively, the BOS can provide a global command per space, so the app only applies a command relative to the space, leaving the BOS the mission to apply commands to the x lights.
- Level 3: a BOS provides a knowledge graph to deeper understand the relationships between equipment and assets as seen before.
By giving a "practical representation" of heterogenous data with syntheses by space, by floor..., a BOS helps a third party to provide its service more efficiently and in some cases, makes it plug & play. This is a big change in the industry and brings many new perspectives!
To summarize:
- A BOS integrates data from any hardware (must be at least communicating)
- A BOS provides a representation made of individual equipment to third parties unrelated from the acquisition hardware
- A BOS provides aggregated data (syntheses) and global commands at a higher level, per space or floor for example
- A BOS provides different angles to describe mutual relationships between equipment
Avoiding a Spaghettiware
We talked a lot about the data All together they form a very heterogenous system from a third party perspective.