Building Operating Systems: A Cloud-based Architecture for Enabling

Knowledge Representation and Improving the Adaptability in Smart

Buildings

Adrian Taboada-Orozco

, Kokou Yetongnon

and Christophe Nicolle

Laboratory CIAD, Univ. Bourgogne Franche-Comt

e, CIAD EA 7533, 21000 Dijon, France

Keywords:

Internet of Things, Knowledge Representation, Smart Building, Building Automation Systems, Building

Operating Systems, Smart Cities, Adaptability.

Abstract:

Hardware and software’s constant evolution opens new horizons for developing systems focused on buildings.

Thanks to this evolution, the smartization of them is possible. The target of building automation systems is

always to reduce human intervention, thus avoiding errors and maximizing the building resources. However,

these systems still require an operator that knows the building’s topology, the elements inside, the dwellers’

preferences, and how to operate the automation system. The operator uses this knowledge to adapt the au-

tomation system by conﬁguring parameters and thresholds to deal with the most common issues in buildings.

This paper introduces a new approach named WITTYM-BOS (W-BOS) that consists of a unique Building

Operating System (BOS) architecture, doted with a knowledge representation comparable with the operators’

knowledge. In this way, we transfer the abilities of an operator to improve the adaptability of a building au-

tomation system like BOS. To construct the knowledge, we combine static and dynamic information such as

Industrial Foundation Classes (IFC) and data coming from the Internet of Things (IoT). We construct a pre-

liminary prototype to illustrate our concept and validate use cases. Our work opens new horizons to innovative

applications that proﬁt from the easy understandability of our approach.

1 INTRODUCTION

Automation systems have been evolving with the ex-

ponential improvement of hardware and software.

Furthermore, automation has reached a unique inﬂec-

tion point towards the smartization of objects. Since

the conception of the ﬁrst Building Automation Sys-

tem (BAS) in 1850 (Martirano and Mitolo, 2020),

they have been reducing human intervention progres-

sively. This fact has been assumed as smartization

of buildings (Buckman et al., 2014). However, this

term is not precise and also evolves. A clear ex-

ample is Domotic, early considered a smart build-

ing system (Buckman et al., 2014). Domotic displays

data and allows local control. Although Domotic au-

tomates building elements like lights or doors, it is

still dependent on an operator. In this case, the do-

motic itself does not make the building smart (Sle-

man and Moeller, 2011). Instead, the operator uses its

https://orcid.org/0000-0002-2396-3286

https://orcid.org/0000-0002-6949-1050

https://orcid.org/0000-0002-8118-5005

knowledge of building topology and elements inside

to solve dwellers’ issues. Beyond the operator’s inner

knowledge, it possesses a capacity to adapt the system

to new scenarios.

The rigid architecture of BAS has pointed out spe-

ciﬁc management of building tasks such as monitor-

ing thermal comfort or energy consumption. It is this

speciﬁcity that has impeded its adaptation to new sce-

narios. BAS systems like Heating Ventilation and

Air Conditioner (HVAC) controllers, Programmable

Logic Controllers (PLC), Supervisory Control and

Data Acquisition (SCADA), and Building Manage-

ment Systems (BMS) are examples of rigid build-

ing automation systems that require highly trained ex-

perts to manipulate the data and operate the system.

The main issue of BAS remains on how to break

with their rigidity and how to provide adaptability to

them. We believe that by transferring the operator’s

knowledge and simplifying its access and the con-

trol of the entire system (hardware and software), we

make a building fully adaptable to new issues. Con-

sequently, the smartization of the building is possi-

ble. While the term smart is still debatable, some

162

Taboada-Orozco, A., Yetongnon, K. and Nicolle, C.

Building Operating Systems: A Cloud-based Architecture for Enabling Knowledge Representation and Improving the Adaptability in Smart Buildings.

DOI: 10.5220/0010650400003064

In Proceedings of the 13th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2021) - Volume 2: KEOD, pages 162-169

ISBN: 978-989-758-533-3; ISSN: 2184-3228

researchers support our belief in equating smartness,

and adaptability (Beetz et al., 2009). The term adapt-

ability has a crucial connotation in the automation

ﬁeld. This term is used to describe the ergonomic of

the system towards end-users (ISO9241-210, 2019)

and it is the ﬁnal barrier of BAS systems.

