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 complexity
Hardware agnostic
A building is complex by the quantity of systems it uses to provide confort to its occupants, to bring safety, to measure its impact on the environment, to be maintained... This is achieved using many different systems and hardwares from different brands, using different technologies. All together they form a very heterogenous system.
This is precisely the core mission of a BOS: it has the objective of creating a convergence of the many systems of a building, no matter the hardware being used (controller A, B...), the communication technology (API, BACnet, Modbus, proprietary...), the silos (HVAC, Energy, Access control, IoT, Lockers...). It is hardware and solution agnostics extending the original purpose of a BMS/BAS (usually found around HVAC, Lighting and energy) as its natural evolution to a broader perimeter and to embrace the digital revolution.
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 need to monitor all the equipment valves opening. They 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 bout is the consumption values (with some context) or the valve position. This piece of data is the only thing they want to get, as easy as possible. That's precisely one of the main role of a BOS: hide the acquisition complexity to highlight the shared data.
A BOS creates an abstraction layer between heterogenous systems (data producers) and services (primarily data consumers). This layer hides the complexity and simplifies data access to third party. It works both ways, it's easier to collect data from the building, but it is also easier to apply commands.
- A BOS will be able to share raw data (but enriched with a context) from the various equipment to a third party.
- A BOS will also creates syntheses and global commands for services that want an even more simplified representation of a building.