An IFC4-based Middleware for Data Interoperability in Energy Building

Operation

Jos

e L. Hern

andez, Susana Mart

ın and C

esar Valmaseda

Fundaci

on CARTIF, Parque Tecnol

ogico de Boecillo, Valladolid, Spain

Keywords:

Middleware, Interoperability, Data-model, IFC4, Heterogeneous Data, Interfaces, Data Consistency.

Abstract:

This paper addresses the existing gap in data interoperability among heterogeneous resources for energy ser-

vice systems of building automation. In this sense, the middleware is the core of the communication between

heterogeneous data samples and the application services. This kind of solutions integrates the multiple build-

ing data resources to gather the information within the context of energy and buildings and couples the data in

a single signal. The middleware also manages the data in an harmonized way by means of the representation of

the information in a well-established data-model as IFC4 which is widely used in the building topic. This kind

of harmonic communication allows the exchange of information among the entities in complex platforms by

common formats in order to ease the interpretation of data. Then, interoperability is a key factor for achieving

connectivity that is reached in the present middleware though the event-driven communication mechanisms

and the well-known interfaces.

1 INTRODUCTION

Nowadays, Building Energy Management Systems

(BEMS) are a growing ﬁeld of interest taking into ac-

count it is estimated that up to 40% of total energy in

Europe is consumed by buildings (Sustainable Build-

ings & Climate Initiative, 2009). With the objective

of reducing the consumption, several research efforts

and novel technologies are underway towards design-

ing smart systems (C21, 2014)(NET, 2014). Within

this context, the BaaS (Building as a Service) project

aims at reducing 15% of energy consumption through

ICT tools and by adapting control decisions in real-

time (Baa, 2014). For such purpose, it is strength-

ened the intersection of control algorithms, thermal

simulation, communication technologies, middleware

platforms, and building technologies.

As core of these systems, middleware enables

the communication between the building physics (i.e.

data measurements) and the application services (as-

sessment, prediction and control). The objective of

using a middleware is to obtain interoperability, trans-

parency and coherency in the communication of these

heterogeneous entities. In this scenario, the BaaS

middleware presented in this paper offers data man-

agement from various in- and out-of-building sources

that act as central repositories for all static and dy-

namic building data (Baa, 2014). Other external ICT

systems like a weather station are also considered as

data sources.

On the other hand, within the building context, the

aforementioned efforts still lack the full interoperabil-

ity concept. To achieve it, data models for the repre-

sentation of this information are required, as depicted

in (Crosbie et al., 2011), where semantic integration

of energy information is highlighted. Then, creating

a common language helps the integration and interop-

erability among entities along the building life cycle.

One of these data model is the Industry Foundation

Classes (IFC - ISO 16739:2013) (IFC, 2014) which

deﬁnes a set of domains where the building facilities

are modeled within the architecture, engineering and

construction (AEC) industry. BaaS system has con-

sidered this IFC4 speciﬁcation for the representation

of the information in all its layers. With this approach,

building stakeholders are able to interpret data in the

design of assessment and optimization tools.

Therefore, this paper presents a novel IFC4-based

middleware for the integration and coupling of het-

erogeneous building data in a homogeneous way. The

main purpose is to offer to the end user interoper-

ability and transparency among all the building au-

tomation entities through the same vocabulary. With

that aim, it abstracts the building physics in order

to provide two-way communication between the data

sources and the high level services. Besides that,

287

L. Hernández J., Martín S. and Valmaseda C..

An IFC4-based Middleware for Data Interoperability in Energy Building Operation.

DOI: 10.5220/0005371002870294

In Proceedings of the 17th International Conference on Enterprise Information Systems (ICEIS-2015), pages 287-294

ISBN: 978-989-758-096-3

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

the middleware has been designed according to stan-

dard and open source projects, such as OSGi (Open

Services Gateway initiative), to provide a framework

