IEEE INTERNET OF THINGS JOURNAL, VOL. 5, NO.
2, APRIL 2018
Context Design and Tracking for IoT-Based
Energy Management in Smart Cities
Carlos A. Kamienski, Member, IEEE, Fabrizio F. Borelli, Gabriela O. Biondi,
Isaac Pinheiro, Ivan D. Zyrianoff, and Marc Jentsch
Abstract—The advent of the Internet of Things (IoT) and its
innumerous applications for Smart Cities emphasizes the need
for context-aware systems able to adapt behavior automatically to
instant environment conditions. Currently, there is a gap in terms
of understanding how context information is interrelated, as well
as tracking which events occurred under which conditions within
certain context scopes. Visualizing, specifying, tracking and mon-
itoring typical contexts involved in IoT-based applications are
still challenging activities since context modeling remains a low
level process that requires much human expertise. In this paper
we propose a new context life cycle that involves context design
and context tracking. We developed a context-aware management
framework, where contexts are modeled as graphs and can be
explicitly designed and their occurrences can be tracked down.
We believe that this feature of designing and tracking context
graphs may help developers, administrators, and end-users in
harnessing the wealth of information generated by highly scalable
IoT systems.
Index Terms—Context-aware management, Internet of
Things (IoT), Smart Cities, smart energy management.
I. I NTRODUCTION
ONTEXT-AWARE systems first appeared in a pre-
C Internet era, where no one imagined that nowadays
they would have a perfect symbiotic relationship with the
Internet of Things (IoT), helping us to make sense out of
the wealth of information generated by different types of sen-
sors. By making systems able to adapt behavior automatically,
context-aware management for IoT has been increasingly used
within the scope of big data analytics [12], [14]. Regardless of
how sensor data and other information are managed, context
needs to be fully understood and carefully considered in IoT-
based applications in order to guarantee an effective, efficient,
and scalable automatic decision-making process. We consider
context-awareness a key component of a middleware aimed
at enabling rapid development of IoT-enabled applications,
mainly for smart energy management [8].
Manuscript received January 31, 2017; revised August 8, 2017; accepted
August 22, 2017. Date of publication September 1, 2017; date of current
version April 10, 2018. This work was supported by the European Commission
and CNPq within the IMPReSS Project under Grant 614100. (Corresponding
author: Carlos A. Kamienski.)
C. A. Kamienski, F. F. Borelli, G. O. Biondi, I. Pinheiro, and
I. D. Zyrianoff are with the Federal University of ABC, Santo André
09210-580, Brazil (e-mail: cak@ufabc.edu.br; fabrizio.borelli@ufabc.edu.br;
gabriela.biondi@ufabc.edu.br; isaac.pinheiro@aluno.ufabc.edu.br;
ivan.zyrianoff@ufabc.edu.br).
M. Jentsch is with Fraunhofer FIT, 53754 Sankt Augustin, Germany
(e-mail: marc.jentsch@fit.fraunhofer.de).
Digital Object Identifier 10.1109/JIOT.2017.2748037
2327-4662 c 2017 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
687
There is currently an unbridged gap related to the under-
standing of the relationship between context entities and of
tracking the occurrence of events in IoT-based applications.
Context modeling remains a low level process that requires
higher levels of human expertise. Visualizing, specifying,
tracking, and monitoring typical contexts involved in IoT-
based applications are still challenging activities. Data man-
agement strategies in IoT-generated big data scenarios require
a deeper understanding of context information and there-
fore we argue that context design and context tracking
are essential activities of a context life cycle for Smart
Cities.
In this paper, we advocate that not only low-level context
modeling for context reasoning purposes is needed, but also
higher-level context modeling can be easily expressed and
understood by humans. Context design is a high-level con-
text modeling approach, where entities and their relationship
are represented as a context graph. It provides three key fea-
tures for an IoT-based application for Smart Cities, such as
smart energy management.
1) Users can explicitly design contexts that were planned
to occur in a given setting.
2) Implicit nonplanned contexts, both wanted and unwanted
ones, can be tracked and expressed in the same model
used on explicitly created contexts.
3) Both explicitly created and implicitly discovered con-
texts can be actively monitored for troubleshooting,
auditing and demonstration purposes.
We developed and deployed a context-aware management
system, where contexts are modeled as graphs, which can
be explicitly designed and whose occurrences can be tracked
down. Our context-aware system for IoT-based applications
for Smart Cities has been implemented, deployed, and tested
for troubleshooting and monitoring purposes, within the scope
of the IMPReSS Platform [9]. Designing and tracking context
graphs may be successfully used in order to help develop-
ers, administrators, and end-users in harnessing the wealth of
information generated by IoT-based applications.
Summarizing, the expected key contributions of this paper
are manifold, focused on the development, experimentation
and evaluation of context design and tracking features for
Smart Cities. We identify the need of a new context life cycle
that captures some higher-level context management needs,
such as context design, monitoring, and tracking, as well as
explicitly identifying context occurrences. Based on that, we
developed the concept of a context graph, where vertices are
688
represented by context entities and the set of edges is repre-
sented by data flow (or control flow) between entities. Context
graphs can be explicitly created in the context design phase
and they can be actively tracked and implicitly discovered by
in the context tracking phase. Whereas the context graph is
the key underlying concept of our approach, its importance is
leveraged when connected to context design and tracking.
In the remainder of this paper, Section II presents back-
ground and related work. Section III introduces our context
life cycle and context graph and Section IV introduces the
context-aware management framework focusing on the context
processing phase. Sections V and VI depict the two key topics
of this paper, which are context design and context tracking,
respectively. In Section VII, we draw the conclusions and paths
to future work.
II. BACKGROUND AND R ELATED W ORK
When fully deployed, the IoT [1] will allow a huge variety
of new services to be available for our society. Making cities
smarter poses many technological challenges for IoT [17], big
data [12], cloud [4] among other technologies, but also pro-
vides opportunities for new applications (verticals), such as
smart energy management [3].
Context-aware systems acquire different types of informa-
tion for reasoning and adapt their behavior without explicit
user intervention [2]–[11]. Currently, with the advent of the
IoT and the innumerous applications in Smart Cities, context-
aware management has been increasingly used within the
scope of big data analytics [12]–[14]. Regardless of how sen-
sor data and other information are managed, context needs
to be fully understood and carefully considered in IoT-based
applications in order to guarantee an effective, efficient, and
scalable decision-making process. We consider context aware-
ness as a key component of a middleware aimed at enabling
agile development of IoT-enabled applications, mainly for
smart energy managing [8].
Due to the fact that context-aware management is not a new
subject and application scenarios evolved substantially in the
last years, we identified the need to modernize some con-
cepts like the context life cycle to keep theory up-to-date
with newer hands-on experience in designing, developing,
deploying, and evaluating related technology to the IoT realm.
Perera et al. [15] proposed a context life cycle management for
IoT composed of four phases: 1) context acquisition; 2) mod-
eling; 3) reasoning; and 4) dissemination. Although useful,
this model is data oriented and does not consider typical man-
agement activities involved in IoT systems. Our context life
cycle captures some higher level context management needs,
such as context design, monitoring, and tracking, as well as
context occurrence as an important entity to be modeled and
whose own life cycle should also be followed.
The key components of any context-aware system are
context modeling and context reasoning. The choice of a con-
text model is a very important step in any context-aware
system because it influences the whole system and also lim-
its the choice of a context reasoning technique. Therefore,
context modeling and reasoning are usually considered as
IEEE INTERNET OF THINGS JOURNAL, VOL. 5, NO. 2, APRIL 2018
a whole for system development purposes. Although ontology-
based modeling and reasoning are very attractive due to high
expressiveness, there are disadvantages enough to make it
impractical for an operational system, where scalability is very
important [11]. A very common approach is using object-
oriented modeling with rule-based reasoning, which usually
are seamlessly integrated in a variety of existing platforms.
One key feature and an important application for Smart
Cities is smart energy management, aiming at achieving
high efficiency by avoiding waste. Particularly in industrial-
ized countries, where buildings account for 40% of energy
usage [16], a challenging problem is how to improve occu-
pant comfort and at the same time reduce energy usage [6].
Byun and Park [5] investigated context awareness for saving
energy. Their system consists of a self-adaptive intelligent
gateway (SIG) and sensors (SIS). SIG provides service pro-
vision based on locations and SIS is used for gathering
information. For instance, when a user with a smartphone
enters a room, SIG is able to send a list of the manageable
devices and their real-time energy consumption. This system
is highly focused and dependent on typical energy saving
mechanisms from the area of wireless sensor networks, such
as efficient energy-based routing. On the contrary, we focus
on a higher-level context modeling approach, which allows
contexts to be actively tracked and monitored.
The IMPReSS systems development platform enables rapid
development of context-aware mixed-criticality IoT-based
applications [9]. IMPReSS offers a variety of components
for facilitating the development of IoT-enabled applications,
which includes a context manager. While in [9] we briefly
described the context manager and introduced some use
cases, here we elaborate on the new concepts underlying
the IMPReSS context-aware management framework, namely,
the context life cycle, the context graph, context design, and
context tracking. Also, in [7] we focused on communication
issues of IMPReSS, but do not elaborate on context-aware
management for IoT.
We consider that our high level context life cycle, the concept
of context modeling as a context graph and the resulting context
design and context tracking features are novel compared to the
current state of the art. Therefore, to the best of our knowledge,
there is no similar context-aware management framework with
those features in the literature thus avoiding direct qualitative
and quantitative comparisons to be conducted.
III. C ONTEXT L IFE C YCLE AND THE C ONTEXT G RAPH
A. Context Life Cycle
Context life cycle management here refers to a higher-
level function-oriented view of context-awareness for IoT,
compared to a lower level data-oriented view introduced by
Perera et al. [15]. Our context life cycle is composed of six
phases, as depicted by Fig. 1.
• Context Design: Context design is a high-level context
modeling approach, where entities and their relation-
ships are represented as a graph. The context designer is
a graphical tool that allows context graphs to be explicitly
specified. The importance of context design is highlighted
KAMIENSKI et al.: CONTEXT DESIGN AND TRACKING FOR IoT-BASED ENERGY MANAGEMENT IN SMART CITIES
Fig. 1. Context life cycle for IoT-based Smart Cities.
in our life cycle because it helps administrators to follow
and understand context occurrences.
• Context Editing: Context entities must be stored in the
context storage in order to be available for context pro-
cessing. Performing [create, read, update, delete (CRUD)
operations on context entities] is a straightforward but
necessary feature. As a matter of fact, context design
can be understood as a special way of editing contexts,
modeled, and visualized as a context graph.
• Context Occurrence: Contexts occur when they undergo
a process that starts with data coming from sen-
sors (resources), being transformed by fusion, firing a rule
for taking a decision that executes actions with commands
for actuators (resources). In other words, contexts occur
when an instance of the related context graph is activated
by data flow. The concept of context provides a more
precise understanding of the dynamics involved in the
process of adapting system behavior.
• Context Processing: Context occurrences are handled
by system components in charge of context process-
ing that include the usual phases of context acquisition
(sensor data gathering), sensor data fusion, context rea-
soning, and dissemination (commands sent to actuators).
In other words, context processing is the result of context
occurrences.
• Context Tracking: When contexts occur and are pro-
cessed, they are logged and leave a trail in the system,
which can be tracked down. For example, a variety of
devices may have their states automatically changed by
a context-aware application and system administrators
must be able to understand what happened. Context track-
ing has two fundamental goals. First, it identifies that
certain contexts explicitly designed occurred in practice.
Second, it identifies contexts that occurred but were not
initially conceived during the design phase.
• Context Monitoring: Contexts are edited and designed,
contexts occur, contexts are processed, contexts are
tracked and finally contexts are stored. In order to
understand what happened in a context-aware system
for performance auditing and troubleshooting activities,
contexts must also be actively monitored.
• Context Storage: Context storage stores data of the con-
text entities, in addition to log information. The latter is
used for many purposes, including context tracking.
689
Fig. 2. Context entities and relationships.
B. Context Entities
We identified six essential entities for modeling typical
IoT-based context-aware management applications: resource
(sensors and actuators), place (buildings, rooms, floors), fusion
(sensor data aggregation), rule (context reasoning), action
(commands to actuators), and context (combination of place,
resource, fusion, rule, and action). Those entities were cho-
sen specifically for smart energy management systems [8].
Other models for different applications might result in slightly
different sets of entities.
Fig. 2 depicts the relationships among these entities.
• Place has Resource: Sensors and actuators are physically
located in places.
• Resource Feeds Fusion: Fusion criteria combines
data coming from sensors.
• Fusion Fires Rule: Rules are fired by fusion criteria.
• Rule Binds to Place: Rules are bound to places, for
ensuring locality of effect.
• Rule Performs Action: When a rule is fired, it performs
one or more actions.
• Action Changes Resource: Actions send commands to
change the state of actuators, thus adapting the application
to current environmental conditions.
• Context Contains Entities: Context contains place,
resource, fusion, rule, and action. Contexts can contain
other contexts in a nested way as indicated by Fig. 2.
C. Context Graph
Context is a container entity, i.e., it comprises a set of
instances of other entities. The use of contexts is important for
modeling and documentation purposes. Contexts model situa-
tions of real life, such as empty building, occupied classroom,
idle elevator, or closed university. Whereas nouns in these
examples are represented by places, verbs need a combination
of other entities to be meaningful. For example, a university
may determine that whenever a classroom is empty, lights must
be switched off and air conditioners (or heaters) must be turned
off. Determining whether a classroom is empty may involve
different presence sensors placed in strategic positions within
a classroom and the values will be averaged. Also, when all
presence sensors indicate that a classroom is empty, a rule will
be fired that in turn executes two actions for switching lights
off and turning air conditioners off.
690
(a)
(b)
Fig. 3. Context graph (a) simple four-step (sensor/fusion/rule/actuator) con-
text graph. (b) Context graph with nested fusions. The anchor represents that
contexts are tied in a place by the rule, which is unique in a context.
Contexts are nonbinding when it comes to the execution
of particular instances of their constituent entities. In practice
a context may occur in unpredictable ways, due to the asyn-
chronous nature of rule-based reasoning and of the randomness
of real world situations.
Contexts are modeled as directed acyclic graphs, where the
set of vertices is represented by entities and the set of edges
is by data flow or control flow among entities. The same con-
text graph can be applied to different places in a process of
instantiation of a generic graph. In that case, the place entity
is used to determine, where that graph is anchored.
Fig. 3 depicts two examples of context graphs.
Fig. 3(a) depicts a simple context graph with the enti-
ties resource, fusion, rule, and action. Raw data measured
by sensors (resource) is fed into an average calculation
process (fusion), whose result is in turn fed into a reasoning
step (rule) that determines whether commands should be
sent to actuators to change their behavior (action). The
Place entity is a different type of vertex with only control
flow information involved, but not data flow. Therefore, it
is represented in a different color and the edge is a dashed
line. The rule entity is “anchored” in the place entity, which
means that since there is only one rule in a context graph, all
other entities are also anchored in that place. A fusion step
may be deemed as a virtual sensor, so that multiple nested
fusions may be connected in sequence, as in Fig. 3(b). This
recursive connection of fusion steps gives us higher flexibility
in modeling the operation of contexts in a real scenario.
Contexts can be self-related, i.e., they can be used as a vir-
tual sensor and nested inside each other, thus helping this
approach to achieve scalability by allowing context reuse. This
is performed by generating an additional output for signaling
the execution of rules in the form of a binary value. Whenever
rules are fired, there is an output value of “1,” and otherwise
the output is “0.” Thus, contexts can make arithmetic and log-
ical (Boolean) operations upon other contexts in the fusion
IEEE INTERNET OF THINGS JOURNAL, VOL. 5, NO. 2, APRIL 2018
Fig. 4. Nested contexts using a context as a virtual sensor: empty floor is
defined based upon three empty room contexts.
step, representing whether they occurred or not. For example,
an empty building context can be created upon a combination
of empty floor 1, empty floor 2, and empty floor n contexts.
In turn, empty floor 1 is also a combination of other contexts,
such as empty room 11, empty room 12, and empty room 1n.
If the purpose is to switch off all lights in a building, one just
needs to activate the context empty building and all contexts
related to it will be automatically activated. In the absence of
this feature, all constituent contexts will have to be activated
individually.
Fig. 4 depicts the feature of nesting contexts and repre-
sents an empty floor context using a logical AND operation.
Different contexts can be defined using empty room, such as
number of occupied room that negates the output of empty
room and sums all values in the fusion step.
D. Explicit and Implicit Context Occurrence
Considering the asynchronous and independent behavior
of entities, contexts can occur in predictable or unpre-
dictable ways. Predictable context occurrences are obviously
the expected and preferred way of dealing with automatic sys-
tem changes. However, since combinations that differ from
the intended prespecified contexts can occur in practice, any
context management system must be designed to deal with
unpredictable context occurrences for monitoring, validation,
and troubleshooting purposes. This happens because users
do not always have a clear understanding of the interac-
tion between multiple instances of different entities, such as
resources, fusion, rules, and actions.
In a real world environment, different combinations can
happen in a system, which can puzzle administrators, integra-
tors and end-users when the system makes counter-intuitive
changes to the environment. When creating a rule for context
reasoning, administrators might consider a certain class of sen-
sors, but depending on how the rules are actually written, they
may catch other data that were not originally conceived to be
handled by them. As a consequence, unexpected, inconvenient,
or even harmful actions might happen. For example, scheduled
events can be easily generated by creating virtual sensors that
send data signaling the beginning and end of an event, such
as a meeting that takes place in a certain meeting room. It
is straightforward to observe that in that situation scheduled
events can be mixed up with on-demand events (people enter-
ing or leaving the room) and certain unplanned combinations
of context entities might actually occur.
KAMIENSKI et al.: CONTEXT DESIGN AND TRACKING FOR IoT-BASED ENERGY MANAGEMENT IN SMART CITIES
Fig. 5. Explicit and implicit context occurrences.
Fig. 5 depicts the two ways of creating contexts.
1) Contexts can be explicitly created using the context
designer with an expectation that they will occur in
a predictable way afterwards, but they might never occur
in practice.
2) Contexts can be implicitly discovered and created by the
context tracker after they occurred in an unpredictable
way.
The context tracker also counts the number of occurrences
of any particular context, both explicitly and implicitly cre-
ated. After a context is implicitly discovered and created by
the context tracker, it does not differ from its explicit counter-
part and it can be viewed, updated, and deleted by the context
designer. Finally, the context monitor is a tool within the con-
text modeler that allows users to follow contexts that occurred,
either explicitly designed or implicitly discovered.
As an illustration of explicit and implicit contexts, let us
assume the existence of an explicit scheduled classroom in
a university that switches lights on and turns air conditioning
(or heaters) on 10 min before a class starts. It does the opposite
10 min after the class finishes. A professor switches her classes
to the laboratory and does not tell the administration. Also,
there is a rule that whenever the absence of people inside
a classroom for more than 15 min is detected, lights, and other
devices must be turned off. It turns out that the classroom
will not be prepared for classes during the whole scheduled
period. The context tracker will track all executed actions and
identify the existence of an implicit context that has not been
planned. Thus, an administrator can check the reason that this
classroom is not used and contact the professor to perform
whatever action they see fit, such as creating a specific context
for dealing with that situation.
IV. C ONTEXT-AWARE M ANAGEMENT F RAMEWORK
Our context-aware management framework architecture
(Fig. 6) is divided into two major components linked by
a communication interface, which are context modeler, context
manager, and context API, respectively. The context manager
is divided into components that deal with context process-
ing, context occurrence, context tracking, and context storage.
The context modeler is divided into components that deal with
context design, context editing, and context monitoring. The
context API is a Web services REST interface that allows
applications, such as the context modeler to interact with the
context manager, but also other context user interfaces and
other components of the IMPReSS system [9]. Although our
691
Fig. 6. Context-aware management framework architecture for IoT-based
energy management systems for Smart Cities.
Fig. 7. Relational model of the context storage.
context-aware framework was developed for the IMPReSS
project, it can be used as an independent software platform.
Fig. 6 highlights context design and context tracking, which
will be further elaborated in the following sections.
The context manager provides features of context acqui-
sition, reasoning, and tracking, as well as algorithms for
sensor data fusion [8]. Two main design choices guided the
technological choices: object-oriented context modeling and
rule-based context reasoning. Some very mature underly-
ing technologies exist, such as persistence storage and rule
engines. These are based on the object-oriented approach. In
addition, rule-based reasoning is commonly used and offers
different existing tools that integrate with object-oriented
programming languages.
The data fuser receives sensor data from the communicator
and uses a set of techniques for combining data from multiple
sources or computing statistics. Whenever fusion criteria are
met, it activates the reasoner that infers logical consequences
from a set of facts, by searching the entire set of rules for
a match. As a result, one or more actions are performed
which send commands to actuators. Finally, the communicator
encapsulates communication with sensors and actuators.
The context storage deals with context entity templates.
A relational database is used for storing entity information
(Fig. 7), but not for sensor data that is better dealt with by
NoSQL databases. Here, an explanation regarding the use of
a relational model in IoT is needed, since current solutions
usually are based on NoSQL. A key feature of our strategy is
providing means for users to track and monitor contexts, as
they occur in a normal execution of a system. In order to keep
all information needed for context tracking purposes, we must
692
Fig. 8. Context design scenario: smart energy management in classroom
A-112.
be able to refer entities to each other. A relational database
with foreign keys and integrity features was considered best
fitted to achieving that end.
Our relational model is divided into three categories:
1) entity; 2) relationship; and 3) log, represented in Fig. 7 in
dark blue, light blue, and orange, respectively. Tables belong-
ing to the entity category represent the context entities depicted
in Fig. 2. Tables belonging to the relationship category are
associative entities, used to maintain integrity among different
entity tables. Finally, tables belonging to the log category keep
log information for tracking and auditing purposes. Both place
and context entities have self-relationships in order to provide
scalability by nesting entities inside each other.
V. C ONTEXT D ESIGN
Context design is performed by a component that exposes
a graphical user interface called context modeler. This compo-
nent is also responsible for context editing and monitoring. In
order to demonstrate the features of context design, we will
adopt a scenario of energy saving in a university classroom
(borrowed from [9]). Fig. 8 represents a simplified classroom
with four rows and four individual lights (L1–L4), four ultra-
sonic presence sensors (U1–U4), and two Kinect sensors (K1
and K2). There is one ultrasonic sensors installed per row and
two Kinect sensors each two rows since they have a wider
angle. We use both ultrasonic and Kinect sensors to improve
presence detection and decrease false positives. We deployed
such scenario in a real setting for demonstration and evaluation
purposes.
Table I depicts an example of five rules used in this sce-
nario to switch lights on and off according to the presence
of students in specific rows of the classroom. The rationale
for this example is that if back rows are empty, lights can
be automatically turned on but whenever there is at least one
student in a certain row, all lights from that row frontwards
are turned on. Ultrasonic sensors report presence of students
in a row as 1 and absence as 0, whereas Kinect sensors detect
presence in two rows at once and therefore after passing by
the data fusion step they arrive at the Reasoner as two bits:
00, 01, 10, and 11. For example, 01 means that at least one
student was detected in the right side but no one was detected
in the left side. Presence in a row must be detected by both
ultrasonic and Kinect sensors in order for lights to be turned
ON from that row frontwards.
IEEE INTERNET OF THINGS JOURNAL, VOL. 5, NO. 2, APRIL 2018
TABLE I
S MART E NERGY M ANAGEMENT: RULES AND ACTIONS
Fig. 9. Context graph for the context design scenario.
We use rule R4 (highlighted in Table I) to depict the context
design feature, which turns light L1 on (row 1) and turns lights
L2–L4 off. In order to guarantee that presence is detected only
in row 1, among ultrasonic sensors only sensor U1 must report
presence (i.e., U1 = 1 and U2 = U3 = U4 = 0) and for Kinect
sensors, only K1 must detect presence in its right row (i.e.,
K1 = 01 and K2 = 00).
Fig. 9 depicts a graphical view of the context graph that
must be modeled in the context designer. Rule R4 was adapted
to include two fusion steps in order to relieve the reasoner
from a high processing burden by reducing the complexity of
the rules. Therefore, the first fusion step implements a con-
catenation of bits (II) for both ultrasonic and Kinect sensors
and the second one implements a logical AND operation (∧).
This example follows exactly the condition of R4 so that the
actions will be sent to actuators in order to only keep light
L1 switched on.
Fig. 10 depicts a context graph as it appears in the con-
text designer, modeling the same context illustrated in Fig. 9,
except that the place entity is not represented within the graph,
but as its attribute. The context designer can add sensors, actu-
ators, fusion, and rules, where actions are specified together
with rules, since their execution is a direct result of a rule
being fired. Since actions for switching lights on and off are
already linked to rule R4, whenever R4 is fired, commands
are sent to the actuators L1–L4.
Using the context copy feature of the context modeler, con-
texts can be easily replicated to provide scalability to the
context design approach. For example, universities usually
have a high number of similar classrooms in terms of size and
layout. Administrators can create one instance of an empty
classroom context and replicate it to all similar classrooms.
KAMIENSKI et al.: CONTEXT DESIGN AND TRACKING FOR IoT-BASED ENERGY MANAGEMENT IN SMART CITIES
Fig. 10. Context designer—context graph for switching light L1 ON.
Even though every classroom has a different set of resources
(sensors and actuators) they can be automatically detected
by the IMPReSS resource discovery component and tagged
with the place, where they are located [7]. Currently, there
are different proposals for dealing with automated labeling (or
naming) schemes for sensors, such as similarity finding based
on linguistic and semantic techniques [16]. Therefore, when-
ever a new context is replicated by the context copy function,
it can find resources of the same type in both the source and
target classrooms and match the discovered resources with the
newly created one. In our current proof-of-concept prototype,
this feature is not yet available due to the lack of a real sce-
nario for deployment and testing purposes. Nevertheless, we
consider it conceptually simple and feasible from a software
development perspective since IMPReSS provides resource
discovery features. Nested contexts (Section III-C) also pro-
vide scalability to the context design approach, by allowing
the use of contexts as virtual sensors and thus using a context
inside another context.
VI. C ONTEXT T RACKING
Context tracking leverages context logging, which plays an
important role for auditing purposes, but it also helps users
to understand which contexts are being executed, given a set
of places, resources (sensors and actuators), fusion, rules, and
actions. Context tracking does not simply consist of finding the
execution of a single entity a posteriori, but provides features
for helping users to understand and monitor which contexts are
being executed in practice. Even though context graphs can be
specified by the context designer, contexts may be executed in
unpredictable ways. Some contexts occur in the exact way they
were initially defined (i.e., they are explicitly created), whereas
other contexts may happen in unexpected ways without users
being aware of them (i.e., they are implicitly discovered).
The context tracker follows traces of context occurrences
stored in the context storage, as depicted by Fig. 11. The
communicator, fuser, and reasoner components of the context
manager store sensor data, fusion criteria, rules, and actions
to actuators as shown by the top part of Fig. 11.
693
Fig. 11. Context tracker.
Fig. 12. Context tracking algorithm.
The context tracker runs periodically as a batch process
and always starts by finding actions executed since its last
execution. It reads all actions one by one and finds a rule,
fusions, sensors, and actuators associated to them. One con-
text occurrence (and related context graph) can have many
nested fusions, so that the tracker recursively finds all fusions
and with the set of fusions finds all sensors that fed data into
them. Whenever a context execution is detected, the tracker
checks in the context storage if this context exists, either an
explicitly created or a previously implicitly discovered one. In
case this detected context is found in the storage, it increases
its count information and updates the timestamp. Otherwise,
a new implicit context is created.
Fig. 12 depicts the high-level algorithm used by the con-
text tracker. The tracking algorithm receives a time interval
as input, consisting of the initial and final timestamp of the
actions that started a context occurrence. In line 5, the algo-
rithm loops over all actions within that interval, obtained in
line 4. In lines 6–8, it finds all rules, actuators, and fusions
related to each action and after that it calls a function to
obtain all nested fusions recursively (lines 16–22). The result
of a fusion might become a virtual sensor, which in turn may
be fed into another fusion. Tracking such nested fusions needs
a recursive function for guaranteeing that no matter how many
694
Fig. 13. Context tracker performance.
nested fusions exist, all of them will be tracked back reaching
the sensors. In line 11, it makes a new context out of rule,
fusions, and resources (sensors and actuators).
In a real scenario, the context tracker will need to process
a large number of contexts in a small time period, which might
pose constraints on its use. In order to understand the scalabil-
ity of the context tracker, we conducted a performance analysis
study and for that purpose we populated the database shown
in Fig. 7 with synthetic data. We considered a scenario, where
each sensor sends data that goes through fusion, rule, and
action entities. This is the worst-case scenario because every
single data sent by a sensor generates a new context.
All tables depicted in Fig. 7 were populated with data rep-
resenting entities that make up a context as depicted in
Figs. 2 and 3. Tables representing entities obviously have
to be populated, but also relationship tables are necessary,
such as FUSION_RULE. Also, auxiliary tables that are not in
Fig. 7 were also populated, such as PLACE_TYPE. Finally,
log tables are necessary for identifying that contexts were exe-
cuted, such as RULE_ACTION_LOG that is, where the tracker
starts looking for contexts according to Fig. 11.
Using this methodology, the context tracker was executed
30 times for 1, 10, 100, 1000, and 10 000 contexts and the
average result of the 30 replications is depicted in Fig. 13. 99%
asymptotic confidence intervals were computed, but they are
not shown in the chart because the values are insignificantly
small. The chart is in a logarithmic scale and clearly shows
that the tracker running time grows linearly with the number
of contexts. For these experiments, with a relatively old and
modest hardware configuration, 10 000 contexts can be pro-
cessed in less than 5 min (268.55 s). In our experiments we
used a dedicated server based on Intel Xeon CPU E3-1240 V2
3.40 GHz with 8 GB RAM.
Considering the context tracker processing times shown in
Fig. 13, let us understand how many sensors it is able to han-
dle in a certain time period. For the Padova Smart City project,
Zanella et al. [17] identified two types of sensors: 1) those that
generate data constantly in spaced time periods and 2) those
that generate data on demand according to particular events.
The worst-case scenario for time-driven sensors in Padova is
to send one data packet every 10 min. Also, a context is only
created when a rule is fired, i.e., a given behavior is only
changed under certain circumstances. Using a very conserva-
tive estimate that a context is created 5% of the times a sensor
data is sent, a simple calculation shows us that 400 000 sensors
IEEE INTERNET OF THINGS JOURNAL, VOL. 5, NO. 2, APRIL 2018
generate data that creates 2000 contexts per minute, which can
be processed by the context tracker according to Fig. 13. On
demand sensors, on the other hand, generate data at irregular
periods, whenever certain events occurs for changing certain
behaviors. This type of sensor typically will not pose scala-
bility constraints because it will be able to process in batch
after the event is finished.
In addition, we have to consider that the hardware used in
the experiments is not top notch and that the context tracker
is highly parallelized because of the query structure of the
tracking algorithm, but we only used a single processing core.
Therefore, if we consider a high end CPU, such as Intel Xeon
E5-2679 v4 with 20 cores, one can easily see that the context
tracker can handle more than 10 million (or even 20 million)
time-driven sensors in one minute.
VII. C ONCLUSION
Context-aware systems are key resources for making sense
of the myriad of information generated by a multitude of
sensors in any IoT-based application for Smart Cities. They
allow applications to adapt behavior automatically according
to changes in the current environment conditions. Our context-
aware management framework identifies many components
needed for such a system in a smart energy application, partic-
ularly the context graph, the context designer, and the context
tracker.
This framework has been implemented, deployed and tested
in different situations, including troubleshooting, demonstra-
tion, reviewing, and performance analysis purposes. Our expe-
rience makes us believe that using context graphs that can
be designed and tracked might be successfully used in future
systems in order to help developers, administrators, and end-
users to harness the wealth of information generated by highly
scalable IoT systems.
As future work, we intend to broaden the scope of the
context-aware framework for different applications of Smart
Cities, which may require additional context entities. Also,
we will test different implementations of the context man-
ager, varying the data architecture for grasping a better
understanding on limits of scalability.
R EFERENCES
[1] L. Atzoria, A. Ierab, and G. Morabitoc, “The Internet of Things:
A survey,” Comput. Netw., vol. 54, no. 15, pp. 2787–2805, Oct. 2010.
[2] M. Baldauf, S. Dustdar, and F. Rosenberg, “A survey on context-aware
systems,” Int. J. Ad Hoc Ubiquitous Comput., vol. 2, no. 4, pp. 263–277,
2007.
[3] E. Borgia, “The Internet of Things vision: Key features, applications and
open issues,” Comput. Commun., vol. 54, no. 1, pp. 1–31, Dec. 2014.
[4] A. Botta, W. de Donato, V. Persico, and A. Pescapé, “Integration of cloud
computing and Internet of Things: A survey,” Future Gener. Comput.
Syst., vol. 56, pp. 684–700, Mar. 2016.
[5] J. Byun and S. Park, “Development of a self-adapting intelligent sys-
tem for building energy saving and context-aware smart services,” IEEE
Trans. Consum. Electron., vol. 57, no. 1, pp. 90–98, Feb. 2011.
[6] B. Campbell and P. Dutta, “An energy-harvesting sensor architecture and
toolkit for building monitoring and event detection,” in Proc. 1st ACM
Int. Conf. Embedded Syst. Energy Efficient Build. (BuildSys), Memphis,
TN, USA, Nov. 2014, pp. 100–109.
[7] E. Ferrera et al., “XMPP-based infrastructure for IoT network man-
agement and rapid services and applications development,” Ann.
Telecommun., vol. 72, nos. 7–8, pp. 443–457, Aug. 2017.
KAMIENSKI et al.: CONTEXT DESIGN AND TRACKING FOR IoT-BASED ENERGY MANAGEMENT IN SMART CITIES 695

