A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

Comprehensive Building Information Management System Approach

Artur Krukowski Dusan Arsenijevic

Intracom S. A. Telecom Solutions, UNIBRAIN S. A.
19.7km Markopoulou Av., 19002 Peania, Greece Peania, Greece
[email protected] [email protected]

Sofoklis Efremidis Abolghasem (Hamid) Asgari

Athens Information Technology, Thales Research & Technology (UK) Limited,
19 Markopoulou Avenue, Paiania, 19002, Greece Worton Drive, Reading RG2 0SB, United Kingdom
[email protected] [email protected]

Kalevi Piira and Olli Stenlund Anu Ktk and Jarno Mitjonen
VTT Technical Research Centre of Finland, Lonix Ltd
P.O. Box 1000, FI-02044 VTT, Finland Teollisuuskatu 33, FI-00510 Helsinki, Finland
[email protected], [email protected] [email protected], [email protected]

Abstract -The paper presents the results of a joint work on the Integrated Building Information Management System developed
and tested in the frame of the European research project I3CON funded from the 6th Framework Program. This innovative system
proposes an innovative approach to dealing with building information managing, employing Wireless Sensor Networks and the
Rule Based Engine for monitoring the building environment as well as for automatic control of its infrastructures (water,
electricity, heating, cooling etc). It involved also the development of integrated user interfaces allowing location and context aware
operation of the mobile system including methods and tools for their implementation for Building Service Operative applications.
This allows mobile service personnel to have a full access to the building information system from their mobile terminals enhanced
with location awareness (employing latest active RFID technologies), context awareness and multi-modal user interfaces for hands-
free intuitive operation of a mobile system with little or no need for manual operation or control. A generic object browser was
developed enabling of browsing building automation objects in real-time as well as static building database objects and properties
using standard data communication protocols. The described technologies have been already deployed and tested in real
environment of the residential Margarita building in the center of Madrid.

Keywords: Multimodal User Interfaces, Building Control, RFID Positioning, Content Adaptation, Context Adaptation,
Personalisation, Profiling, Wireless Sensor Network, WSN, Building Management System.

I. INTRODUCTION Within this framework I3CON foresees the use of

advanced terminal devices for supporting the diverse set of
I3CON1 project aims at enhancing the sustainability of Building Operational Services (BOS). Because of the
the European construction industry by delivering nature of their work, communication of building related
industrially produced, integrated processes and intelligent information to the operational services personnel is
building systems using distributed control systems with expected to employ highly intuitive and natural user
embedded sensors, wireless connections, ambient user interfaces resulting in minimal interaction overhead. Such
interfaces and autonomous controllers. New value based interfaces are to exploit a variety of modalities, including
business models with highly specialized SMEs working in visual and audible in addition to context & location-
radically contracted supply chains are expected to deliver awareness. In this work we determined the specification
high performance spaces, smart business services and and performed an implementation of multimodal interfaces
lifecycle solutions. to building data (real time and static model) accessible via
building service gateway (BSG) for use by the operation
services personnel, based on narrowband (text, data) and
1
This work was conducted in the frame of the European research broadband (voice, video, images etc) services, enabling
project NEM-I3CON-026771-2 Industrialized, Integrated, voice/speech/video interactions and user profiling. Parallel
Intelligent Construction. This project received funding from to this we developed a Generic Object Browser (GOB)
the 6th Framework Program (FP6) of the European Commission application for viewing dynamic real time objects from
(EC). The EC has no responsibility for the content of this paper. building automation systems as well as static building data
Information in this document reflects only the views of the objects from the BIM databases.
authors, and is provided as is, and no guarantee or warranty is
given that the information is fit for any particular purpose. In order to enable context and ambient awareness for
mobile application we developed an RFID-based wireless

IJSSST, Vol. 11, No. 3 12 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

positioning system allowing tracking the position of the sensor values in the common graphical user interface (client
operational service-person inside the building and using this based or browser based user interface), together with the
information for display of data relevant to this location and data gathered from other systems. Also other functions
the operation context. The terminal adaptation aspects were provided by the BOS platform are automatically in their
considered, to allow accessing GOB from a wide range of perusal such as trends or alarms.
mobile devices enabling them to interface with the building Data from Building Information Model (BIM) can be
databases and control systems as well as to interact with imported to BOS platform to be utilized during the
variety of its components (e.g. controlling temperature in a operational phase of the building. The BOS platform is
room). Implementing terminal adaptation helps resolving based on a defined Data Model, which enables efficient
such issues as related to downscaling or transcoding of the handling of structured data. The building, its technical
content so as to fit the device specific terminal capabilities. systems, their sphere of influence and included devices as
well as user roles are defined in the Data Model. The BOS
II. SYSTEM ARCHITECTURE Data Model includes a subset of the full BIM, i.e. those
The Integrated Building Management System objects from the BIM, which are necessary for BOS to
architecture is based on a common system platform, the operate. The following main elements are included BOS
Building Operating System (BOS), to enable integration Data Model (Figure 2):
and interoperability of all building systems. Structure of building
Floors, spaces etc (without geometry information)
Control systems
AHUs, heating systems, access control, etc.
Devices
Sensors, fans, pumps, doors, cameras, etc
Operation areas
Areas of operation for all devices

Standard model of real world

Estate
Standard model of abstract things

Standard model of user roles Building/Area

Device manufacturer dependent

adaption to standard COBA model Building Part Control System

Server dependent COBA driver to

control network
Space Control Group
Effect Area
Mandatory

Figure 1: BOS Architecture Optional

Location

User Role Location

Device Information Point

The BOS platform comprises defined interfaces for any

system and any application to be connected with BOS. The Control Network
interfaces reside in two ends of the platform:
Figure 2: BOS Data Model
Enterprise Interface allows a variety of applications
and services to be produced and connected with the
The BOS Data Model contains various components:
BOS platform and accessing all BOS connected systems
both locally and remotely. The open Enterprise Control System: container of Control Groups or other
Interface enables provisioning of any type of value- Control Systems which forms one process e.g. air-
adding services requiring access to connected building handling unit or access control system. Control Systems
systems. are linked to buildings. This link indicates their physical
location.
System Interface allows different systems to be
connected with the BOS platform utilizing specific Control Groups (CGs): abstract presentations of actual
drivers. New drivers are implemented according to the devices (e.g. fans, pumps, doors.). CGs consists of
System Interface specification. System Interface Information Points, which presents inputs and outputs
standardizes manufacturer specific details and of controlled devices.
proprietary technologies and adapts systems to open Effect Areas: link between Control Groups and Spaces.
BOS platform. Effect Area defines the Control Groups having an impact
Network Interface Driver (NID) is a component, which on a specific space. For example, the Effect Area of a
adapts different protocols and communication methods to lighting group can be a single office room. Similarly, the
the BOS System Interface. For example, Wireless Sensor effect area of a fan - physically located in the air-handling
Network (WSN) is integrated with other systems through a unit - can be a zone including several rooms. Thus, the
WSN NID. The implementation allows for showing the effect area may differ from the physical location of the

IJSSST, Vol. 11, No. 3 13 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