to Service-Oriented Architectures (SOA) and event

communication.

To overcome the description of the BaaS middle-

ware, this paper is mainly organized in three sections

where the requirements of the speciﬁc BaaS systems

are pointed out and comparison with existing plat-

forms is realized. Next, the high-level architecture,

communication interfaces, data model and interoper-

ability concepts are explained. Finally, the distributed

deployment of the system is depicted before the ﬁnal

conclusions reached during this study.

2 BaaS MIDDLEWARE

REQUIREMENTS

The ﬁrst step in any software development must be

the compilation of all the requirements and function-

alities which should be assured. BaaS design is not

an exception of this methodology and the function-

alities and performance requirements have been col-

lected. Table 1 summarizes these functional (FR) and

non-functional (NFR) requirements.

First of all, any middleware, by deﬁnition, has

to ensure interoperability among all the components

which is easier reached by means of making use of

standards or recommendations offered by the differ-

ent standardization bodies. In the speciﬁc case of

BaaS, the middleware needs to access to multiple ser-

vices and heterogeneous pieces of information as de-

scribed in the next bullets:

• Building Management Systems (BMS)

• DataWarehouse (DWH)

• Building Information Model (BIM)

• Existing ICT systems and external data services

• Assessment, Prediction and Optimal-Control ser-

vices and analytics

Each piece of information has its own communi-

cation language, and it has to be merged into a com-

mon one. Therefore, the middleware should be able

to translate and adapt the different information repre-

sentation into a same vocabulary. For such purpose,

the ISO 16739:2013 standard (IFC4) (IFC, 2014) is

selected. Then, the middleware should communicate

the speciﬁc protocol of the BMS and obtain sensor

data translated into IFC4. This is also applicable to

the external services (e.g. weather forecast or weather

station) whose information is required from the high

level services. Moreover, the DWH (Mo et al., ) and

Table 1: Requirements summary.

Identiﬁer Requirement description

FR-1 Baas MW should assure interoper-

ability among all the entities involved

in energy assessment

FR-2 BaaS MW should represent data into

the same vocabulary or data model

FR-3 BaaS MW should implement the

speciﬁc communication protocol at

building level

FR-4 BaaS MW should connect Web Ser-

vice for accessing Weather forecast

FR-5 BaaS MW should manage BIM en-

tities for the representation of the

building physics

FR-6 BaaS MW should maintain a coher-

ent data repository with dynamic data

FR-7 BaaS MW should maintain co-

herency and consistency among all

the data sources

NFR-1 BaaS MW should assure Quality of

Service parameters

NFR-2 BaaS MW should be compliant with

cloud deployments

BIM Server (TNO, 2010) are IFC4-based designed.

The ﬁrst one is the main repository of the BaaS sys-

tem for dynamic data and the BIM is in charge of

managing the building static data.

In order to enable the communication with

the aforementioned data-sources, a set of well-

established communication interfaces are deﬁned

based on standards (Hernandez et al., 2013b). How-

ever, each resource heterogeneously accesses to the

information, hence, the middleware covers this gap

with these communication interfaces, which transpar-

ently translates the data into IFC4. This solution as-

sures the interoperability and integration of heteroge-

neous data in an homogeneous way. Besides that, the

information between multiple data sources must be

coherent, therefore, additional components which en-

sure data consistency are required.

Last but not least, some performance require-

ments (non-functional) have been deﬁned to assure

Quality of Service. In that way, the system should

provide a sufﬁciently high availability (service level

agreement) and be scalable and replicable as well as

fault-resilient. Besides that, the BaaS system is de-

signed and developed according to cloud computing

premises which allow deploy the Building as a Ser-

vice or Platform as a Service.

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

288

2.1 Fitting the Requirements in Existing

Middlewares

After detailing the requirements and speciﬁcations for

BaaS middleware, the next phase is to determine if

any existing middleware overcomes with these needs.