Nowadays, the term Building Operating System

(BOS) emerges to deﬁne a system able to solve and

simplify the complex underlying hardware and soft-

ware of BAS. BOS is deﬁned as an intermediate sys-

tem between ﬁeld equipment and services (Sleman

and Moeller, 2011). This deﬁnition has not yet been

clariﬁed. BOS is cutting-edge technology, which does

not have a clear deﬁnition nor a deﬁned architecture.

However, BOS does have a clear objective, which

consists of providing adaptability to buildings sys-

tems (Vermorel, 2020).

In this paper, we address the central issue

of BAS by proposing a knowledge representation

named Building Brain Knowledge Representation

rainKR) incorporated as a module in a unique

BOS architecture. We called the entire system

WITTYM-BOS (W-BOS). W-BOS is an enriching

environment composed of modules to manage the ﬂux

of information and access to end-users. The function

of B

rainKR is to improve even more the adaptabil-

ity that BOS already provides. In this way, the system

can be adaptable without requiring a deep understand-

ing of the building features. Besides, we propose an

innovative cloud-based BOS architecture that harmo-

nizes data ﬂux and creates the most favorable condi-

tions for users to develop applications.

rainKR module represents the operator’s

knowledge and is made with ontologies that re-use

static and dynamic information of the building. The

static part is represented by ontologies based on

the standard Industrial Foundation Classes (IFC)

ﬁles (ISO 16739:2018). IFC ﬁles contain geometric

information of the buildings as well as their elements.

The dynamic part is the information coming from the

Internet Of Things (IoT). This information populates

the ontological representation. Precisely, we re-use

existing ontologies such as SAREF4Bldg

and

Building Topology Ontology (BOT)

ontologies to

construct B

rainKR.

To illustrate how W-BOS can deal with an emer-

gent issue, we evaluate a use case in our cloud-based

prototype. In this experiment, we display ﬁve single

steps to create a ”hello-world” application that solves

the use case issue.

The rest of the paper is as follows. Related work

is described in section 2. Our approach is explained

https://saref.etsi.org/saref4bldg/v1.1.2/

https://w3c-lbd-cg.github.io/bot/

in section 3. The procedure to create applications and

interfaces is illustrated in section 4. Finally, section 5

discusses and concludes the paper.

2 RELATED WORK

Research in BOS systems focuses on opening systems

to end-users not only as consumers but also as devel-

opers. BOS proposal approaches have ﬁrstly deﬁned

BOS as middleware hardware and software placed in

the fog computing layer. However, nowadays, new

cloud services and the boom of IoT have extended and

re-located BOS.

The author (Fierro and Culler, 2015) introduces

XBOS as an open-source system, aiming to monitor

real-time conditions in buildings and control actua-

tors. Similarly, (Dawson-Haggerty et al., 2013) intro-

duces BOSS, an approach that monitors and controls

ﬁeld devices. These works describe complete archi-

tectures to simplify the information ﬂux from IoT to

the application layer. However, they neglect the open-

ness aspect, not allowing clear access to data. Be-

sides, these systems are presented as fully middleware

APIs.

A step forward is presented in the work of the

authors (Kciuk, 2014), (Rosen et al., 2004) and

(Wenjiang et al., 2009), they introduce OpenWRT,

HomeOS, and VxWorks systems respectively. Open-

WRT is a GNU Linux environment aimed to extend

the services of a communication router. In this way,

extending the communication purpose of the router

into an administrator of tasks. HomeOS is a system

part of Microsoft research aimed to optimize tasks in

house applications. In other words, it seeks to autom-

atize domotic tasks. HomeOS points out to reduce

human intervention in automation systems, and it also

includes a space for applications. VxWorks’ approach

aims to exploit real-time data coming from sensors.

The architecture of VxWorks allows users to create

subroutines dedicated to speciﬁc tasks. From a global

perspective, these systems enable end-user to inter-

vene and create dedicated services. However, these

architectures do not conceive important aspects like

integration of data, security, and scalability. In the

case of HomeOS, the exciting aspect is the concep-

tion of a set of re-conﬁgurable applications. HomeOS

marks a milestone towards BOS and open services for

buildings.

Nowadays, cloud services are mature enough and

stable to host complex applications that require high

processing skills. It is the case of BIM; some pro-