[8] C. Kamienski et al., “Context-aware energy efficiency management for
smart buildings,” in Proc. IEEE World Forum Internet Things (WF IoT),
Milan, Italy, Dec. 2015, pp. 699–704.
[9] C. Kamienski et al., “Application development for the Internet of
Things: A context-aware mixed criticality systems development plat-
form,” Comput. Commun., vol. 104, pp. 1–16, May 2017.
[10] A. I. Maarala, X. Su, and J. Riekki, “Semantic reasoning for context-
aware Internet of Things applications,” IEEE Internet Things J., vol. 4,
no. 2, pp. 461–473, Apr. 2017.
[11] P. Makris, D. N. Skoutas, and C. Skianis, “A survey on context-aware
mobile and wireless networking: On networking and computing envi-
ronments’ integration,” IEEE Commun. Surveys Tuts., vol. 15, no. 1,
pp. 362–386, 1st Quart., 2013.
[12] M. V. Moreno et al., “Applicability of big data techniques to smart cities
deployments,” IEEE Trans. Ind. Informat., vol. 13, no. 2, pp. 800–809,
Apr. 2017.
[13] E. F. Nakamura, A. A. F. Loureiro, and A. C. Frery, “Information fusion
for wireless sensor networks: Methods, models, and classifications,”
ACM Comput. Surveys, vol. 39, no. 3, 2007, Art. no. 9.
[14] E. A. Nuaimi, H. A. Neyadi, N. Mohamed, and J. Al-Jaroodi,
“Applications of big data to smart cities,” J. Internet Services Appl.,
vol. 6, p. 25, Dec. 2015.
[15] C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos, “Context
aware computing for the Internet of Things: A survey,” IEEE Commun.
Surveys Tuts., vol. 16, no. 1, pp. 414–454, 1st Quart., 2014.
[16] A. Schumann, J. Ploennigs, and B. Gorman, “Towards automating the
deployment of energy saving approaches in buildings,” in Proc. 1st ACM
Int. Conf. Embedded Syst. Energy Efficient Build. (BuildSys), Memphis,
TN, USA, Nov. 2014, pp. 164–167.
[17] A. Zanella, N. Bui, A. Castellani, L. Vangelista, and M. Zorzi, “Internet
of Things for smart cities,” IEEE Internet Things J., vol. 1, no. 1,
pp. 22–32, Feb. 2014.
Gabriela O. Biondi received the B.S. degree in
computer science from the Centro Universitário
da FEI, São Bernardo do Campo, Brazil, in 2011,
and the M.S. degree in computer science from the
Federal University of ABC, Santo André, Brazil, in
2013, researching with data mining. She is currently
pursuing the Ph.D. degree in information engineer-
ing at the NUVEM Strategic Research Unit, Federal
University of ABC.
She is a Research Fellow of the NUVEM Strategic
Research Unit, researching with data models and
technologies for IoT for Smart Cities. From 2013 to 2016, she performed
research on the IMPReSS project. She has been an instructor of different
courses in ICT, since 2008, and she has been a Lecturer with the Faculdade
das Américas, Fortaleza, Brazil, since 2015.
Isaac Pinheiro is currently pursuing the B.S. degree
in computer science with the Federal University of
ABC, Santo André, Brazil.
From 2013 to 2016, he was involved with research
on the IMPReSS project. He has been researching
for many years with development of Web backend
applications. His current research interests include
computer networks, Internet of Things (IoT), and
software development for the IoT.