Within the European context, multiple projects are

carried out, such as Campus21 (C21, 2014) or MOST

(Zach et al., 2012), but also other research initia-

tive, such as the one presented in (MWs, 2013), de-

ﬁne middleware platforms for buildings. Moreover,

several commercial solutions are in the marketplace,

as for instance NETxAutomation (NET, 2014) or

Smarkia (Sma, 2014). All of them treat the building

communication topic from an energy point of view

and using middleware platforms with different fea-

tures as explained below, although the commercial so-

lutions go beyond the middleware platform providing

the complete Building Energy Management System.

Starting with the Campus21 middleware (Schulke

et al., 2013), its objective is to render building op-

erations as happening in BaaS project. It also con-

siders multiple data sources whose information is ex-

changed among multiple entities and/or components.

Moreover, the requirements are similar to the BaaS

one (Schulke et al., 2013). However, it does not ap-

ply with the common data model because it shares the

data in Java-based objects. Even more, the protocol

for accessing the BMS is BACnet/IP, whereas BaaS

requires adaptability.

Next, Flotyski et al (MWs, 2013) present a build-

ing middleware working in the Internet of Things

so as to integrate multiple data sources in an OSGi

framework. This middleware is developed based on

events and as a gateway for connecting heterogeneous

devices in a modular manner, similar to BaaS. How-

ever, it is only centered into the integration of de-

vices though modules (MWs, 2013) without allowing

high-level services for the facility management. Even

more, each module is in charge of the speciﬁc device,

whereas BaaS middleware adapts the information into

the data model before exchanging it (Hernandez et al.,

2013b).

Regarding the Smarkia system (Sma, 2014), it

is a complete Building Energy Management System

which follows a similar architecture than BaaS be-

cause it gathers the information from the building

level so that high-level services perform the analyt-

ics. Yet, it does not use any speciﬁc data model for

exchanging the information, but the internal commu-

nication mechanisms interprets these data. The disad-

vantage of Smarkia, in comparison with BaaS, is that

the scalability is reduced.

Finally, NETxAutomation has developed the Voy-

ager 5.0 system (NET, 2014) which is a system which

integrates multiple protocols to access the BMSs. It

also applies control algorithms to improve the energy

performance in buildings, as presented in the demon-

strator cases (NET, 2014). Nevertheless, it is a closed

solution without the possibility of scalability which

does not couple multiple data sources, but it is based

on BMS. As well, it does not implement any data

model for the representation of the information.

2.2 Beyond the State of the Art

Once having explained how existing middlewares ﬁt

with the requirements of the BaaS system, it can be

concluded that no one applies with the full stock of

requirements in the BaaS system, as pointed in the

Table 2. This table highlights the differences from the

presented middlewares in comparison to the require-

ments and draws why BaaS platform goes a step for-

ward in order to cover the lacks of existing systems.

Above of all, the most important result of the mid-

dleware is the presence of a common context for ex-

changing data. IFC4 has been selected as the data

model for the BaaS middleware, and although this

standard is large, a subset of objects have been used,

as described in section 3.2. BaaS is able to map the

information from the data sources in this common for-

mat. The great novelty of that is the capability to rep-

resent the information in the same context of the ap-

plication, i.e. buildings.

On the other hand, BaaS manage multiples and

heterogeneous data sources, such as Building Man-

agement System, BIM, DataWarehouse, etc., as de-

picted in section 3.1 and 3.3. Then, so as to increase

the scalability and replicability of the solution, the

presented solution connects the communication pro-

tocols of the building, instead of providing a commu-

nication interface and having to adapt the building to

the software. For example, Campus21 middleware is

compliant with BACnet, but the full stock of buildings

are not BACnet compatible. With BaaS, the connec-

tivity with open and standards protocols is assured.

As well, the integration of additional data resources

eases the common understanding of the energy per-

formance in buildings through the building informa-

tion and weather conditions, among others.