Control Group. Concept of Effect Area maps the building The Mapping Table is a MySQL database which binds
system data into the physical model of the building. This together BIM instances, BACS instances and user defined
information does not otherwise exist at all and is therefore instances. The data flow through BSG is shown in Figure 4.
extremely important. BSG sends information and calls the BIM, the BACS and
The BOS platform combines benefits of modelling BsgMappingTable WEB services based on the requests
with integration capabilities through defined interfaces, thus received from BSG client. After receiving a response, BSG
enabling implementation of even complex systems in a sends it to the BSG client.
standard manner, utilizing existing definitions, interfaces
and components. A. BSG Example Clients
In future it is possible to develop BSG related building
III. BUILDING SERVICE GATEWAY life cycle applications enabling efficient, economical, high
performance, productive buildings and related new life
The Building Service Gateway (BSG) offers data cycle services. Some examples of BSG clients are Generic
access to integrated BIM (IFC) and BACS (BACnet, etc) BSG object browser and Ambient User Interface (UI).
data needed in building life cycle applications like space
related services, building lifecycle performance metrics B. Generic BSG Objerct Browser
reporting and new value driven services. The runtime
environment architecture for the implemented BSG The Generic BSG object browser is one example of
research prototype is shown in Figure 3. possible BSG clients. The idea of BSG object browser is to
browse online the data relating BIM, BACS and the BIM
BSG client BSG modules
Only used
and BACS integration model called BSG Mapping table.
General IT platform The data flow of Generic BSG object browser is based on
Possible extensions
BSG web services calls activated by user (Figure 5). The
BSG return values of those web services are xml strings based on
IIS + .NET BIM (IFC) de facto standard, BACS (BACnet) standard
BSG Mapping and BSG mapping table data model. Three kinds of content
BSG WS Table WS MySQL can be browsed with Generic BSG Object Browser: BIM,
BSG BACS and BSG.
BSGs BIM WS BSGs BACS WS Mapping
Lonix Other BACnet Other Table
BIM calls BIM calls BACS BIM browsing
The online browsing of BIM instances is typically
started by searching the interesting root node. For example
BACS
BIM
BACnet WS
(SCADA Engine)
using command GetInstancesByType with parameter
Axis2 IfcSpace (see IFC data model) gives all room ids for
Lonix IFC
BACnet network
possible root node. By clicking the root node, the instance
BIM WS (+ SCADA Engine BACnet device simulator) details are retrieved online from the BSG and the new
branch appears in the browsing tree below the root node.
Figure 3: BSG runtime environment architecture This happens also when any other BIM instance or
The implemented BSG utilizes BIM web services reference is clicked in the tree. The details will be shown
implemented by LONIX and standard based BACS web below the selected instance (Figure 5).
services (BACnet WS - ANSI/ASHRAE Standard 135-
2004c-1 [1]) implemented by SCADA Engine [4]. LONIX
BIM web services are installed onto Apache Axis2 Web
services engine.
Lonix BIM

Instance IDs,
types
Instance
details

Instance IDs, Instance IDs,

attributes attributes
BACnet based
BSG client BSG
BACS
Instance Instance
details details

Instance IDs
Mapped
instance
IDs

BsgMappingTable

Figure 4: BSG data flow Figure 5: Browsing BIM data

IJSSST, Vol. 11, No. 3 14 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

BACS browsing
BACS browsing is quite similar to BIM browsing.
BACS instances have id-attributes and by clicking them
details about the instance are retrieved online from the BSG
and shown below the selected tree node. BACS instances
have many attributes and by clicking the attributes, their
values are shown. By clicking the children-attribute, the
list of BACS children of the parent node is shown.
Browsing BACS data is shown in Figure 6.

Figure 7: PC based Ambient UI application interface

III. WSN FOR BUILDING MONITORING

The emergence of Wireless Sensor Networks (WSNs)

has brought significant benefits as far as environmental
monitoring is concerned, since they are more cost-efficient
(because of the lack of wired installations) compared to
their wired counterparts, while additionally they allow for
flexible positioning of the sensor devices. Any WSN
architecture should be designed in such a manner, so as to
allow its straightforward integration to the general
networking infrastructure where any other application can
Figure 6: Browsing BACS data
utilize the data gathered by WSN.
BACS instances can also be monitored, which means The most prominent approach towards realizing the
that their values are updated every 5 seconds in the low above goal is that of Service Oriented Architectures (SOAs)
right corner window. Monitoring can be turned on by open framework. In the case of SOAs all architectural
pressing the monitoring on radio button. The monitored elements are decoupled and considered as service providers
instance or one of its child nodes must be selected in the left and consumers. Service discovery and access to the services
window. The instance /1/1/0/2 are monitored in Figure 6. is performed in a dynamic manner, ensuring thus a generic
and extensible design. Web Services constitute the most
significant technological enabler of SOAs due to the
interoperability that they offer and the fact that they can
C. PC Based Ambient UI Application easily support the integration of existing systems.
In this section, we provide a detailed architectural
Ambient UI application is another example of possible framework for WSNs for integrating with other applications
BSG clients. The PC based ambient UI application interface over a SOA infrastructure. The functionality of the WSN
is shown in Figure 7. The main idea is to read the RFID tag architecture can be decomposed in two complementing
from the real room. In this implementation the RFID value aspects, namely:
is given manually to the text box called User defined id.
The related mapping item contents are shown in the left WSN services exposed to the applications (service
window as a tree. The mapping item related BIM and consumers) by means of the enterprise middleware.
BACS instance graphical 3D models are shown in the right WSN tasking to enable configuring sensor nodes for
window. The user can move the camera in the 3D virtual data collection by means of the tasking middleware.
world by giving keyboard commands and instances can be The WSN architecture assumes the role of service
selected by clicking them with mouse. When the user provider as far as data collection and information
selects an instance it is shown blinking in the model management is concerned. This justifies the need for a
window. The selected instances BIM and possible real WSN service interface to be defined and exposed to the
time BACS information is shown in the bottom window. SOA infrastructure, in order to hide the complexity and

IJSSST, Vol. 11, No. 3 15 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

heterogeneity of the underlying WSNs. The architecture allow for survivability of the WSN i.e., having diverse
that we propose for this purpose has to additionally cater for routes where not all nodes should use the same path to route
the monitoring and data management aspects. These their data towards the gateway, which would drain the
functional requirements are addressed by a tasking resources of particular nodes rapidly and hence lead to node
middleware that is responsible for handling translating the failures.
requests for information as received from Nevertheless, conceptually the WSN should be viewed
applications/clients and translating them into WSN-specific from external entities as having a single point of access to
data queries. The clients need not be aware of the WSN ensure consistency and have manageable administration.
internal operations, hence the importance of the tasking For every WSN therefore one of the gateways assumes the
middleware. role of the Master Gateway (MGW) and the remaining
A typical use case scenario of the proposed WSN gateways, if any, are deemed as Secondary Gateways
architecture involves the following. When another (SGW). Both the MGW and SGWs manage their respective
application/service wishes to obtain specific WSN assigned sensor nodes, but the MGW is moreover
monitored information, it accesses the respective WSN responsible for coordinating all gateway activities within a
service interface requesting so. The WSN service is zone through an appropriately defined gateway
discovered by accessing the Service Registry, which coordination protocol and serving as the single point of
provides details on available service interfaces that satisfy access to the WSN for communication with external
certain selection criteria. Upon receiving a client request, entities. The gateway coordination protocol is responsible
the WSN service assigns this request to the tasking for informing the Server of any changes in the WSN, e.g.
middleware that directly operates on top of the sensor nodes MGW and SGW status.
and performs the actual data collection and possibly As shown in Figure 8, the network service layer deals
processing. The outcome of this operation, i.e. the with the communication aspect of the sensor network such
corresponding sensed data, is then forwarded to the WSN as addressing, routing and data transport. It also relies
service that is stored in the data base and is then the mainly on the radio/enterprise network interface
processed information posted back to the original requester. components for communication at MAC or IP levels.
The node services are the functions, which are local to the
devices. Both sensor node and gateway contain the same
Wireless Sensor Network
Applications
basic computing functions, namely processing, storage and
a radio function. The gateway additionally has an external
Control
Access

