Main objectives

A building can be considered as a complex living structure which needs to provide comfort and safety to its occupants. In order to achieve its purpose, a building includes many different technical systems working more or less together. In the past, such systems would be self sufficient and would have no interactions apart from local interfaces. With the digital transformation, with incoming new challenges like carbon footprint reduction or high standard air quality requirements, systems cannot be autonomous anymore.

People are seeking for data, they want to make sure those challenges are efficiently met. Third parties want to provide their service to improve systems control, user experience, feedback... Having multiple, heterogenous systems in a building doesn't make the task easy. This is primarily due to a missing part in many buildings: a digital core that can:

• Communicate with regular OT systems (HVAC, Lighting, Metering...) and IT systems (Network, IoT, Access Control...)
• Transform technical data into intelligible pieces of information
• Create information exchanges between Systems and Services

Considering different types of 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 from services that produce their own data. Dynamic data can take many forms:

• A primary value also called "Datapoint" to represent a numerical variable, a boolean.
• An event such as a traditional BMS alarm, a CMMS work order 
• A series of values (also called timeseries) such as a weather temperature forecast, a logged pressure...
• A schedule with a list of bookings or recurring events
• ....

A dynamic data is usually acquired from a traditional BMS/BAS protocol (BAcnet, Modbus...) or from APIs.

Merging Static & Dynamic Data

Creating a context

A Dynamic value has a very limited use on its own (it is just a value varying over time). Most of the traditional BMS/BAS systems apply 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.

Sharing a context

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.

Hiding OT complexity

Hardware agnostic

What made the use of OS very popular was initially the availability to plug-in any devices and to be recognized by the machine (with the use of drivers). A building is even more complex by the quantity of different systems it uses to provide comfort 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 these many systems, integrating all of them into a single platform 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...).

An 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

On the IT side more and more services are deployed now for occupants, facility managers, property managers, owners... Although being sometimes self-sufficient, services usually require interactions with building systems (OT) or from other services to improve their added value. For example a meeting rooms booking application may require comfort data to suggest the most appropriate room or to liberate bookings based on the actual presence. In parallel, a portfolio monitoring app could require both the presence and the bookings made in the other app. The BOS has  a big role to play.

Without a BOS

As new services are deployed, they are looking at interacting with other apps or with the OT systems, and this is either poorly and hardly done or it costs a lot of money. This money is spent on the "connectors" to create the connection but not on the core value of each service. This is called a Spaghettiware as everyone tries to create its own connectors. For example, a portfolio monitoring app would create a "connector" to collect data from a workplace app and a workplace app would create a connector itself to get the list of available rooms from the portfolio app... All the these connectors development result with:

• An increased budget (multiplication of connectors)
• An increased inter-dependency between apps (making it harder to change one as it would impact the others)
• An increased complexity

Unfortunately, this happens every time a middleware is lacking. It may work on the deployment of a couple of services, but becomes a spaghettiware as the number of services increase.

With a BOS

While a BOS acts as a middleware, each application exchanges data with this intermediate layer that easily translates and enriches data from one app to another. Back to our analogies, a text editor uses the OS to store the work on a file locally so he can be sent using an email editor. The text editor developers didn't try to create a "connector" with every email editor on the market. The interaction with the OS is the key to allow end users to choose (and change) their text editor independently from their email editor or any other app.

Applied to our business: let's take a popular example where a BOS collects work orders (tickets) from a CMMS app. The BOS retrieve the tickets from the app and enrich them (associate it with a corresponding equipment if it's not done at the CMMS level), and once in the BOS, it can be shared to any third parties such as an analytics platform. The CMMS platform doesn't need to create a specific connector to the analytics app, the BOS already has these two connectors since it already communicates with each app for other purposes (generate ticket for example, and feed the analytics app with other types of data). Both apps can be changed, only the connector to the BOS will need to change.

Apply this logic to 3 services and the amount of work is even more reduced.

Exchanging data with the World

What also made Operating Systems so popular at a time was their capacity to install any software found out there, install them quickly and start using them. The OS was providing a single User Interface to launch dozens of applications at the same place.

Time has changed, with the heavy use of the Internet, most of applications are hosted in the Cloud using their own infrastructure to run efficiently and provide their continuous service. A BOS is then not the place where we should install a software application, launch it and access it through the BOS User Interface. Occupants want to book a room though their smartphone, property managers want to check energy consumptions from their own office (Why should they be in their customer's basement where the BOS server is located to check some data). Even Facility managers want to operate buildings remotely as much as possible.

Therefore the core mission of a BOS is not to host applications but to exchange data with them. This is again redefining our approach with BMS and middleware as they stood so far for most of them as a single place to attract all the users. A BOS may have no User Interface, it wouldn't be a big deal (a UI is still very useful to configure, monitor, debug... wait to see what Linksper can offer on this subject).

To exchange data, a BOS needs to provide an extensive range of possibilities to interact with third parties. At least:

• A BOS should be able to interact with all field hardwares (OT) using open protocols (and with the possibility for using proprietary protocols when necessary)
• A BOS should be able to interact with any solution/silos opening their data with an API (Similar to open protocols, any specific development should be avoided to reduce costs integrations)
• A BOS should provide an open, dynamic and fully documented API for third parties
• A BOS should provide other means of data exchange (MQTT, Real-time databases using SDK...)