Another advantage of the BaaS middleware is the

coherency of data among data sources, as explained

in section 3.3. Normally, the middleware systems en-

sure the interoperability among different entities, but

it does not take care of the coherency of data. This

functionality is usually implemented in high level ser-

vices or by means of intelligence in the data layer.

Nevertheless, the novelty presented in BaaS, is the ca-

AnIFC4-basedMiddlewareforDataInteroperabilityinEnergyBuildingOperation

289

Table 2: Comparison among existing middlewares.

Req. Campus21 Flotyski Smakia NETx

FR-1 Yes Yes Yes Yes

FR-2 No No No No

FR-3 No Yes Yes Yes

FR-4 Yes Yes Yes Yes

FR-5 Yes No No No

FR-6 Yes Yes Yes Yes

FR-7 No No No No

NFR-1 Yes Yes Yes Yes

NFR-2 No No Yes Yes

pability of the middleware to periodically check the

data sources, compare them and determine if any in-

consistency has been detected so that the administra-

tor could be automatically reported about it.

Last but not least, cloud consideration are not al-

ways taken into consideration in middlewares, but the

capability of providing interoperability. Taking into

account this current trend in novel systems, BaaS has

been designed to operate in cloud platforms and offers

the opportunity of being deployed under Building as

a Service where the building is the core.

3 ARCHITECTURE OF

MIDDLEWARE-BASED BaaS

SYSTEM

The BaaS middleware has been designed according

to the functional and non-functional requirements de-

scribed in the section before. With all of them in

mind, the high-level architecture of the BaaS mid-

dleware is an event-driven platform following the

Service-Oriented Architecture (SOA) patterns and

the OSGi framework. Figure 1 (Hernandez et al.,

2013b)(Floeck et al., 2013) represents this system

which is composed by three levels: data layer, com-

munication logic layer (CLL) or middleware layer

and the application layer based on high-level ser-

vices (assessment, prediction and optimized control).

Moreover, the communication interfaces are drawn

which ensure the interoperability among all the com-

ponents of the system, as well as they integrate the

heterogeneous data sources.

The Communication Logic Layer (CLL) of this ar-

chitecture, in the form of a middleware entity, is the

topic of the present paper. It is basically split into two

sub-layers: the core communication and data access

object (DAO) (Hernandez et al., 2013b). Communi-

cation core is responsible for the management of the

signals and the business core. In contrast, DAO aims

the integration of heterogeneous data sources and ho-

mogeneizes the information in a common data model.

Apart from that, the CLL is, at the same time, di-

vided into two entities: Data Acquisition and Control

Manager (DACM) and Domain Controller (DC). The

ﬁrst one is the server side and manages the commu-

nication procedure and the second one is in charge of

the building connectivity. The objective of this desing

is to increase the scalability and extensibility, as well

as allow the cloud deployment.

3.1 Interoperability Communication

Interfaces

Interoperability is a concept inherent to middleware

platforms and it describes the capability for intercon-

necting modules in a transparent way so as to ex-

change information. Communication interfaces are

required here to set up a well-known communication

mechanism focused on allowing connectivity, per-

forming the expected functionality, and adaptating

communication languages between layers.

In the context of the BaaS middleware, several

interfaces (I1 to I10) have been deﬁned (Hernandez

et al., 2013b)(Floeck et al., 2013) (see Figure 1). I-

1 is the interface between the application layer and

the middleware itself to carry out assessment, predic-

tion and control tasks. Thus, the main topics in this

communication are the retrieval of data from the data

layer and the results of the application calculations,

both to actuate over the BMS and to store these re-

sults. I-2 establishes the communication between the

modules of the CLL to connect the building side and

the server part of the middleware. I-3 posts events

between the core communication and DAO sub-layer

to the retrieval/storage of data from the BIM Server,

DWH and/or external services. Similarly to I-3, I-4

