Babel Buster Network Gateways: Big Features. Small Price.
|What’s a Building Operating System?
The role of the BOS is to hide the complexity of the field with various equipment manufacturers and protocols and to provide meaningful data on the IT side, so you can deploy independent services from each other without even knowing the architecture of the buildings.
Originally published on LinkedIn
The way we interact with a building
is evolving quickly with the impulse of the digital transformation of
our society. This digitalization has serious impacts on how we design
BMS/BAS solutions and what value we bring to the different actors.
Why we can’t continue the same way?
On one side, we have end users seeking for more
interactions with their surrounding environment: an app to control
their comfort, meeting rooms smart booking, issues reporting, chatbot,
indoor geolocation… And on the other side, buildings tend to have more
and more connected systems producing even more data but mostly failing
to satisfy these new needs.
The building digitalization is also disrupting
the way we manage facilities and is opening new ways of creating value.
Building data is underexploited because of the lack of coherence and
structure. That data can generate a lot more value if we improve the
way we deal with them: malfunction detection, energy optimization,
space optimization, maintenance log, predictive maintenance…
You may think it’s just a hype that will be away
soon, but buildings that don’t follow this evolution will have a
decreased value in the future regarding other buildings that provide
plug & play installation of new services, some we don’t even know
yet. Mastering buildings data to provide more value is becoming so
important; it’s now one of the key requirements for investors.
What’s a Building Operating System?
A Building Operating System is the middleware between equipment on the field and services. Its main goal is to rationalize and mutualize data between field equipment/sensors and applications. Data are acquired by the BOS, structured and dispatched in the right format to any application that would need them.
The Building Operating System is the evolution
of a traditional BMS/BAS to an information system. It differs in the
plurality of data it handles: IoT, access control, fire detection…, the
contextualization & structuration of data it provides and the
connectivity to IT solutions. A BMS is currently deployed with the only
purpose to provide a technical interface to Facility Managers. Even if
it’s an open system, deploying a new IT service on the top is difficult
and expensive because the BMS hasn’t been designed to allow third
parties to access easily meaningful data.
With a micro-service approach, the concept of a
BOS is to allow any digital service provider to connect to the building
and learn what’s inside automatically because every data it interacts
with can describe itself and its interactions. So, it’s becoming
possible to deploy a new service without changing the current
infrastructure of a building or even changing anything with the local
data. The role of the BOS is to hide the complexity of the field with
various equipment manufacturers and protocols and to provide meaningful
data on the IT side, so you can deploy independent services from each
other without even knowing the architecture of the buildings.
Why services can’t connect directly to the devices?
The Building Operating System plays the role of an ESB (Enterprise Service Bus) we can find in other IT domains. It handles the integration of data from heterogeneous sources into a single unified interface to provide useful data to services that need them. This integration is done in three phases:
The BOS can
acquire local data (communicating equipment, gateways, IoT…) or cloud
data (weather, IoT…). The BOS purpose is to make the acquisition at the
equipment level as much as it’s possible, avoiding any gateway in order
to increase the reliability of the architecture. The BOS should be the
only interface between the equipment and the services. This is intended
to avoid every service creating a connector to every equipment
manufacturer, also called the “Spaghettiware.” It’s a bad architecture
for two main reasons:
At the opposite, changes are done at the BOS
level, and then it provides automatically the changes to every service
accessing the data. This process is automatic.
How does it make a difference with a traditional middleware?
BOS isn’t just a simple gateway between
OT and IT. The BOS is a platform handling data and provides several
tools to administrate the data with three main steps:
The concept of data doesn’t only apply to
real-time values but covers more complex formats (commands,
time-series, events, schedules, alarms…) that are also handled by the
Step 1: Integrating data
The acquisition must be made with
heterogeneous sources, as we have seen before. Using a truly open
system like Niagara is important to ensure communication with many
different systems. This step is also important to ensure the
homogeneity of data (units’ conversion, time synchronization…) and
optimal data quality (handling incoherence values, loss of values…).
Step 2: Modeling
and structuring data
To allow service applications to access the
data they need, it’s necessary to simplify the access to the data by
creating an abstraction of systems complexity.
To do that, each field data is associated
with various data models: the location (where), the associated
subsystem(s) (how), nature (what)… The interactions between the various
elements (equipment, sensors, actuators…) are described using mutual
relations to elaborate hierarchies between these elements. A BIM model
can be used as a data model resource to simplify and partially automate
the data structuration.
In order to do this, the BOS uses a graph
database which facilitates the description of complex systems and
information search process. Data are accessible through individual
nodes that each of them represents a part of the system.
For example a node
can be a tenant,
equipment, a floor…
Each node can have relations with other
nodes to define interactions. Together they form a semantic (a
dictionary of words) and even more a taxonomy (a classification of
are created between
“Cooling Water Plant A” and “Fan Coil unit 1” to represent that this
fan coil is fed by this cooling water plant. Other relations can be
used to describe which tenant(s) is related to that zone(s).
Having this information, it becomes easy
for a third-party system to ask the BOS: “which zone is fed by this
cooling water plant?”.
Step 3: Allowing access to data and handling IT interactions
Data must be shared with third-party
systems using IT technologies and according to different formats:
through Web service, Rest API, connectors… A single technology isn’t
enough because of the plurality of services and restrictions on IT
Example: time-series data can be transferred to a local database for search purposes like Elasticsearch, while real-time data can be synchronized to a cloud platform like Azure or Google Cloud and alarms pushed to a CMMS API…
Since the BOS
is the information system, it
must handle the permissions given to every application to control what
data they can access. Using the graph database, it simplifies a lot
administrator of the BOS can
authorize the analytics platform to access metering and environmental
data but forbids access to other information (names of the tenants,
maintenance log…). Another example, the BOS can give permissions to a
room booking application the rights to access occupation of each room
but forbids access to any other data.
What example of services could you give to an investor?
many services that can be
deployed to a building to improve comfort, security, maintenance and
occupants' experience. The most common one we see is the energy
management system collecting metering data. It’s usually a manual
process to set it up. Using a BOS can simplify the installation of such
systems. The most important advantage is the freedom to change the
service at any time without losing much because all the data
structuration was past done inside the service and is done now inside
the BOS only once.
Interest around Digital Twins is increasing
since they provide a real-time representation of a building using a BIM
model for static data and live data from a BOS. It’s disrupting the way
of handling maintenance in a building by providing very precise and up
to date information to the Facility Manager. The implementation of a
Digital Twin is simplified a lot and almost entirely automated if the
BOS uses the BIM model as an input.
At VayanData, we work in collaboration with
Twin Ops from
Vinci Facilities to industrialize the use of Digital
Twins. We have created unprecedented interactions, feeding the digital
twin with highly structured data, sharing BIM information and even
reconfiguring local equipment (like a master-slave logic between FCUs)
from a BIM model change (like an open space broken into two offices).
The result is improved productivity and reliability for people on site
avoiding a lot of coordination since it’s handled automatically by
machines. See this video for more information.
Meeting rooms are a nightmare for a lot of occupants. Always booked, but mostly empty, people are always looking for meeting rooms. What if the BOS can feed the meeting room booking system with the information of occupation and liberate the room when there is nobody inside after an amount of time? It’s something you can do easily using a BOS.
Washroom occupation can be monitored, and data synchronized to the Facility Manager's internal application so they can improve the cleaning frequency according to the occupation rate — better comfort for occupants, lower costs for tenants.
Chatbots, mobile applications for parking, analytics… are the future of a Smart Building.
At VayanData, we help companies such as Master System Integrator to bring technical solutions using a powerful stack (Niagara & Active-Framework). We can help your company. Contact us at firstname.lastname@example.org
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]