network interface, to connect to the wider network (e.g.,

Tasking Gateway Tasking Enterprise
middleware Coordination
Middleware
Intranet), so that the corresponding WSN can be accessed
Reprogramability

Network
Reprogramability

remotely and also to allow for the inter-gateway

Network Network
S e c u r i t y,

S e c u r i t y,

Services Services
S e r v i c e s (IP)
WSN Intranet

communication (MGW to SGWs). Sensor nodes contain a

number of additional node services, not present in the
Node Node
Services Services

Sensor Node Gateway Server gateway, such as a sensing, a power management and a
positioning function.
Figure 8: Functional layered architecture for WSN. The Server is made aware of various WSNs available
in the enterprise building or field and their respective
The WSN architecture is implemented over two sensor MGWs and SGWs by accessing a topology map. When
platforms, i.e. the sensor node and the gateway, while at a applications/ services require interaction with the WSN
higher layer of abstraction the Server entity is responsible architecture as a whole, this occurs through the relevant
for managing the WSN nodes. The high level, layered WSN service interface that interacts with the Server. The
architecture of the WSN infrastructure is shown in Figure 8. Server is equipped with an enterprise middleware layer,
The functionality for both the sensor nodes and the which is responsible for communicating with the WSN
gateways is almost identical apart from the fact that the service interface of the SOA. It has to be clarified that the
gateway has an additional feature, i.e. gateway coordination Server itself is not part of the WSN, but is used to access
and the sensor nodes have the tasking middleware and interact with the WSN. The Server resides outside the
employed. WSN and communicates with the MGWs, in order to
expose data gathered by the WSN to high-level
A gateway essentially is a network-bridging device,
applications. The Server has nevertheless the functionality
which connects the WSN to the Intranet/enterprise network.
for the tasking middleware, in order to be able to instruct
In that sense, it does not participate in the tasking of
the sensor nodes (that also have this functionality) on data
sensors; it rather relays data from the WSN to the enterprise
collection and reporting as per the client requests. A back-
network and vice versa. To ensure scalability and reliability
up Server has also been considered for stability and
of the WSN we consider that there might be the need to
reliability reasons (so as for the Server not to constitute a
have more than one gateway for a single WSN, since for
single point of failure).
example the number of nodes could rise significantly or the
main gateway could potentially fail. Another reason is to

IJSSST, Vol. 11, No. 3 16 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

The tasking middleware is the architectural entity that / (ROOT)

implements the functionality exposed by the WSN service DomainTask
interface. It is actually client-server architecture with the
{DomainTaskId}
client side residing on sensor nodes and the server side
existing on the Server. The tasking middleware receives as

DomainTaskResult

input high-level service requests (known as WSN queries) {DomainTaskResultId}
from enterprise entities via the enterprise middleware, i.e.


SensorTask
WSN WS interface, determines at the Server what data and SensorTask

processing are required to provide the service, tasks the {SensorTaskId}
relevant sensor nodes to perform sensing and processing
SensorTaskResult
(known as sensor tasks), collects the resulting data at the
sensor node, sends the data back to the Server where it {SensorTaskResultId}

might be contextually processed and stored it in a database Sensor
for keeping records and finally responds to the original Sensor

service request. {SensorId}