enables connectivity between the core and the DAO

for accessing the building data.

Communications with the data layer are estab-

lished through the interfaces I-5 to I-8. I-5 imple-

ments the protocols available on the BMSs. SOAP,

BACnet/IP, OPC and FTP are connectors considered

within the BaaS project. I-6 makes use of Java meth-

ods provided by the BIM Server client to query this

data source. I-7 deﬁnes the communication between

the CLL and the DWH through mechanisms for the

retrieval and storage of data. The DWH is Oracle-

based, but Hibernate framework has been used with

the aim of mapping the relational tables into Java ob-

jects. By its side, I-8 enables the communication with

external services, i.e. weather forecast, retrieving the

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

290

Figure 1: BaaS system high-level architecture.

information in XML format by means of HTTP calls.

I-9 is out of the scope of the middleware and, ﬁnally,

I-10 enables the communication from the Graphical

User Interface (GUI) and the CLL to exchange infor-

mation. This GUI is developed within the BaaS plat-

form to display measurements, conﬁgure the system

and access to the application results.

All the interfaces are event-driven by using the

event communication mechanism provided by OSGi

framework. The communication is based on three el-

ements: Event Publisher, Event Subscriber and Event

Admin. The ﬁrst one represents the module that posts

the events in the environment, the subscriber which

listens to the subscribed events and the admin is the

dispatcher of the framework.

3.2 Data Model for Data Representation

One of the greatest novelties of the middleware pre-

sented in this paper is the data-model representation

for exchanging information among entities. The BaaS

system objective is to perform buildings operation so

as to run high-level services for the optimization of

the energy performance. In this context, IFC4 (IFC,

2014) is a commonly-used standard in buildings for

the representation of their information within the ar-

chitecture, engineering and construction (AEC) in-

dustry. IFC4 is a large data model and comprises up to

753 objects (IFC, 2014) grouped in multiple domains.

BaaS platform is focused on the assessment and

optimal control of buildings. Therefore, taking into

consideration IFC4 represents the building physics,

but also its facilities and systems, a reduced set of do-

mains and classes available on (IFC, 2014) has been

selected as the basic data model (Cahill et al., 2012)

for the middleware to represent the information in the

communication process. The useful domains in this

speciﬁc system are described below.

• Structural domain: It contains the objects that rep-

resent the building physics, i.e. structure, room

distribution, materials, etc.

• HVAC domain: It includes the information re-

lated to the heating, cooling and ventilation sys-

tems which are the focus of the optimal control

platform and it is the basic concept for interoper-

ability within the data model. This domain points

out the equipment (e.g. boilers), terminal and ﬂow

control devices (e.g. valves).

• Building controls domain: This schema expresses

the concepts about building automation, control

and alarms. That is to say, devices like sensors,

actuators and controllers, among others.

The shared information in the communication pro-

cess is fully represented by the objects and prop-

erty sets included in every domain. The relation-

ships among domains are described by classes with

AnIFC4-basedMiddlewareforDataInteroperabilityinEnergyBuildingOperation

291

the same format commonly named IfcRelElement. On

the other hand, the property sets deﬁne the properties

of the class and how they must be interpreted. For

example, a very useful object for the representation

of the dynamic readings is the TimeSeries, described

below.

ENTITY: IfcTimeSeries

Name: IfcLabel

Description: IfcText

StartTime: IfcDateTime

EndTime: IfcDateTime

TimeSeriesDataType: IfcTimeSeriesDataTypeEnum

DataOrigin: IfcDataOriginEnum

UserDefinedDataOrigin: IfcLabel

Unit: IfcUnit

The IFC4-based data model allows ”context-

awareness” in the middleware. Since the design

phase, the components have been modeled taking it

into consideration (Floeck et al., 2013). Thus, the

data layer comprises sources based on IFC4, such as

the BIM Server (TNO, 2010), that is IFC4 compliant.