Carlos A. Kamienski (M’07) received the B.S.

degree in computer science from the Federal
University of Santa Catarina, Florianópolis, Brazil,
in 1989, the M.S. degree from the State University
of Campinas, Campinas, Brazil, in 1994, and the
Ph.D. degree in computer science from the Federal
University of Pernambuco, Recife, Brazil, in 2003.
He is a Full Professor of computer science with
the Federal University of ABC, Santo André, Brazil,
where he currently holds the positions of the Head of
International Relations and the Head of the NUVEM
Strategic Research Group. His current research interests include Internet of
Things, Smart Cities, network softwarization, and cloud/fog computing.
Ivan D. Zyrianoff received the B.S. degree in sci-
ence and technology from the Federal University of
ABC, Santo André, Brazil, in 2016, where he is cur-
rently pursuing the B.S. degree in computer science
and the master’s degree in information engineering.
From 2014 to 2016, he was involved with research
on the IMPReSS project. He is a Research Fellow
of the NUVEM Strategic Research Unit, researching
the Internet of Things and fog computing.

Fabrizio F. Borelli received the B.S. degree in

science and technology, B.S. degree in computer sci-
ence, and M.S. degree in computer science from the
Marc Jentsch received the Diploma degree in geoin-
Federal University of ABC, Santo André, Brazil,
formatics from the University of Münster, Münster,
in 2011 and 2013, respectively, researched with
Germany, and the Ph.D. degree in computer sci-
bioinformatics and HPC (GPUs). He is currently
ence from the RWTH Aachen University, Aachen,
pursuing the Ph.D. degree in information engineer-
Germany.
ing at the NUVEM Strategic Research Unit, Federal
He is currently a Research Fellow with the
University of ABC.
Fraunhofer FIT Research Center, Sankt Augustin,
From 2013 to 2016, he was involved with research
Germany, where he coordinated the IMPReSS
on the IMPReSS project. He is a Research Fellow
project.
with the NUVEM Strategic Research Unit, researching with software and
data architectures for application development in IoT for Smart Cities.