posals described in (Dave et al., 2018) and (D

ollner

and Hagedorn, 2007) proposes to extend the web

Building Operating Systems: A Cloud-based Architecture for Enabling Knowledge Representation and Improving the Adaptability in Smart

Buildings

163

BIM platforms to display and handle IoT data. These

works aim to open this information to a collaborative

environment.

BIM is closely associated with BOS. They share

the same common interest, which is buildings. BIM

platforms are excellent ways to display data in 3D or

2D virtual models. The authors (Dibley et al., 2012)

and (Curry et al., 2013) propose to use BIM as an ex-

tended BAS. In their work, they present a semantic

model to integrate IoT data into BIM. The idea is to

exploit the geometrical description of BIM with cur-

rent information coming from the physical building.

Despite this enriching integration, there is still an is-

sue concerning complexity. BIM complexity is chal-

lenging itself. These platforms already integrate data

of different users in a collaborative environment, in-

cluding administrative information and different for-

mat ﬁles (images, diagrams, or pictures.). Adding

more complexity to BIM can disrupt its scalability.

Recent commercial proposals have described archi-

tectures considering BIM as part of BOS to display

data (Anonymous, 2019).

Buildings are intricate and large structures com-

posed of many spaces, elements, and devices. Over

time, ontologies have been widely used to repre-

sent buildings’ knowledge and leveraged to solve

dwellers’ most common issues such as thermal com-

fort, energy consumption, and personal security in

many kinds of research. The author (Compton

et al., 2012) proposes Semantic Sensor Networks

(SSN/SOSA) represent devices in buildings like IoT.

In their work, these authors point out to use SSN

and reasoners to manage building. Nevertheless, the

scope of this ontology is limited to observation and

actuation, it lacks Spatio-temporal concepts. These

are limited, and there is no clear deﬁnition of the

most common building elements and their properties

like unities or types. The authors (Rasmussen et al.,

2018) have combined SSN and BOT to complete the

geospatial gap of SSN. However, these approaches

lack of expressiveness of BOT about building mate-

rials, dimensions, and the topology itself. Besides,

the authors have increased non-standardized termi-

nology to describe the missing part to deal with this

gap. The authors (Balaji et al., 2016) propose us-

ing Brick Schema Ontology (BRICK) to represent

building knowledge. Brick possesses a rich vocabu-

lary of building elements. This ontology is oriented

towards design and construction (Esnaola-Gonzalez

et al., 2016). Although Brick overcomes and achieves

a good description, but it does not describe relations

between physical spaces. The author (Schneider,

2017) proposes to complete this gap by evaluating

Brick’s alignment to BOT, demonstrating consistency

between them. IFC-based approaches emerge as a

plausibly way to standardize building vocabulary in

ontologies involving building features. For instance,

the author (Esnaola-Gonzalez et al., 2016) argues that

IFC is being widely implemented in Building Infor-

mation Modeling (BIM) ﬁeld and has been accepted

by most building designers, so building development

should be close tied with IFC. The IfcOWL ontol-

ogy proposed by the author (Pauwels et al., 2017)

takes EXPRESS schemes from IFC to model the rep-

resentation of the building. The transformation from

IFC ﬁles into ifcOwl has been suggested by (Beetz

et al., 2009) in its work, the author proposes a semiau-

tomatic transformation. Although ifcOWL contains

high alignment with the IFC standard, the ontology

is complex and includes many classes that might not

be useful to represent the context of devices. The au-

thor (de Farias et al., 2015), proposes IfcWoD as an

adaptation between IFC and OWL that allows full ex-

ploitation of OWL. IfcWod aims to reduce data re-

dundancy by avoiding some classes of IfcOwl. This

approach is interesting to reduce the complexity of

IfcOwl. However, our objective is to construct an

object-oriented knowledge representation. In this way

reduce even more complexity of IFC to OWL trans-

formation. The author (Daniele et al., 2015) proposes

the SAREF4Bldg ontology as an IFC-based approach

to describe building physical elements. This ontology

extends SAREF ontology by adding 72 classes that

include building objects. It is a summarized version

of ifcOWL that only takes building elements. IFC

ﬁles contain implicit information of building topol-

ogy like adjacency of spaces. This fact is interest-

ing to exploit but not necessarily practical. The study

of the author (Schneider, 2017) reveals an alignment