In the case of the DWH, the schema has been devel-

oped according the aforementioned domains and their

property sets (Mo et al., ). Finally, the remaining com-

ponents working with the data layer retrieve the data

in the speciﬁc protocol and translate the information

into the IFC4 common data model. For such reason,

the middleware (CLL) shares, among all the entities,

Java objects (Hernandez et al., 2013c) which repre-

sent the IFC4 classes in order to harmonize the hetero-

geneous data. Besides that, the DWH contains map-

ping tables with the aim of mapping the data-points

identiﬁers from the speciﬁc communication protocol

into the IFC4 context. Bearing all of this in mind, the

event communication procedure shares the IFC4 ob-

jects as properties of the OSGi events under the dif-

ferent topics.

The advantage of using IFC4 as data model rep-

resentation is the data formatting in a standard vo-

cabulary which is widely understood within the AEC

industry. Moreover, it maps the building physics

and facilities through classes and attributes that eases

its integration and rewards the building platform due

to the ”context-awareness” capability. Finally, it

also enhances the scalability of the system because

any additional service only needs to adapt the ex-

changed information into IFC4 format through the

well-established interface.

3.3 Integration of Heterogeneous Data

Sources

The harmonization of the data samples is the chal-

lenge in this middleware platform because, as ex-

plained, heterogeneous resources are accessed and

their information has to be represented in IFC4

(Floeck et al., 2013). With the aim of interfacing

them, connector components are developed and lo-

cated in the DAO sub-layer of the system architec-

ture. Each one is detailed below, but commonly all

the connectors adapt the information from IFC4 to the

speciﬁc data model in the data layer and vice versa.

• BMS Connector: This connector is really com-

posed by the BMS and ICT connectors (e.g.

weather station), but both are related to the build-

ing. This component is replicated for each build-

ing and its speciﬁc interface which provides the

ability for the integration of additional BMSs with

different protocols (Hernandez et al., 2013b).

• BIM Connector: For the assessment of the build-

ing performance, it is required to know the build-

ing facilities and systems, as well as other build-

ing features. Then, this connector reads the in-

formation from the BIM Server by means of its

libraries based on IFC4 (TNO, 2010).

• DWH Connector: One of the most important com-

ponents in the system, it reads/writes data from/to

DWH so as to keep record of the dynamic build-

ing status, performance and conﬁguration data.

• External Data Connector: Prediction activities in

energy management systems are a necessary func-

tionality. In that sense, this module connects

to the weather forecast Web services (Hernandez

et al., 2013b) to retrieve this information.

The only data-source fully compliant with IFC4 is

the BIM Server, being necessary some adaptation in

the remaining cases. With regard to the DWH, it ex-

tends the IFC4 data model to represent the relational

tables and the use of Hibernate framework allows the

representation of the information as IFC4 objects to

ease the communication between CLL components

and the DWH (Hernandez et al., 2013a). About the

BMS and External Data connector, they require an

additional adaptation though Plain Old Java Objects

(POJO). The connector is able to read data and map

this information into IFC4 classes represented in the

POJO before posting the event (Hernandez et al.,

2013c).

Finally, it is important to note that the commu-

nication is bidirectional, which implies the increase

of the amount of the events in the system. For this

reason, all the information associated to each connec-

tor is merged in single events (i.e. TimeSeries object

(see above)) so as to reduce bottlenecks when pro-

cessing multiple signals. In this case, another com-

ponent, named General Integrator, is the responsible

and it is already compliant with IFC4 (Floeck et al.,

2013).

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

292

Figure 2: Deployment scheme for the BaaS system.

4 RESULTS

By deﬁnition, a middleware is a distributed system

which allows connectivity between multiple layer and

entities. Then, following these premises, the deploy-

ment of the BaaS system presents an hybrid scheme,

as pointed in Figure 2 (Hernandez et al., 2013a). In

this scheme, there is a mixture between centralized