{SensorResult

IV. WSN ARCHITECTURE SPECIFICATION {SensorResultId}
Space

The WSN service interface is exposed in an overall {SpaceId}
SOA. We used web services service model because of its
Sensor
wide-acceptance and the fact that they enable easy and
straightforward deployment of applications over enterprise Figure 9: WSN Web Service URI hierarchy.
networks and the Internet in general, as required by our It has to be clarified that the WS interfaces reside on a
architecture and are supported by well-established Web Server and will be registered to a Service Registry to
standards. WS constitute a means for various software enable their discovery by clients. The actual functionality
platforms to interoperate, without any prerequisite behind the WS interface is implemented by the Server
regarding platforms and frameworks homogeneity being entity, which was discussed previously. It is at the Server
necessary. where the required processing takes place, prior to the
WSN environment is essentially a collection of tasking of the WSN to collect data. The MGW and SGW
resources (i.e. sensors) that continuously monitor their entities serve as network bridging devices between the
environment (i.e. get measurements). We have therefore WSN and the Server.
defined a REST-based (REpresentational State Transfer) Clients have access only to the DomainTask resource
style SOA to enable integration of the WSN with enterprise exposed through the WSN WS interface and the other
services. REST-based WS [14] lack the complexity of resources are used internally by the WSN architecture,
SOAP-based WS [15] and form an open and flexible namely the Server. The DomainTask represents a high level
framework, allowing scalable and dynamic resource tasking of the WSN that is described in terms that are more
monitoring [16], [17]. familiar to the building management domain than the WSN
The WSN Web Services are rooted at the following domain. It is the job of the Server of the WSN architecture
base URI: http://{hostname}/REST/{version}/. The to take a DomainTask as input and translate this into one or
{hostname} parameter must be replaced with the name of more SensorTasks that can deliver the data required to
the server hosting the WS, and the {version} parameter fulfill a DomainTask. The SensorTask resource is a lower
must be replaced with the version number of the service. level tasking of the WSN that is specified in terms that are
When a client wishes to interact with the WSN architecture familiar to this domain. SensorTasks can cause one or more
over the SOA, the client issues the appropriate HTTP Sensors to be configured to deliver data. The SensorTask
method, namely GET (to query an existing resource), POST may perform processing and aggregation of data received
(to create a new resource), DELETE (to remove an existing from Sensors before data delivery. The base SensorTask
resource), PUT (to update an existing resource). The WS type is abstract, with specializations existing to describe
URI hierarchy for the proposed WSN architecture is periodic data collection tasks and conditional, or alarm
illustrated in Figure 9. For example when a client wishes to based, data collection tasks. Each SensorTask is assigned to
retrieve the results from a particular DomainTask resource, a sensor node of the WSN architecture. The sensor nodes
then he/she issues an HTTP GET request to the URI report data back to the Server via their respective gateway.
http://{hostname}/REST/{version}/DomaintaskResult/id The sensor resource represents a sensing component of
where id is the unique identifier of that result and the the WSN. It provides a mechanism for getting information
corresponding data is returned using an XML about the capabilities of the sensors that comprise the
representation. WSN, including sensor type, position, and power status.
The Space resource represents a textual description of a

IJSSST, Vol. 11, No. 3 17 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

space, i.e. a zone, of the building environment, e.g. a room, collected data is stored in a database and used by higher
a block, etc. level processing, which may involve specialized processing
The format of the resource representations used by the may employ the full power of computational languages.
WSN architecture has been formally described in [18].
Resource representations are used both by clients when A. Data Processing and Inference Rules
sending a request to a Server, and by Server when returning
a response to a client. The data model is formally specified The overall architecture for the data processing and
using an appropriate XML Schema Definition; further policy formulation part is shown in Figure 12.
details can be found in [18].
S en sor y Ae
l rt s
s to ra ge S en sor y

V. DEPLOYMENT OF WSN ARCHITECTURE

d at a A ct o
i ns

D eci sio ns

Po l i ci e s
Zone 1 I f f or a gi ve n bui l di ng spa ce
i nt h e al st 3 m i nu te s th e sm ok e
Gateway l eve l si i ncr e asi ng a nd gr e at er
t han 0 .7 5
Zone 3 a nd
i nt h e a
l st 3 m i nu te s th e
Gateway t em p er at ur e i so ve r 35 d eg re es
an d ni cr eas n
i g
Server t h en r ai se a n al ar m and s end a
Zone 2 &3: Offices
Zone 2
Zone 3

si gna l t o t he f ri e br i ga des
Zone 2
Gateway Zone 3
Zo

Gateway
ne

Figure 12: Data processing and policy Architecture.

1:
O
pe
n
Ar
ea

Data collected from the WSN are stored in an

intermediate database from where they are retrieved and
Temperature, further processed. Policies (sets of rules) can be formulated
humidity, light
N
for how the data are to be interpreted, treated, correlated,
CO2 + Presence and what conclusions can be drawn from them. Moreover,
actions can be specified to be taken when certain conditions
(on the collected WSN data) are met. In general
Figure 10: WSN deployment in a building.
conclusions can be expressed as the result of inference rules
A user interface was developed where authorized users that have the form:
can task sensors and query for displaying the historical or P0 P1 Pn
current sensed data. Figure 11 shows this user interface.
C (1)
where Pis are the premises and C is the conclusion. By
using the same approach, higher levels of context
awareness for the building spaces that are monitored by the
WSN can thus be built up by formulating inference rules
hierarchically. The axioms (facts) of these inductive
definitions are the values collected by the WSN. As
mentioned above, we allow C to have operational
components, i.e., contain actions that may influence the
environment. For example, as the figure shows, a rule like:

Figure 11: UI for tasking & visualizing sensor data. if for a given building space
in the last 3 minutes the smoke level keeps
increasing and is over the value 0.75
and
VI. CONTEXT AWARENESS in the last 3 minutes the temperature is over 35
degrees and increasing
The previous sections presented the overall architecture of then
the WSN that collects building data and its interfacing with
conclude that there is fire
the rest of the enterprise middleware. This section focuses
on the processing of data that is collected from the WSN and
and in particular on how rule-sets and policies can be ring an alarm
formulated over the collected data and used for extracting and
useful information and developing the required level of send a signal to fire brigades
situational awareness for the building spaces. The extracted
information from the low level processing of the raw

IJSSST, Vol. 11, No. 3 18 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

This can be expressed to set the fire detection and The architecture shown in Figure 12 allows a level of
reaction policy for the building. In an actual deployment the indirection between the values coming from the WSN and
WSN motes (fire detectors and temperature detectors) will the rule engine. The WSN values are stored in an
send their measurements over standardized interfaces from intermediate database as they are collected from the base
where they will be collected for further processing. station of the WSN. In the sequel they are retrieved from
Nevertheless the formulation of rules is flexible and the database and are fed as facts to the rule engine, which
abstract enough to accommodate diverse sets of devices. applies the specified policies to them, makes whatever
Policies are expressed in a high level form that should conclusions are specified and possibly takes the
be understandable to non-technical users. Figure 12 shows a corresponding actions. The schema of the database used in
rule engine that applies the formulated rules to the the current prototype development is shown in Figure 13.
incoming data from the WSN. The high level rules are The schema specifies the minimal information that is
automatically translated to low level instructions for the required from the WSN so as the rule formulator can be
rule engine that monitors the data coming from the WSN used. The prototype implementation of the rule formulator
and makes the specified conclusions or takes the specified adjusts itself to the database schema as it automatically
actions when the rule conditions are met (the rule is fired). constructs the dropdown boxes and other pieces of
As mentioned in the previous section, most of the data information that presents to its user.
collected from the nodes of the WSN that are dispersed in a
building are mainly environmental (e.g., temperature,
humidity, smoke, etc.) but the presented architecture and
prototype implementation are not constrained by the nature
of the collected data. This implies that if a completely
different kind of data is sensed the same architecture and
prototype will be usable as well. The rule (policy)
conditions are predicates over the WSN data and are
specified by the following grammar:
rule : rterm [over time-duration] mote-group
rterm : rfactor | rterm blop rfactor
blop: and | or
rfactor: named-rule
| sensor-value relop constant Figure 13: DB Schema for intermediate WSN storage data.
| increasing sensor-value
| average sensor-value
| ( rterm )
| not rfactor
relop: < | <= | > | >= | == | !=
constant: integer-literal
time-duration: integer-literal time-unit
time-unit: msec | sec | min | h
mote-group: Any-mote | Same-mote | Same-group
The grammar specifies the permissible rules as
relational terms (rterm) followed by a duration specification
and a mote-grouping specification. A mote group is a
collection of WSN motes at a certain building space, zone,
etc. For example, a mote group may be defined for the
building spaces where the accounting or the inventory
departments are. Rules can then be expressed pertaining to Figure 14: Rule Formulator.
a mote group. A relational term is a sequence of
conjunctions and disjunctions of factors. Rules can be given Figure 14 shows a screenshot of the rule formulator
names and factors can be either named rules, comparisons window. The window comprises three parts:
of sensor values to a constant, statistic functions over values The rule formulator allows rules to be edited (by
monitored by a sensor node, or application of a unary pressing the green button new options for formulating
operator to a factor. disjunctions and conjunctions appear).
Rules can be edited over a web interface, stored to a The rule importer/exporter is used to store the currently
permanent store at the local machine of the user and edited ruleset to an XML file or read a previously stored
retrieved later. Once a ruleset has been defined it can be ruleset and merge it with the currently edited ruleset.
deployed to the underlying rule engine. The prototype Rules can be imported by pressing the Import Rules
implementation makes use of the DROOLS [19] engine that
runs under JBOSS [20].

IJSSST, Vol. 11, No. 3 19 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

button and exported to an XML file by pressing the Figure 15. The exported XML format can then be saved to a
Export Rules button file of the local filesystem. Rules that have been previously
The rule deployer is used to send the current ruleset to exported can be imported by specifying the file that
the rule engine (DROOLS). Rule deployment is done by contains them and pressing the Import Rules button.
pressing the Deploy Rules button. A new drl file is If a ruleset is imported while there is a working set, the
built and deployed on DROOLS. As new rules are sent imported rules are merged with the existing ones. The
to the engine, they become effective along with the ones current ruleset can be deleted by pressing the Clear Rules
the engine currently works with. If this is not desirable, button. As mentioned before, the rules that are formulated
the working ruleset of the engine can be cleared by with the editor can be deployed to DROOLS. For this, they
pressing the Clean Up Engine button. are first automatically translated to the language of
DROOLS (a drl file is generated) and they are shipped to
the engine.

Figure 15: Rule Formulation.

Figure 16: XML dump of an exported ruleset.
The rule formulator is the heart of the user interface.

Figure 15 shows a screenshot of formulating rules on WSN An interesting property of the rule formulator is that it
monitored values. Any of expresses disjunctions. The allows conclusions to be drawn and automatically be used
sample ruleset of for drawing higher level ones. The Then part of the rule
allows a new conclusion to be named as shown in
Figure 15 expresses the following algorithm:
If there is a Humidity value of 70 Figure 17.
and there is increasing values of Temperature over
the last 10 minutes coming from the same group
of WSN motes
then Perform some other action
Time units allowed range from milliseconds to hours.
Even though current WSN technologies may not support
data transmission at the millisecond level, this unit is
maintained for allowing the engine to be used with other
kinds of data as well or future advancements in the
technology.
At the moment, the prototype provides a number of
sample actions (Some Action, Some Other Action and Yet
Another Action) for demonstration purposes. Each action is
represented by a class. For every new action, a class should Figure 17: Making conclusions.
be created to extend org.i3con.wsn.rules. Action abstract
class, while its behavior is specified by perform method.
Rules that have been edited can be exported to a file. The conclusion AC leak is drawn and can then be
used in the When part of subsequent rules. In addition,
Figure 16 shows an XML dump of the exported ruleset that actions for how to treat the conclusions can be specified.
was formulated in Since actions are implemented as objects both the push and

IJSSST, Vol. 11, No. 3 20 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

the pull models for information propagation are supported. the device has a built-in vibrator (smart phone) it can
With the pull model, actions insert the newly drawn be used to draw users attention to device.
conclusion to the database. In this manner contextual Audio User Interface (AUI):
information that is dynamically collected from the WSN The Loquendo [11] Automatic Speech Recognition
becomes readily available to the database for other higher (ASR) engine is used issuing audio commands and
level applications to use. With the push model, actions send Text-to-Speech (TTS) synthesis for communicating
the newly drawn conclusions to interested client information to the user. AUI is used in scenarios where
applications for use. Overall, the situational awareness of the users visual attention has to be directed elsewhere
the system is enriched as time passes and the collected (moving, attending to other tasks) or the hands-free
information is communicated to other parts of the I3CON operation is required/preferred. The AUI may also be
architecture for use. Hence client applications can use the used to speed-up searches for the content as on mobile
knowledge, incrementally built for their purposes. devices text input is inconvenient.
RFID based location awareness:
VII. MULTIMODAL USER INTERFACES Proprietary wireless positioning system was developed
for positioning users against active RFID tags attached
In the context of the I3CON project, the Multimodal to building components stored in the Building
User Interface (MMUI) were envisaged to facilitate Management System (BMS). Having established user
interaction of operation service personnel (OSP) with the location information relevant to his location may be
Generic Object Browser (GOB) who accesses static pre-fetched from the BSM and shown to users (maps,
building data and dynamic data from sensor networks. Our sensor info etc). Furthermore active 2.4GHz RFID
main goal was to integrate speech recognition and synthesis based precise positioning has been implemented
engine into the GUI of the application and in this way allowing pin-pointing user in the building offering
greatly facilitate and enrich the user interaction with the similar performance as Wi-Fi based technologies,
application. Latest generation of speech recognition however at a considerably lower cost than its Wi-Fi
systems designed for mobile platforms provided user alternative.
independent and open vocabulary recognition as well as
Context awareness:
dynamic vocabulary creation, making them well-suited for
Provision of information is based on the context of user
this task.
operation, criticality of information (warnings or
By building upon standard GUI model, utilizing the excess sensor values etc).
paradigm of observer and command patterns, it was
Hands-free operation:
possible to extend the functionality of user interface
In addition to employing audio control interface and
components to provide auditory information to the user as
RFID/context program adaptation we replaced standard
well as react to the user commands. For this task we plan to
mouse, keyboard and/or touch screen with head-on display
use a third-party speech engine that provides an API, and
and free-air (gyro) manipulator allowing maximum comfort
integrate it with the rest of the application and GUI logic.
of service operation.
We also looked into novel research on automatically
generated graphical user interfaces, where look and feel of
the interface is adapted to either the users reduced VIII. RFID POSITIONING SYSTEM
dexterity, due for example to the use of glows, or reduced
visibility due to bad light conditions. We aimed to
Although a number of indoor positioning technologies
implement a variety of user modalities as listed below.
are in existence (UWB, Wi-Fi, Bluetooth, mobile-based
Graphic User Interface (GUI): etc), they face adoption problems due to cost (e.g. UWB),
Output is to graphic device display and the user input is performance and cost (e.g. WiFi. Bluetooth) and
captured either by text input (hardware keyboard, on- performance (e.g. Mobile based). In I3CON, since location
screen keyboard (SIP) or handwriting recognition) or of the user is as important as the identification of the
using the touch-screen or touch-pad to simulate point- construction component, the RFID has been considered to
and-click functionality of standard mouse and address both needs. RFIDs are a commonly available
keyboard UI. system which uses either low-cost passive Radio tags
Hardware buttons / keys on the device: (LF/HF/UHF), or higher cost active tags. The passive RFID
Under some circumstances hardware keys are much reader transmits a low-power radio signal that the tag
easier to use than the graphic controls/touch screen. receives and uses to power its integrated circuit. This allows
They are few in number (four direction keys, one it to briefly converse with the reader for verification and
select/enter key and two to six special keys usually exchange of data.
used to launch common applications and start Once that data is received by a reader it is sent for
audio/video recording) and easily distinguishable processing. In contrast active RFID tags embed own battery
without looking at the device. This is basically one- allowing them to communicate over larger distances than
way interface, for the user input only. In cases where passive ones.

IJSSST, Vol. 11, No. 3 21 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

In Table I and Table II weve shown an overview of

RFID technologies indicating the performance and specific
applications for each of them. In our system we employed
active Wi-Fi tags for user positioning and identification of
TABLE II. RFID REVIEW BY FREQUENCY RANGE [6]
core building components and 13.56MHz passive tags for
marking other building elements. Low High
Ultrahigh
Frequency Frequency
Passive 13.56MHz tags have been developed with (LF) (HF)
Frequency(UHF)
cost effectiveness in mind. Typical Tag costs range from 50 FrequencyRange 30300KHz 3MHz30MHz 300MHz3GHz
cents to $1 unpackaged. Tag prices can dip to the 20 cent Passive:
level if custom EEPROM silicon can be committed to by 860960MHz
the user. Read ranges are typically 10cm for RFIDFrequency RTLS:
125KHz 13.56MHz
ISO/IEC14443A/B and up to 1.5m range for ISO 15693 (to (typical) 433MHz
150cm range). Metal poses a serious source of interference 2.4GHz
and loss of performance. Mounting Tags on metal can be >3GHz(SHF)
very challenging. Wavelength 2000m 20m 35cm
ReadRate
Active RFID tags unlike passive ones have their own (typical)
10tags/sec 100tags/sec 5001500tags/sec
internal power source, which is used to power the Passive:
integrated circuits and to broadcast the response signal ReadRange Passive: Passive: 10m
to the reader. Communications from active tags to (typical) 10100cm 1030cm Active:
readers is typically much more reliable (i.e. fewer >100m
errors) than those from passive tags due to the ability for DataStorage
48bits 100bits 100+bits
active tags to conduct a "session" with a reader. Capacity
MaterialsNot Aqueousfluids
Active tags, due to their onboard power supply, also EasilyRead
N/A N/A
metal
may transmit at higher power levels than passive tags, Ignition
allowing them to be more robust in "RF challenged" Typical control Smartcards Assettracking
environments with humidity and spray or with RF- Applications Animal Accesscontrol Cargotracking
dampening targets (including humans and cattle, which tracking
contain mostly water), reflective targets from metal Passive:
(shipping containers, vehicles), or at longer distances. In ISO180006C
Passive:
MostCommonAir (EPCC1G2)
turn, active tags are generally bigger (due to battery size) Interface
Passive: ISO180003
Active:
and more expensive to manufacture (due to price of the Standards
ISO180002 ISO14443
IEEE802.11
battery). However, their potential shelf life is comparable, ISO15693
IEEE802.15.4
as battery self-discharge competes with corrosion of ANSI371
laminated PCB.
Many active tags today have operational ranges of
TABLE I. RFID TAG TECHNOLOGY OVERVIEW [5] hundreds of meters, and a battery life of up to 10 years.
Passive Semipassive Active Active tags may include larger memories than passive tags,
and may include the ability to store additional information
LF:125KHz
HF:
received from the reader. Special active RFID tags may
MostCommon
13.56MHz 860960MHz
433MHz include specialized sensors. From the 13.56MHz
Frequencies
UHF:
2.4GHz technology that exhibits almost no communication when
860~960MHz placing tags on metal, additional RFID magnetic shields
Lowest: can be applied increasing the read range (placed on metal)
>100m
ReadRange
10cm,HF
100m >1000m
from almost zero to 30% (RFN1) or 60% (RFN4) free
Highest:
andabove space range [10].
10m,UHF
DataStorageCapacity 60kilobits 60kilobits
100200bits
(UHF) orhigher orhigher A. positioning using RFID Tags
>5years 15years 15years
Life
(nobattery) (battery) (battery) RFID Positioning System estimates the position of a
Sensor target in observation area. The target node is an RFID
No Optional Optional
Integration
reader (held by the user walking in the area) that receives
TypicalCostPerTag
(UHF)
$.10$20 $1$30 $10$100 signals from a number of active RFID tags placed in the
Carcontrol Assettrack Asset/personnel
vicinity of the reader. When the RFID reader receives a
CommonApplications Tracking Vehicle tracking/safety signal from a tag it outputs a data packet on its serial port.
SmartCards tolling Cargotracking This data contains, among other info, the ID of the tag and
the indication of strength of the received signal (RSSI).

IJSSST, Vol. 11, No. 3 22 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

Following points regarding the localization system must Any method for estimating location requires as input
also be taken into account. the complete set of data at any given time. In our case the
positioning system would need to know the signal strengths
for all tags in the vicinity at the time it estimates the
B. Tag placement distance. But, as the tags emit in intervals of 800ms or
1500ms with frequent clashing, a way to interpolate data
We assume that all tags have already been deployed for tags that have not been heard from is needed. This
and that they do not move. Positioning system, running on interpolation is done by recording measurements from tags
the mobile device, is assumed to know the positions of all for a certain time frame (in a range of few seconds) and
tags in the area. The tags are ideally placed in such a way taking the largest value. The largest value is chosen having
that there is an unobstructed line of sight between them and in mind that obstacles appearing on the signal path (people,
the reader and that their distribution is even within the columns, etc) could only introduce loss to the signal
whole 2D observed area. Collinear placement of all tags strength. This is not true in case of reflections and multipath
should be strictly avoided. reception.
More research is planned to determine whether the
maximum, average or median values are optimal choice.
C. Orientation of tags and reader The length of this time is again a matter of a trade-off.
Longer time would ascertain that signals from more tags are
The choice of orientation of tags and of the reader received which would increase the accuracy of the
should minimize the effects of anisotropic gain of their estimation, but it would at the same time introduce larger
antennas. This is important as the multilateration method errors when the target is moving. In our test-runs of the
assumes that the variation in signal strength is only due to system we concluded that the time length should be
the variation of distance between the reader and the tag, between 1.5 and 3 seconds. It would be possible to use
whereas in case those antennas are directional the signal adaptive time length shorter time when target is moving
strength depends not only on distance, on relative angular and longer time when the target is stationary, which is
position of reader and tag. determined by the accelerometer.

F. Position estimation

We use a maximum-likelihood (ML) estimation to

estimate the position of a target by minimizing the
differences between the measured and estimated distances.
ML estimation of a targets position can be obtained using
(a) (b) the minimum mean square error (MMSE) [5], [8], which
Figure 18: Active RFID Tag TG501 (a) & reader RX300 (b) can resolve the position from data that includes errors. We
explain the calculation for a two-dimensional case as
follows. MMSE needs three or more tags to resolve a
D. Number of tags
targets position. In the case that only one tag is detected
within a time window its coordinates are assumed to be the
Due to the fact that all tags transmit at the same
coordinates of the target, and in the case that only two tags
frequency, the effect of clashing between tags may result in
are detected within a time window target coordinates are
long intervals between receiving signals from some of the
calculated as an average of tags coordinates weighted by
tags. Tags we were using implement a simple method for
respective signal strength.
reducing effects of clashing: The exact time of transmitting
varies randomly in a range of 10% of the transmitting
period. This prevents tags from continuously clashing with G. The positioning algorithm
each other, but does little to prevent single instances of
clashing. A trade-off between this effect and the benefits Our known variables are:
from having as many tags as possible in the vicinity of the
n, (n3) Number of tags detected
reader has to be found experimentally. Our results based on
empirical study show that desirable results may be obtained (x02+y02) Unknown coordinates of the target
by placing tags in such a way that the reader is within a di , i 1,2,..., n Measured distances between the
range of 10 to 15 tags at any one time. The actual ith tag and the target obtained by interpolation from RSSI
placement of tags will vary from location to location due to values Curve Fitting Tool from Matlab.
the spatial constraints of the venue.
The differences between measured and estimated distances
are then defined by
E. Data collection x1 x0 2 y1 y0 2 d12

IJSSST, Vol. 11, No. 3 23 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

x2 x0 2 y2 y0 2 d 22 (2)
covered by the user carrying the target (reader) moving at
some realistic velocity between the two measurement
instances. The distance between the estimated position and
xn x0 2 y n y0 2 d n2 the previous estimated position is compared to the product
of measurement interval and maximum velocity of the user.
kth equation from the set (1) can be expressed as: In case that the obtained distance is smaller, the values are
updated and we go on. In case it is larger, we have an
x02 y02 d k2 xk2 yk2 2 xk x0 2 yk y0 outlier and we set the new position to be the same as the
(3) previous one. In case this happens three times
Using (3) we can eliminate (x02+y02) terms by subtracting consecutively, we once skip setting new estimated value to
kth equation from other ones: previous one.

2 xk x1 x0 2 yk y1 y0 d12 d k2 xk2 x12 yk2 y12

IX. GENERIC OBJECT BROWSER
(4) Generic Object Browser is a software component that is
2 xk xn x0 2 yk yn y0 d d x x y y
2 2 2 2 2 2 used to browse dynamic real time objects from building
n k k n k n
automation systems as well as static building product data
Leading to (4) that can be expressed in a matrix form: objects. Stationary and mobile implementations are
considered, allowing accessibility of the building data from
2 xk x1 2 yk y1 d 2 d k2 xk2 x12 yk2 y12 a wide range of stationary (PC) as well as mobile devices
x0 1
(real & small) devices; capable to interface with the object
y0 2
2
k x x 2 y y
n
n
d d 2
x 2
x 2
y 2
y n
2
database and specializations for interacting with specific
n k k k n k (5)
components. Generic Object browser was to act as front-
or AX=B. end for accessing BSM and be solely based on exploiting
Web services access to BSM. Object browser was expected
Then Eq. (5) can be expressed as to work on standard commercial version of windows based
2 xk x1 2 yk y1 d 2 d k2 xk2 x12 yk2 y12 terminals. That meant there are no extra requirements for
x0 1 processor speed, memory, HD space, network capacity etc.

y0 2
2 xk xn 2 yk yn d n d k xk xn yk yn
2 2 2 2 2
(6)
A. Architecture
or AX=B1+B2. The solution of (6) is:
X A 1B1 A 1B 2 The architecture of the system incorporating
positioning service and mobile browser, encapsulating three
Where A-1B1 is the error term: modules related to multi-modal user interface modalities
(speech, hardware buttons and touch-screen) are shown in
2 x x1 2 y k y1
1
d 12 d k2 Figure 19. The latter ones are managed by the UI controller
x0 k (7) unit which resolves eventual ambiguities in user input. On
y mobile devices (Smartphone, PDA, UMPC or Notebook),
2 x k x n 2 y k y n
0
d n d k
2 2
the GOB jointly with positioning and personalization and
adaptation components, augment the capabilities of the
It can be seen from (7) that the choice of k, the index of
multimodal UI that provides the Ambient User Interface to
equation from the set (2), puts that particular tag in a
the Building Operational Service.
privileged position as the errors in estimating its distance
from the reader appear in all other equations. This means
that the tag used for elimination should be the one for
which we are most likely to get a best estimation of
distance. In our implementation we are using the data form
a tag with strongest signal to perform the elimination as this
is most likely the closest tag with no interference and where
multipath reception is of least influence.

H. Additional constraints

To further eliminate measurements with large errors

(outliers) to which the MMSE is very sensitive, we have
introduced a constraint that the estimated position could not
be farther from the previous one than the actual distance

IJSSST, Vol. 11, No. 3 24 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

intersect at the exact location of the reader. The dark blue

circle is the estimated position, whereas the actual position
was just above it, in between the estimated position and the
tag 1131. Numbers below tags represent tagID (pink) and
RSSI (blue). In this configuration we have achieved
positioning errors below 2 metres for moving target at
moderate walking speed.

X. MOBILE SYSTEM

A composition of the mobile system is shown in

Figure 20. It is composed of the PDA device running
Mobile 6.1 running WEB services from the I3CON server:
environmental sensor data from WSN by Thales
Communications (UK), BIM data by LONIX and access to
Figure 19 Ambient UI Architecture dynamic data from Building System Manager (BSM) by
The positioning system is based on reading active VTT. Active Wi-Fi RFID tags deployed in the environment
RFID tags that are in proximity of the user holding the provide both necessary signaling for determining the
mobile device and determining the position of the device position of the user in the building.
relative to the tags. As the locations of tags are available
from the building data repository via the BSG, the location GH
z

of the user in the building can be determined. The same Wi-Fi

2.4 RFIT Active 2.4GHz
Temperature & Humidity
Sensor Tags Pro (T40028 )

system (based on RFID tags) will be used to easily identify 2.4GHz RFID Active 2.4GHz Long

parts of the building equipment (HVAC, lighting, etc).

Range Pro tags (T40019 )

Bluetooth
Active
2.4GHz
I3CON Server
RFID

2,4GHz
reader

Headset
B. Positioning system
2.4

Hz
GH

2,4G
z

Wi-Fi

For testing and demonstration of positioning system we 2.4G

Hz
3.5mm audio jack (optional)

have deployed 10 RFID tags at the ground floor of

Intracom Telecom building A2 with distances between tags
HTC Video Cable

in range of 3-5 meters (see Figure 19). In order to minimize HTC 7510 Advantage

interference of the body of the person carrying the reader 3D Gyro-mouse (RF)

and other people in the area, as well as to minimize the Micro Optical SV -6 Display

influence of the directivity of tags antennae, the tags were Figure 20: Mobile System Architecture
placed on the ceiling, as far as possible from any metal
parts of the construction. This unfortunately introduces a
systemic error in estimation, as when the reader is exactly By offering long range (over 100m in free space) they
under the tag it is actually about 1.5 meters from it, but this provide a cost effective wireless positioning infrastructure.
has much less detrimental influence than placing the tags at Having those tags attached to principal building systems
the receiver height. (e.g. HVACS etc), those tags can be used for fast access to
BIM data about these components when in specific
proximity. Additional tags with environmental sensors
(temperature and humidity) can be also used for integration
with HVAC control systems.
Smaller passive tags can also be deployed that upon
scanning (proximity of less than 13cm) would allow direct
access to BIM and GSG data about systems to which they
are attached. Note that both types of tags can be read using
the same reader (Bluetooth RFID 2.4GHz Reader R410031
from InfoTek). Hands-free operation was achieved by using
monocular display SV-6 from Micro-Optical that can be
mounted on glasses and 3D gyro mouse. This was
Figure 19: Screenshot of the test-bed application
supported by SW interfaces employing speech recognition
for voice controls, speech synthesis for alerts and messages
The circles around the active tags have radii and context-awareness, location-awareness and proximity
corresponding to interpolated distances and should ideally detection for access to most important information. If

IJSSST, Vol. 11, No. 3 25 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

needed, classical touch screen / keyboard / mouse operation XXI century such as parking, environmental services, etc.
is offered allowing access to other types of information The goal was therefore to integrate the strong demand of
stored in the BSM, e.g. documents etc. residential surface with complementary, industrial type or
municipal services, which are necessary activities for the
life of the district. Following that path the new building
XI. TERMINAL ADAPTATION integrated three uses clearly differentiated:
Assisted living for young people
In order to adapt the core positioning and browser
Parking for residents
services to the target terminal characteristics, a terminal
Facilities that hold municipal cleaning services
adaptation technology was developed aimed to offer the
same experience irrespective of terminal characteristics, Each one of the specific uses shows a series of own
capabilities and operating interfaces, namely: necessities that define the types and the amount of relation
that are possible between them.
Content Adaptation to Terminal Capabilities:
Aimed to downscale or transcode the content to fit to
device specific capabilities, e.g. high resolution images
are downsized to display capabilities of the terminal.
The format of the content is also important to match
device decoding capabilities (especially for the video).
Content adaptation demands a lot of resources and as
such is typically done off line, not in real time. This
requires content pre-transcoded and stored on the server,
while an appropriate indexing mechanism that takes into
account the specificities of the device used should be in
place for retrieving appropriate content.
Content Layout Adaptation to Terminal Display:
Capability of the application to exploit fully display
capabilities of the client terminal by making appropriate
adjustments (resizing, scaling etc) of the application
user interface to fit the device capabilities. Frameworks
have been developed for automating targeting to a
variety of devices that were exploited in the context of
I3CON.
Terminal Adaptation to Network Transports:
Figure 21: Cross-section of the Margarita building.
Allows seamless use of one or more network adapters
(GPRS, EDGE, UMTS, HSDPA, Wi-Fi, USB The real life demonstrators have been conceived in the
networking etc) optimized in terms of cost or required Margarita building (Figure 21) in order to put into practice
data throughput, local availability, even using multiple the RTD results of the ICON project. As part of this
interfaces at the same time when higher bandwidths are demonstration a Building Management System including
required. the Wireless Sensor Network has been deployed and tested
The focus of the work is more on the second point. by the residents of the building.
Content adaptation has been widely addressed in the
research community and there are lots of techniques for
downgrading or transcending content. To this extent we
assume that content is available in the appropriate formats,
resolutions, and qualities, for the devices on which it is to
be displayed and can be indexed, given the specific
devices display characteristics.

XII. TEST DEPLOYMENT AT MARGARITA

BUILDING

Madrid's downtown is an area that accuses an important Figure 22: The structure of the BMS.
deficit of dowries and public facilities. The revitalization
programs in the city centre need to be effective and The system provided information for users through the
complementary to the residential use and solve some of the Info Display. Displayed information contained electricity
existing problems to keep the city fully operative in the consumption, cold water consumption, hot water

IJSSST, Vol. 11, No. 3 26 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

consumption and various measurements from WSN. The o On-demand access to the Building Management
structure and devices for the system are described in System for static and dynamic information.
Figure 22. o Multimodal interfaces employing Speech
As far as demonstration scenarios are concerned the Recognition and Synthesis, context-awareness
aim was to exploit the proposed Integrated Building System related to equipment status, location-awareness and
Architecture together with Wireless Sensor Networks and adaptation to terminal capabilities.
the Mobile Browser in order to develop and present a o Map (raster/CAD) support for self-orientation by
building assessment tool. This was expected to provide a pin-pointing users own position and the location of
measure of improvement of the energy efficiency and relevant equipment queried from the Building
building maintenance efficiency by making use of data Management System.
collected by wireless sensors dispersed throughout the
building and subjecting them to specific assessment criteria.
Building performance indicators were used as these have
been defined in appropriate standards, e.g. ideal XII. CONCLUSIONS AND LESSONS LEARNED
temperature should be between 20 and 25 C, depending on
whether it is winter or summertime. Systems described in this paper have been deployed in
the Margarita building through September 2009 and have
been since used and tested by the tenants. It is expected that
they will be continued until the project end date in October
2010. Until now all systems have been operating
successfully with positive responses from the residents,
although frequent visits were required to service, fine-tune
the system components and resolve usability issues.
In addition to testing of Wireless Sensor Networks and
Building Management System, proof of concept tests were
also performed of the Mobile Productivity Tools including
RFID positioning, location and context awareness as well
Figure 23: LONIX display panel. as multi-modal user interfaces. Due to stringent regulations
governing deployment of prototype systems in residential
Based on the collected data (accessible through the buildings, those components have not been deployed at
IBAC architecture) and energy measurements (via sub- Margarita building and will be demonstrated in the
metering to be further installed in the energy delivery projects mock-up to be constructed by ACS Actividades de
subsystem), an overall assessment of the energy efficiency Construccin y Servicios (Dragados)2, the coordinator.
of the system would be deduced and displayed on a panel
The results of compliance are summarized as follows:
(Figure 23) and/or other user interface. Therefore the
overall grading score of a building or that of particular areas Hardware: RFID technology was proven to be suitable for
within the building related to its energy efficiency is to be signal-strength positioning, especially if Wi-Fi long range
produced to be further utilized by the occupants or the active tags are used that also prove to be a more cost
operators so as to promote energy conservation. effective solution to using Wi-Fi triangulation against
wireless access points. Further improvement can be sought
Furthermore additional technologies were to be tested:
in read accuracy of RSSI by the reader, using
Integration of the Rule Based Engine with Wireless omnidirectional antenna and fixing clashes between tags.
Sensor Network and the Building Management System
Software: further improvements may be achieved through
for the creation of custom actions based on pre-defined
runtime statistical analysis of differences between the
rules with regards to measurements received from the
interpolated distances of the reader from each tag and the
sensors.
distances of the estimated reader position from each tag
Demonstration of the Mobile Browser, a PDA-based allowing detecting outliers after the first estimation and
application for accessing wireless sensors and the then repeating the calculation without them (assuming a
Building Management System featuring: minimum of three tags left).
o RFID precise component localization (passive tags) Multimodal interfaces proved to be an attractive
and positioning system (active tags) for displaying novelty allowing faster and more intuitive access to
both users position and location of selected building information with minimal users control and reduced
components on a CAD map. network delays thanks to advance data fetch when moving
o Automated recognition of RFID-tagged building into a new area.
equipment in the users vicinity for faster and easy
access to relevant information from the BMS
(description, status etc). 2
http://www.dragados.com

IJSSST, Vol. 11, No. 3 27 ISSN: 1473-804x online, 1473-8031 print

 A KRUKOWSKI et al: COMPREHENSIVE BUILDING INFORMATION MANAGEMENT SYSTEM APPROACH

The adopted approach differed from other approaches Network based on ZigBee Standard, Proceeding (538) Wireless
found [12] in the way that the user position, operational Sensor Networks, 2006
context and tagging building components from one side [9] Paolo Magrassi, "A world of smart objects: The role of auto
provide a reference information allowing the hands-free identification technologies, 2001
audio-visual-control User Interface to use them to the [10] http://www.nitta.co.jp/english/product/sheet/rfid/top.html
advantage for reducing the need for software operation, [11] Loquendo ASR/TTS: http://www.loquendo.com/en/
allowing the service personnel to concentrate on the task at [12] V. Papataxiarhis, V. Riga, et al, MNISIKLIS: Indoor Location
hand. The terminal adaptation approach employed Based Services for All chapter from: Location Based Services
correlates also its operability to the availability of physical and Tele Cartography II, From Sensor Fusion to Context Models,
Lecture Notes in Geo-Information & Cartography Series, Springer,
terminal capabilities and range of physical interfaces pp. 263-282, 2009
available (head-on display, free-air UI, head-set, RFID
[13] Stephanidis, C. (Editor) et al, "Toward an Information Society for
reader etc). All: HCI challenges and R&D recommendations". International
This allowed speeding up the access to building Journal of Human-Computer Interaction, vol. 11 (1), pp. 1-28,
databases and maintaining the display of most up-to-date 1999
sensor information. Using location awareness and context [14] Thomas Fielding R T, Architectural Styles and the Design of
awareness options we also decreased the need for manual Network-based Software Architectures, Representational State
Transfer (REST), WEB site:
operation allowing the user to concentrate on other aspects http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.
of the building service maintenance without feeling a htm
burden of dealing with its mobile IT system. [15] W3C SOAP 1.2 Specification from WEB site:
The performance of the RFID positioning was http://www.w3.org/TR/soap12-part1/ (Jan. 2010).
satisfactory, although due to the triangulation against power [16] Pautasso, C., Zimmermann, O. & Leymann, F., RESTful Web
levels on the read from the RFID tags, the position accuracy Services vs. Big Web Services: making the right architectural
was varying depending on the density of obstacles in the decision, Proceedings of the ACM 17th International Conference
on World Wide Web, WWW 2008, Beijing, China, April 2008.
room and people moving around. The fingerprinting
approach that was used to mitigate this problem allowed [17] Landre, W. & Wesenberg, H., REST versus SOAP as
Architectural Style for Web Services, ACM SIGPLAN
decreasing high error variations leading to consistent indoor International Conference on Object-Oriented Programming,
accuracy achieved at a level of around 3 meters. An Systems, Languages and Applications, Canada, Oct. 2007.
important concern was also the autonomy of the system [18] I3CON Project Deliverable: D3.4-1F Reference model and
throughout the service shift. The power consumption of the specification of the sensor networking architecture in the BS
mobile system was considerable, especially for the PDA architecture, Sept. 2007.
that apart from running its application needed to maintain [19] DROOLS: www.jboss.org/drools
Bluetooth communication with mouse and RFID reader, [20] JBOSS: www.jboss.org
wireless communication with the service centre and driving
the external VGA display. Hence it was required to employ
a high power battery pack (3600mAh) instead of a standard
1100mAh battery. This allowed continuous operation in
excess of 4-6 hours depending on the usage.

REFERENCES

[1] COBA: http://www.coba.fi (Jan-2010)

[2] I3CON project Deliverable D6.1-1, Part 1 and Part 2: Margaritas
Implementation
[3] Addendum C to ANSI/ASHRAE Standard 135-2004 BACnet-A
Data Communication Protocol for Building Automation and
Control Networks. 135-2004c-1. Adding BACnet/WS Web
Services Interface: http://www.bacnet.org/Addenda/Add-2004-
135c.pdf
[4] SCADA: http://www.scadaengine.com/
[5] http://www.rfidessentials.net/mod/resource/view.php?id=40
[6] http://www.rfidradio.com/?p=25
[7] A. Savvides, C.-C. Han, and M. B. Strivastava, Dynamic fine-
grained localization in ad-hoc networks of sensors, 7th
International Conference on Mobile Computing and Networking,
166179, 2001
[8] M. Sugano, T. Kawazoe, Y. Ohta, and M. Murata, Indoor
Localization System using RSSI Measurement of Wireless Sensor

IJSSST, Vol. 11, No. 3 28 ISSN: 1473-804x online, 1473-8031 print