of SAREF4Bldg with BOT showing high compati-

bility and simplicity compared with IfcOWL. We re-

mark that our work aims to proﬁt from the most recent

technology to construct a simple and effective archi-

tecture located entirely at the cloud computing level.

Moreover, we do not consider BOS as only a middle-

ware layer. Instead, we believe that the functions of

BOS must go further and improve the understandabil-

ity of the building. We strongly believe that transfer-

ring knowledge to a BOS system is crucial to achieve

full adaptability. Otherwise, W-BOS would fall into a

miscellaneous misconception of smart systems simi-

larly to domotic.

3 W-BOS FRAMEWORK

W-BOS is an architecture composed of ﬁve intercon-

nected modules in opposition to monolithic systems

KEOD 2021 - 13th International Conference on Knowledge Engineering and Ontology Development

164

developed in this domain. The main objective of a

modular BOS is to guarantee interoperability between

systems and the extensibility of services. In this way,

it is possible to replace one module without affecting

the others. Beyond, we aim to create the most fa-

vorable conditions to create applications by enabling

access to data and knowledge through a set of APIs

functions. Additionally, our system counts with ex-

tra tools to become even easier to use this knowledge

(e.g., reasoners). W-BOS proﬁts from recent mature

technology such as cloud services and IoT. Thanks to

this groundbreaking technology, we propose a cloud-

based solution for buildings. As illustrated in ﬁgure

1, W-BOS is composed of ﬁve autonomous modules

divided into two groups management and knowledge

modules.

Figure 1: Modular W-BOS architecture, IoT Block and

BIM server.

3.1 Knowledge Modules

These modules are tools and knowledge-based infor-

mation. The main target is to transfer the operator’s

knowledge to the W-BOS system, which is challeng-

ing, considering that the operator had to build this

knowledge by hard training.

To describe buildings’ features based on a com-

mon vocabulary of elements, equipment, and type of

spaces can be tedious and need high expertise. Even

in this way, the description can be imprecise. To avoid

misinterpretation and allow interoperability between

systems, a standard reference is needed. The stan-

dard IFC emerges as a plausible solution to deﬁne and

name with high accuracy building elements. Our aim

with these modules is to move towards open systems

following a standard guideline.

The representation of the static elements of a

building gives good spatial information. However,

this is not enough to construct knowledge. Buildings

are dunk in data that need to be taken into account.

Related work trusts on complex multi-protocol de-

vices to obtain this information from various ﬁeld de-

vices. Nowadays, the use of IoT has simpliﬁed this.

Many IoT are used as a direct source of data and as

gateways to homogenize communication. IoT are a

direct source of dynamic data that completes the rep-

resentation of knowledge.

The following subsections explain how the static

and dynamic information is combined in a knowl-

edge representation named Building Brain Knowl-

edge Representation (B

rainKR).

3.1.1 B

rainKR Static Components

The static component of B

rainKR is IFC informa-

tion that contains all physical elements of a build-

ing and their relations between them. The IFC

standard has the two most used versions IFC2x3

and IFC4. The evolution of objects has allowed

buildings to get more complexity, as reﬂected in

these two versions. IFC2x3 describes elements

as a type of one single object. For example, in

IFC2x3, a boiler is described as a type of en-

ergy conversion device(ifcEnergyConversionDevice).

On the other hand, IFC4 contains more precise

description of objects such as boilers(ifcBoiler),

heaters(ifcSpaceHeater), solar panels(ifcSolarPanel)

among others. This fact increases the complexity of

interoperability between other systems. For instance,

the standard IFC2x3 and IFC4 are widely used by

Building Modeling Applications(BIM), and the tran-

sition between IFC2X3 towards IFC4 is still in pro-

cess. To construct knowledge over these two versions

of IFC, we use SAREF4Blds ontology. SAREF4Blds

ontology contains classes of building objects based on

the IFC4 version. Besides, we propose the alignment

of IFC2x3 with SAREF4Blds, as shown in ﬁgure 2.

Beyond the description in SAREF4Blds of build-

ing elements like doors, walls, or electronic equip-

ment, there is still a lack of relation between

spaces, as stated in previous work. Additionally to

SAREF4Blds, we use the alignment with BOT ontol-

ogy proposed by the author (Schneider, 2017). The