and distributed systems following a server-client com-

munication. The DACM illustrates the server which

centralizes the communication between the building

sides (i.e. BMS, DWH, BIM) and the upper lay-

ers (i.e. application and visualization). On the other

hand, the client side is represented by the DCs that im-

plement the speciﬁc communication at building level

and are physically deployed in the building.

BaaS system merges four building data, therefore

four DC entities that exchange information with a sin-

gle DACM server through web services. The DACM

can be also distributed, although the communication

between upper and lower layers is still centralized in

the DACM concept, if the load collapses its perfor-

mance, but it is not the case. The same web service

protocol is used for the communication with the ap-

plication services which are deployed in an external

server owing to its high performance requirements.

Finally the GUI is integrated in the DACM, making

up a distributed architecture that exchange informa-

tion among the entities in an harmonized way.

At the current status, the deployment step in un-

der test, although the complete communication ﬂow

is available in the CARTIF ofﬁces building located in

Boecillo, Spain. In this pilot, the four connectors are

deployed so as to retrieve and store data which allows

keeping an historical record for further optimization

tasks in the application layer. Figure 3 represents the

deployment scheme in which the DACM is hosted in

the server side, whereas the DC is placed in the build-

ing site. The connectivity between them is rendered

by Virtual Private Networks (VPN) to avoid exter-

nal invasion. Moreover, the computer hosting the DC

Figure 3: Deployment scheme in the CARTIF building.

contains the BMS and ICT connector that communi-

cate two LonWorks-based BMS and the weather sta-

tion (ICT system) and merge the information in a sin-

gle event with the data translated into IFC4 to be sent

to the DACM server. Finally, the DACM computer

deploys the connectors with the BIM Server, DWH

and weather forecast. Additional components, such as

the operation schedulers, application layer and graph-

ical user interface are being deployed in next steps.

5 CONCLUSIONS

In the current energy research topics, buildings are

trend because the great possibilities they present to

save energy. Mainly, there are two approaches to

overcome the problem: passive solutions such as in-

sulation system or improvement of the facilities and

active ones, as for example ICT tools. This is the case

of the BaaS system where a multi-layer platform has

been designed for the management of the generation

and distribution systems through assessment, predic-

tion and control services.

Within this context, the middleware is a very

important piece because it allows connectivity with

multiple data resources which provide heterogeneous

data. Each source has its own protocol and interface,

therefore the middleware is able to integrate the in-

formation of the various data resources. To achieve it,

integrator components merge the information in sin-

gle signals so as to ease the retrieval of data to upper

layers. With this aim, the middleware system bridges

the gap between the Smart Grid and the information

services for the analysis of operative tasks.

On the other hand, the middleware platform pro-

vides connectivity in a common format in order to

avoid misunderstandings between layers. It homoge-

nizes and shares information in the same common for-

mat, i.e. IFC4 for the BaaS speciﬁc case, through Java

beans to map heterogeneous data into IFC classes.

This IFC model is a widely-used standard within the

building ﬁeld and it includes a data schema for the

AnIFC4-basedMiddlewareforDataInteroperabilityinEnergyBuildingOperation

293

building facilities and it is also easy to integrate ad-

ditional information, such as dynamic data, by means

of extending the data model and its classes.

Next, taking into account the integration and cou-

pling of heterogeneous data for sharing information in

a common language, data coherency and consistency

ought to be considered. In this way, the middleware

implements a periodic mechanism for checking the

cross-related information between the data sources.

For this purpose, several components query the dif-

ferent data sources, compare the results and, in case

of incoherences, report an alarm.

Regarding next steps and future lines, the aim is to

start an operational stage by integrating all the layers

in the system and run the optimal control over four

demonstration buildings. Once the complete deploy-

ment will be ready, the performance tests will be car-

ried out to detect the software goodness parameters

and improve the quality of service. Finally, this de-

