![](bg4.png)
be substituted at the server back-end side, without re-
configuring the sensor source at the front-end side.
This kind of system flexibility stands in stark con-
trast to traditional proprietary supervisory control and
data acquisition (SCADA) and BMS systems where
adding or even modifying a few sensory inputs to a
running system requires custom programming by spe-
cialized people resulting in very high end-user costs.
These systems generally assume a static configuration
of wired sensors, which makes them brittle and un-
able to support mobile users with platform-integrated
sensors.
2.2.3 Document-oriented Sensor Database
On the server side, we use a variant of StreamFS (Or-
tiz, 2012) as a universal subscriber to all sensors to
handle sensor data streams and store sensor records
in the sensor database. In our view, key requirements
for the sensor database are high throughput, scalabil-
ity, and some flexibility in data structure. In the cur-
rent implementation, we use MongoDB, a document-
oriented noSQL database (MongoDB, 2011) for sen-
sor data storage.
In document-oriented database, each data record
is stored as a document. In general, document-
oriented databases do not provide transactional ca-
pability with ACID (atomicity, consistency, isolation,
and durability) properties. This results in lower write
and little or no locking overhead, thus resulting in
higher read/write throughput than traditional transac-
tional and relational databases. The tradeoff is lack
of transactional and recovery capability, meaning that
some data records may be lost in case of system
crashes. This is generally not a problem for stream-
ing sensor data due to a large number and relatively
minor significance of individual readings and post-
processing ability to approximate the missing read-
ings in a sequence. In addition, document-oriented
noSQL databases do not require fixed formats and
pre-specified schema. Therefore, new attributes can
be added dynamically without affecting the whole
system. This flexibility allows us to add new sen-
sors and change sensor data format with minimal ef-
fort. Nevertheless, we also use a relational database
to store associations, metadata, and to create analytic
reports for users and system operators. The access-
ing frequency for this database is much lower than
the sensor database.
2.3 Case Study: Eco-Sense Buildings
(ESB)
The initial use case of our platform-integrated sensing
architecture is eco-sense buildings (ESB). The proto-
type and end-user testing target is energy efficiency in
office buildings. Our project goal is to expand the role
of IT to participate in increasing energy efficiency of
office buildings, while improving comfort and safety
of their occupants. We are working with eco-system
partners worldwide towards meeting the most aggres-
sive energy target, net-positive energy buildings (GIE,
2011).
We choose buildings for both their opportunities
and challenges. Buildings are a major energy con-
sumer of energy. Today, buildings consume 42%
of total energy and 72% of electricity (OSC, 2011).
Given the increasing demand on energy and its im-
pacts on the environment, it is critical to achieve en-
ergy efficiency in buildings. Design-time energy op-
timization, while important, is static. To maintain ac-
tual desired operational efficiency throughout a build-
ing lifetime, a process of constant commissioning that
continuously monitors and adjusts the building’s op-
eration and control settings is necessary.
2.3.1 ESB Implementation
In our initial prototype, we focus on leveraging IT
infrastructure to measure personal energy consump-
tion and personal ambient conditions (i.e., tempera-
ture, light, and humidity wherever the user with the
instrumented laptop happens to be). The system in-
cludes sensor DB server, PC clients and other devices.
In the forthcoming end-user deployments, we plan to
use office laptops with built-in ambient sensors. For
initial prototyping, we use an external sensor kit at-
tached to each laptop via an USB port (Figure 2). In
addition to platform-integrated sensors, we also ap-
ply soft sensors and commercial meters to monitor en-
ergy consumption of devices. All sensors and sensor
agents communicate with the database over existing
Ethernet and Wi-Fi infrastructure, thus, simplifying
provisioning and deployment.
For personal power and energy measurement, we
use a combination of custom-made software sensors
and commercial meters. We developed a software
sensor that is installed on a monitored platform. The
software agent accurately estimates the platform en-
ergy consumption (currently PCs and laptops) by
tracking occupancy of computer power states defined
by EnergyStar (EnergyStar, 2011) and ECMA-383
(ECMA-383, 2011), such as short idle, long idle and
sleep. Taking into consideration battery status and
modeling the appropriate power draw, which can in-
crease by a factor of 2 − 3 when the battery charge
is low, provides the added accuracy. This allows us
to eliminate the need for dedicated hardware power
meters to measure PC power draw and energy con-
SENSORNETS2013-2ndInternationalConferenceonSensorNetworks
50