idea is to use relations like ”bot:adjacentZone” and

”bot:intersectsZone” to complete the description of

the building. The combination and alignment are

illustrated in ﬁgure 2. A signiﬁcant advantage of

SAREF4Bldg over ifcOWL and ifcWod is its object-

oriented aim, which is particularly useful and compat-

ible with W-BOS’s goal to decrease the complexity of

the entire system, even the knowledge representation.

On the other hand, it is also possible to extract some

classes or re-use ifcOWL and ifcWod partly. How-

ever, the question is how to discriminate the classes

and properties. A work that has already been done

in SAREF4Bldg ontology. Besides, SAREF4Bldg’s

versatility allows the interoperability between the two

IFC versions(IFC2x3 and IFC4).

Building Operating Systems: A Cloud-based Architecture for Enabling Knowledge Representation and Improving the Adaptability in Smart

Buildings

165

Figure 2: The windows IFC4, IFC2x3, and SAREF4Bldg represent the alignments between IFC and SAREF4Bldg concepts.

The two-sense arrows indicate the equivalence, and the color code represents main concepts such as Building (red), Spaces

(blue), and Objects(green). In IFC2x3 as no direct or explicit equivalence, the yellow block contains the general ancestor of

IFC2x3 objects. The windows SAREF4Bldg and BOT display the alignment between them and the properties (dotted blocks).

In our prototype, we use an IFC2x3 ﬁle that be-

longs to the description of our laboratory building.

Figure 3 shows the real physical building, and its 3D

digital model using WITTYM-BIM

application. The

WITTYM-BIM is a collaborative web-based applica-

tion that supports the actors of the building construc-

tion domain by reproducing a digital twin of the phys-

ical building.

Figure 3: Physical building of our laboratory CIAD and its

the 3D representation using WITTYM-BIM application.

3.1.2 B

rainKR Dynamic Components

The dynamic part of B

rainKR is heterogeneous data

coming from IoT. The ontologies are suitable to inte-

grate these data. An example of the manner an inte-

gration is made in B

rainKR is depicted in ﬁgure 4.

Figure 4 shows how a measurement is related to a

space, a sensor, and the features of the measurement

itself. To make this integration possible, we store

the data into a relational database (SQL), aiming to

store row data and enable non-knowledge-based ap-

plications. The data coming from IoT contain meta-

data attached to the measured value, independently

https://wittym.com/

Figure 4: Part of T-Box and A-BOX from sensors and their

measurements extracted form B

rainKR.

from the communication protocol (MQTT, HTTP, and

LoRWan

). This extra information (ID and TimeS-

tamp) is also used to create many instances of sensors

and measurements in the ontology. The ﬁgure 5 dis-

plays B

rainKR representation in protege.

Figure 5: B

rainKR in protege, left side the classes hierar-

chy of SAREF4Bldg. In the right part, the building space as

instances of the class Building Space.

https://lora-alliance.org/about-lorawan/

KEOD 2021 - 13th International Conference on Knowledge Engineering and Ontology Development

166

3.1.3 BOS Tools Module

The BOS tools module contains a set of tools to facil-

itate building applications resources to construct ap-

plications. One primary tool is the embedded rea-

soner. This semantic reasoner is available for infer-

ring new data, which is helpful in the cases where

the inference is required to explain the physical de-

scription of the relation between sensors and build-

ing elements. The reasoner translates knowledge and

makes it easily understandable for humans. For ex-

ample, a temperature sensor installed on a partition

of a wall must be reﬂected by the temperature of the

room (and not of the partition). It is the inference

mechanism that ﬁnds the space associated with the

partition. In this example, the inference would use

the relation ”saref4Bldg:contains” between the build-

ing space and ”saref4Bldg:sensor”. In our prototype,