velopment establishes the fundamentals for the repli-

cability of the solution in multiple buildings thanks to

its extensibility and scalability properties.

ACKNOWLEDGEMENTS

The authors would like to thank the partners of the

BaaS project for their support during the design and

development of the middleware platform. Moreover,

the authors would like to thank the European Com-

mission for the opportunity of working in this topic

under the Grant Agreement no. 288409.

REFERENCES

(2010). Tno: Bimserver, open source building, http://

www.bimserver.org. Last accessed 21st Aug. 2014.

(2013). In The Future Internet, volume 7858 of Lecture

Notes in Computer Science.

(2014). Baas project grant agreement no.288409, https://

www.baas-project.eu/. Last accessed 4th September

2014.

(2014). Campus21 project, http://campus21-project.eu/.

Last accessed 3rd November 2014.

(2014). Ifc4 rc4, http://www.buildingsmart-tech.org/

ifc/ifc2x4/rc4/html/. Last accessed 19th August 2014.

(2014). Netxautomation: Voyager 5.0, http://www.netx

automation.com/netx/en voyager-visualization.html.

Last accessed 5th Nov. 2014.

(2014). Smarkia: Energy efﬁcient systems solution, http://

www.smarkia.com. Last accessed 26th Nov. 2014.

Cahill, B., Menzel, K., Floeck, M., Schmidt, M., Schuelke,

A., Etinski, M., Hernandez, J. L., Martin, S., and Val-

maseda, C. (2012). Deliverable d3.1: High-level ar-

chitecture, interfaces deﬁnitions, data models exten-

sion description. Technical Report 1.

Crosbie, T., Dawood, N., and Dawood, S. (2011). Improv-

ing the energy performance of the built environment:

The potential of virtual collaborative life cycle tools.

Automation in Construction.

Floeck, M., Schuelke, A., Schmidt, M., Hernandez, J., Mar-

tin, S., and Valmaseda, C. (2013). Tight integration of

existing building automation control systems for im-

proved energy management and resource utilization.

In Conference on Central Europe towards Sustainable

Building, CESB’13, Prague, Czech Republic.

Hernandez, J. L., Martin, S., Floeck, M., Schmidt, M.,

Mo, K., and Katsigarakis, K. (2013a). Deliver-

able d3.6: Development guide, https://www.baas-

project.eu/images/deliverables/baas wp3 d3.6 devel-

opmentguide 1.1.pdf. Technical Report 1.

Hernandez, J. L., Martin, S., Floeck, M., Schmidt, M., Mo,

K., and Rojicek, J. (2013b). Deliverable d3.3: Inter-

faces deﬁnition. Technical Report 1.

Hernandez, J. L., Martin, S., Floeck, M., Schmidt, M., Mo,

K., Rojicek, J., and Katsigarakis, K. (2013c). Deliv-

erable d3.5: Detailed system design. Technical Re-

port 1.

Mo, K., Menzel, K., and Hoerster, S. Development of

an ifc-compatible data warehouse for building perfor-

mance analysis. In Proceedings of the 30th CIB W78

International Conference.

Schulke, A., Schmidt, M., and et al, M. F. (2013). A mid-

dleware platform for integrated building performance

management. In Mahdavi, A. and Martens, B., editors,

Proceedings of the 2nd Central European Symposium

on Building Physics, volume 1, pages 459–467, Vi-

enna Austria. Vienna University of Technology.

Sustainable Buildings & Climate Initiative, U.-D. (2009).

Buildings and Climate Change: Summary for

decision-makers. Sustainable United Nations, Paris

CEDEX 09, France.

Zach, R., Glawischnig, S., Honisch, M., Appel, R., and

Mahdavi, A. (2012). Most: An open-source, vendor

and technology independent toolkit for building mon-

itoring, data preprocessing, and visualization. In Pro-

ceedings of ECPPM conference, Reykjavik, Iceland.

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

294