we embedded a Pellet-based reasoner (Openllet

3.2 Management Modules

The management modules focused on opening access

to W-BOS to end-users. Therefore, easy access can

be translated into better adaptability of the system.

3.2.1 IoT Management

The IoT management modules represent a subsys-

tem that handles IoT connections, authentication, and

communication. In our prototype, we have imple-

mented a python-based client that holds a register

of IoT device topics and identiﬁcation codes. This

module receives and then transfers data to the storage

module. Additionally, it also re-transmit commands

coming from the cloud applications. In our prototype,

we have used experimental IoT devices connected to

an MQTT cloud broker that transfers all IoT data to

W-BOS.

3.2.2 API Server

The objective of the API server module is to

break with silos of data by unifying information in

rainKR and providing access to it. As if it were a

bus of communication between applications and data.

This module is critically essential for W-BOS. Its pri-

mary function is to guarantee access and provide a

consistent ﬂux of information. In our prototype, we

implemented a Swagger

API server that performs

SPARQL and SQL queries over B

rainKR by using

RFDlib

libraries. Besides, this module provides in-

https://github.com/Galigator/openllet

https://swagger.io/

https://rdﬂib.readthedocs.io/en/stable/

formation to the Wittym-BIM platform to display ap-

plications and IoT data. These APIs are also enabled

for external applications that might require more pro-

cessing skills. The API module has ﬁve functions de-

scribed below:

• Add rules into B

rainKR and extract inferred ax-

ioms

• Request the spatial measurement made by sensors

(by sensor ID)

• Request spatial adjacency of measures or actua-

tion (by BuildingSpace)

• Request positions of sensors ( by sensor ID)

• Request status of the building element (by data

properties)

3.2.3 Cloud Application Space

The cloud applications module is a speciﬁc space ded-

icated to the development of applications. In this way,

end-user can adapt the system to solve new issues in

new scenarios. This module proﬁts from a Linux-

based environment over which applications can be

made using shell or high-level languages like python.

3.3 Field Devices and BIM Server

The prime function of IoT devices is to capture infor-

mation from the physical environment. They com-

pose the ﬁeld layer. The hardware in our proto-

type is IoT devices composed of sensors and actua-

tors. These devices count with Wi-Fi connection over

which we implemented the MQTT protocol. MQTT

is a topic-based protocol consisting of two main com-

ponents: A broker aimed to administrate topics and

subscribers. On the other hand clients can publish

(transmit information) and subscribe (receive infor-

mation) over some determined topics. Our IoT plays

the role of clients and subscribers to transmit teleme-

try data and receive commands from W-BOS through

a broker.

4 W-BOS USE CASE EXAMPLE

This section presents how an application can be de-

veloped in W-BOS. We create the Internet of Things

Fire Detection Application (IOTFDAPP) as a ”hello-

world” example. The aim of showing this example

is to demonstrate that W-BOS efﬁciently exploits the

knowledge of the static elements and dynamic infor-

mation. IOTFDAPP’s objective is to determine the

presence of ﬁre in a room and the surrounding spaces.

Building Operating Systems: A Cloud-based Architecture for Enabling Knowledge Representation and Improving the Adaptability in Smart

Buildings

167

The result of IOTFDAPP is the names of room spaces

that surround a room with ﬁre. In our case, we use

the model of our laboratory building. This use case

can be helpful for ﬁreﬁghters to evacuate people in a

building. For this purpose, we employed 10 IoT phys-

ical devices installed in rooms of our laboratory. We

enable the API module to exchange information be-

tween the Wittym-BIM platform and W-BOS to dis-

play IoT data. The idea is to represent the result of

the IOTFDAPP application as a virtual sensor that

contains the names of these dependencies(Building

spaces like rooms). For this purpose, we follow the

following ﬁve steps required to create an application

in W-BOS:

• 1.Insert a rule, perform semantic reasoning and

query the ontology with the inferred axioms. In

this use case, the following rule describes our de-

sire: The rooms surrounding a space that reaches

a temperature higher than 50[Centigrades] must

be evacuated. Table 1 depicts this rule. The result

of the application is displayed in ﬁgure 6.

Table 1: Ontology rule in the API.

Ontology Rule

s4b:Sensor(?s)∧s4b:Measurements(?m)∧

s4b:makesMeasurement(?s,?m)∧

s4b:relatesToProperty(?m,AIRTEMPERATURE)∧

s4b:hasValue(?m,?v)∧bot: Space(space?)∧

s4b:conatins(?space,?s)∧

bot:adjacentZone(?space,?adjacent)∧

swrlb:greaterThan(?v, integer 50)

→ s4b:isluminated(?adjacent, true)

• 2.Request the result with the ”isIluminated” prop-

erty that has a Boolean value of ”true”.

• 3.Creates a virtual sensor label to transmit the re-

sult into W-BOS.

• 4.Create a virtual sensor in WITTYM-BIM

• 5.Request the API with the ID of the sensor. The

result of the application is displayed in ﬁgure 6.

5 DISCUSSION AND

CONCLUSIONS

This paper introduced W-BOS, a BOS architecture

doted with a knowledge representation that contains

static and dynamic information of the building. W-

BOS aims to solve the central issue of building au-

tomation by blending knowledge in a unique and open

architecture. We built a cloud-based prototype to

demonstrate W-BOS’s advanced adaptability. Specif-

ically, we have evaluated a ”hello-word” use case.

Figure 6: Result of IOTFDAPP displayed in WITTYM-

BIM. The plan in 3D belongs to the rooms of our laboratory

building ﬂoor.

We believe that our prototype covers essential

functions to reach a high level of adaptability. Never-

theless, a cloud solution already provides easy access

to information in geographical terms. Our proposed

architecture structures the data and their ﬂux. By us-

ing knowledge, we ﬁrmly believe that the system is

more understandable and thereby easy adaptable. It

is possible to conceive the underlying operating sys-

tem (Linux) of W-BOS as the BOS itself. However,

related work reveals that data arrangement and ﬂux

are more signiﬁcant than the programming language

or the underlying operating system.

Beyond this evidence shown in this paper, there is

growing concern about the security of data that must

be addressed. Targeting this issue, we presume that

using knowledge can limit access to private user data

by creating rules according to the user’s privacy and

security policy.

A relevant challenge is a paradigm of combining

IoT and BIM information. To create B

rainKR we

transformed IFC2x3 to SAREF4Blds manually. Al-

though this method is valid, the task of transform-

ing IFC information manually into ontologies is in-

efﬁcient. An automatic transformation can increase

the scalability of the system and simplify this process.

Despite this gap, we could describe most building de-

pendencies, sensing, and actuating devices without

creating new classes.

In the W-BOS prototype, we could quickly re-

quest the knowledge using the API module to develop

IOTFDAPP. Following the ﬁve steps, this task be-

comes easy. We think that more functions can make

this adaptation even easier. However, creating more

functions without a standardized guideline can reduce

the understandability of the system. Despite, this need

we could observe that the API facilitates access to

information by simplifying all complicated SPARQL

queries to the ontology model.

Our work paves the way for developing applica-

tions based on knowledge rather than only informa-

KEOD 2021 - 13th International Conference on Knowledge Engineering and Ontology Development

168

tion. We believe that by opening and facilitating the

control of building systems, we can count on more

appealing and efﬁcient solutions.

ACKNOWLEDGEMENTS

This project is funded by the KID’S AI Company. We

thank the members of this company involved in the

WITTYM project and especially the engineer’s team

for providing insights.

REFERENCES

Anonymous (2019). Etude de cas: le futur

campus d’emlyon business school - ur-

ban practices. https://urbanpractices.com/

etude-de-cas-le-futur-campus-demlyon/. (Accessed

on 05/05/2021).

Balaji, B., Bhattacharya, A., Fierro, G., Gao, J., Gluck,

J., Hong, D., Johansen, A., Koh, J., Ploennigs, J.,

Agarwal, Y., et al. (2016). Brick: Towards a uni-

ﬁed metadata schema for buildings. In Proceedings

of the 3rd ACM International Conference on Systems

for Energy-Efﬁcient Built Environments, pages 41–50.

Beetz, J., Van Leeuwen, J., and De Vries, B. (2009). Ifcowl:

A case of transforming express schemas into ontolo-

gies. Artiﬁcial Intelligence for Engineering Design,

Analysis and Manufacturing: AI EDAM, 23(1):89.

Buckman, A. H., Mayﬁeld, M., and Beck, S. B. (2014).

What is a smart building? Smart and Sustainable Built

Environment.

Compton, M., Barnaghi, P., Bermudez, L., Garcia-Castro,

R., Corcho, O., Cox, S., Graybeal, J., Hauswirth, M.,

Henson, C., Herzog, A., et al. (2012). The ssn on-

tology of the w3c semantic sensor network incubator

group. Journal of Web Semantics, 17:25–32.

Curry, E., O’Donnell, J., Corry, E., Hasan, S., Keane, M.,

and O’Riain, S. (2013). Linking building data in

the cloud: Integrating cross-domain building data us-

ing linked data. Advanced Engineering Informatics,

27(2):206–219.

Daniele, L., den Hartog, F., and Roes, J. (2015). Created

in close interaction with the industry: the smart ap-

pliances reference (saref) ontology. In International

Workshop Formal Ontologies Meet Industries, pages

100–112. Springer.

Dave, B., Buda, A., Nurminen, A., and Fr

amling, K. (2018).

A framework for integrating bim and iot through open

standards. Automation in Construction, 95:35–45.

Dawson-Haggerty, S., Krioukov, A., Taneja, J., Karandikar,

S., Fierro, G., Kitaev, N., and Culler, D. (2013).

{BOSS}: Building operating system services. In 10th

{USENIX} Symposium on Networked Systems Design

and Implementation ({NSDI} 13), pages 443–457.

de Farias, T. M., Roxin, A., and Nicolle, C. (2015). Ifc-

wod, semantically adapting ifc model relations into

owl properties. arXiv preprint arXiv:1511.03897.

Dibley, M., Li, H., Rezgui, Y., and Miles, J. (2012). An on-

tology framework for intelligent sensor-based build-

ing monitoring. Automation in Construction, 28:1–14.

ollner, J. and Hagedorn, B. (2007). Integrating urban gis,

cad, and bim data by servicebased virtual 3d city mod-

els. Urban and regional data management-annual,

pages 157–160.

Esnaola-Gonzalez, I., Berm

udez, J., Fernandez, I., and Ar-

naiz, A. (2016). Eepsa as a core ontology for energy

efﬁciency and thermal comfort in buildings. Semantic

Web, 1.

Fierro, G. and Culler, D. E. (2015). Xbos: An exten-

sible building operating system. In Proceedings of

the 2nd acm international conference on embedded

systems for energy-efﬁcient built environments, pages

119–120.

ISO9241-210 (2019). Iso - iso 9241-210:2019 - ergonomics

of human-system interaction — part 210: Human-

centred design for interactive systems. https://www.

iso.org/standard/77520.html.

Kciuk, M. (2014). Openwrt operating system based con-

trollers for mobile robot and building automation sys-

tem students projects realization. In 15th International

Workshop on Research and Education in Mechatron-

ics (REM), pages 1–4. IEEE.

Martirano, L. and Mitolo, M. (2020). Building automa-

tion and control systems (bacs): a review. In 2020

IEEE International Conference on Environment and

Electrical Engineering and 2020 IEEE Industrial and

Commercial Power Systems Europe (EEEIC/I&CPS

Europe), pages 1–8. IEEE.

Pauwels, P., Zhang, S., and Lee, Y.-C. (2017). Seman-

tic web technologies in aec industry: A literature

overview. Automation in Construction, 73:145–165.

Rasmussen, M. H., Frausing, C. A., and Karlshøj, C. A.

H. J. (2018). Integrating building information model-

ing and sensor observations using semantic web. In

SSN@ ISWC, pages 48–55.

Rosen, N., Sattar, R., Lindeman, R. W., Simha, R., and

Narahari, B. (2004). Homeos: Context-aware home

connectivity. In International Conference on Wireless

Networks, pages 739–744.

Schneider, G. F. (2017). Towards aligning domain ontolo-

gies with the building topology ontology. In Proceed-

ings of the 5th Linked Data in Architecture and Con-

struction Workshop (LDAC 2017).

Sleman, A. and Moeller, R. (2011). Soa distributed operat-

ing system for managing embedded devices in home

and building automation. IEEE Transactions on Con-

sumer Electronics, 57(2):945–952.

Vermorel, L. (2020). What is a building operating system?

https://blog.wattsense.com/building-management/

what-is-building-operating-system/#:

∼

:text=A%

20Building%20Operating%20System%20is,data%

20from%20the%20building’s%20equipment. (Ac-

cessed on 04/29/2021).

Wenjiang, L., Nanping, D., and Tongshun, F. (2009). De-

sign of the embedded remote monitor system for

building automation system based on the vxworks. In

2009 Asia-Paciﬁc Conference on Computational In-

telligence and Industrial Applications (PACIIA), vol-

ume 1, pages 436–438. IEEE.

Building Operating Systems: A Cloud-based Architecture for Enabling Knowledge Representation and Improving the Adaptability in Smart

Buildings

169