COBASEN (COntext-BAsed Search ENgine)
Framework: Discovery of Computing Devices in IoT
Environments
Willian T. Lunardi1 , Everton de Matos1 , Ramão Tiburski1 , Leonardo A. Amaral1 , Sabrina Marczak2 ,
Fabiano Hessel2 , Marcelo Thielo2
Pontifı́cia Universidade Católica do Rio Grande do Sul (PUCRS)
Porto Alegre, Brazil
1
{willian.lunardi, everton.matos.001, ramao.tiburski, leonardo.amaral}@acad.pucrs.br
2
{sabrina.marczak, fabiano.hessel, marcelo.thielo}@pucrs.br
Abstract—During the past few years, with the fast development and proliferation of the Internet of Things (IoT), many
application areas have started to exploit this new computing
paradigm. An interesting use of IoT is in the Industrial field,
which has resulted in a new business concept called IIoT
(Industrial Internet of Things). Another important fact is the
number of active computing devices that has been growing at a
rapid pace in IoT environments around the world. Consequently,
a mechanism to deal with this different devices has become necessary. Middleware systems solutions for IoT have been developed
in both research and industrial environments to supply this need.
However, search, discover, select, and interact with middleware
devices remain a critical challenge. In this paper we present
COBASEN, a software framework composed of a Context Module
and a Search Engine to address the research challenge regarding
the discovery and interaction with IoT devices when large number
of devices with overlapping and sometimes redundant functionality are available in IoT middleware systems. The search engine
of the COBASEN operates based on the semantic characteristics
of the devices, which is provided by the context module, and that
helps users in their interactions with desired devices. The main
goal of this work is to highlight the importance of a context-based
search engine in the IoT paradigm and to provide a solution that
addresses the proper management of such search and usage in IoT
middleware environments. We developed a tool that implements
all COBASEN concepts. However, for preliminarily tests, we
made a functional evaluation of the search engine in terms of
performance for indexing and querying response time. Our initial
findings suggest that COBASEN provides important approaches
that facilitate the development of IIoT applications, which based
on the COBASEN systems support, may perform essential roles
to improve industrial processes.
I.
I NTRODUCTION
The term Internet of Things (IoT) was coined in 1998 [1]
and defined as the computing paradigm that allows people
and things to be connected Anytime, Anyplace, with Anything
and Anyone, ideally using Any path/network and Any service
[2]. In this sense, there are current market statistics and
predictions that demonstrate a rapid growth in computing
device deployments related to IoT environments. By 2020, it
is estimated that there will be 50 to 100 billion IoT devices
connected to the Internet [3].
Based on these statistics, we can see that the old frontiers
of industrial environments between the digital and physical
world will be torn down. According to experts from industry
and research, the introduction of the IoT into the manufacturing
environment is ushering in a fourth industrial revolution called
Industrial Internet of Things (IIoT). The adoption of several
smart computing devices (RFID, sensors, and actuators) in
industrial environments has improved manufacturing processes
and their outcomes (e.g. cost savings, greater efficiency and
speed, smarter products and services). These statistics and facts
imply that we will be faced with a vast amount of IoT devices,
which, when properly used, will add more value to industry.
In this sense, the biggest challenge and time-consuming task
is to select and use the appropriate devices when there are a
large amount of available devices to choose from and, often,
with heterogeneous characteristics.
Middleware systems solutions for IoT have been developed
in both research and industrial environments to supply this
need. However, search, discover, select, and interact with
middleware devices remain a critical challenge [4]. End users,
such as programmers that are in charge of selecting (aggregating) heterogeneous devices in order to contextualize virtual
environments and apply operations among them, are not aware
of domain modeling and middleware specification patterns (to
define what and how they want to interact with things/devices).
Besides, end users may not have enough knowledge to perform
such task without devoting time to understand the middleware
patterns or to engage others who are responsible for modeling
the domain of devices.
To exemplify such situation, let’s consider an industrial
scenario in which a programmer desires to develop an application to measure the humidity of soybeans that are stored
in a warehouse. There is no single device that is capable of
measuring the humidity of soybeans. For example, soybean
humidity can be roughly attributed by two categories: environmental temperature and environmental humidity. Each category
can be measured by several devices and the data retrieved
from multiple devices need to be fused together to generate
such high level context. Therefore, allowing the search and
selection of heterogeneous devices by understanding the user
requirements and, as a consequence, facilitating data fusion
and making the middleware layer transparent to the user is a
inherently complex challenge.
By analyzing other IoT middleware systems (e.g., [5][6]),
Fig. 1.
COMPaaS architecture overview
Fig. 2.
Example of specification report
we found that they do not provide intuitive search methods for
end users and also do not focus on middleware transparency
and ease of use of devices by programmers. Trying to fill
this gap, we propose in this work a software framework that
allows IoT middleware users, who are not aware of devices
domain and middleware patterns, to be able to search, discover,
select, and interact with middleware devices in order to use the
devices in their applications.
IoT applications and middleware system, which is a software
layer interposed between the infrastructure of devices and applications, and is responsible for providing services according
to devices functionality [11]. IoT middleware systems have
evolved from hiding network details to applications into more
sophisticated systems to handle many important requirements,
providing support for heterogeneity and interoperability of
devices, data management, security, etc.
The remainder of this paper is organized as follows:
Section II highlights our vision and where our proposed
framework and its initial evaluation fit in in the IoT field. This
section also describes the COMPaaS (Cooperative Middleware
Platform as a Service) architecture and briefly reviews relevant
literature. Section III discusses a real-world application related
to grain storage domain as a means to exemplify the need
of our contribution for the Industrial IoT field. Our proposed
solution, the COBASEN (COntext BAsed Search ENgine)
framework, is presented in detail in Section IV. Section V
provides implementation details including tools, software platforms, and data sets used in this work and our preliminary
results. Section VI discusses how the use of our framework can
help to solve the problems previously mentioned. Section VII
concludes the paper with final considerations and prospects of
future work.
Many of the system architectures proposed for IoT middleware comply with Service-Oriented Architecture (SOA).
This approach allows each device to offer its functionality as
standard services. Moreover, SOA architecture refer to enables
interoperation in various domains, like industry, environment,
and society, and supports open and standardized communication through all layers of web services.
II.
BACKGROUND AND R ELATED W ORK
The IIoT can use a SOA-based IoT middleware in order to
meet applications needs, providing infrastructure abstractions
to applications and offering multiple services [12]. In this
sense, in a prior work we described COMPaaS [7]. COMPaaS
is a SOA-based IoT middleware that provides to users a
simple and well-defined infrastructure of services. Behind
these services there is a set of system layers that deals with
the users and applications requirements, for example, request
and notification of data, management of computing devices,
communication issues, and data management.
In this Section we briefly describe IoT middleware systems
focusing on our prior work – COMPaaS [7]. We also discuss
definitions of context and semantic characteristics that enrich
the representation of computational devices [8], as well as
technologies that allow discovery by querying in order to
discover heterogeneous devices according to the task at hand
in the IoT paradigm. This will be a significant enhancement
over current paradigms in which publishing and sharing the
domain characteristics of IoT devices is a challenging issue
[9].
The architecture of COMPaaS is composed of three main
cooperating systems (see Figure 1): API, Middleware, and
Logical Device. API is the system that provides methods
to be used by applications that desire to use middleware
services. Middleware is the system responsible for abstracting
the interactions between applications and devices and hides
all the complexity involved in these activities. Logical Device
is the system responsible for hiding all the complexity of
computing devices and abstracts their functionality. These
systems are based on Subscribe/Notify communication pattern.
A. IoT Middleware
In order to get data from devices using COMPaaS, we
describe here the necessary interactions and exchange of
data [7]:
IoT ecosystems are based on a layered architecture style
and use this view to abstract the integration of objects and to
provide services solutions to applications [10]. In IoT, highlevel system layers as the application layer are composed of
•
The application uses the API to get access to middleware web service interface (SOAP) to define and
subscribe its specification, which contains some important parameters for the collecting of data by the
middleware (see Figure 2).
•
Middleware interprets the application specification and
creates the respects collection cycles.
•
Middleware uses each logical device web service
interface (REST) to subscribe and start the device(s)
involved in the collection cycles.
•
Each logical device provides the requested data in a
DataMessage (generic object) object that is notified to
the middleware.
•
Middleware processes the data according to the specification parameters and, at the end of each cycle,
prepares the reports and sends them to the application.
At the end of entire cycle, Middleware stops and
unsubscribes the devices.
•
The application unsubscribes the Middleware and uses
the collected data.
Although COMPaaS has all these features, it does not have
a functionality to make available its devices directory, which
could assist in the process of search, selection, and usage of
IoT devices in COMPaaS.
B. Context of Things
Context is considered any information that can be used to
characterize the situation of an entity. Entity is a person, place,
or computing device (also called thing) that is relevant to the
interaction between an user and an application, including the
user and the application themselves [13]. In this way, an IoT
ecosystem requires a mechanism for the acquisition of context
characteristics of devices in order to provide search features
for devices discovery.
Context information about IoT devices needs to be acquired
and stored with annotations that will make easy to retrieve it
later. Abowd and Mynatt [14] identified the five Ws (Who,
What, Where, When, and Why) as the minimum annotations
that are necessary to understand context. In IoT, once context
can be obtained through the device description, it is possible
to create a semantic version of the device information and
characteristics.
A set of methods is mandatory to obtain the context of
an entity. Furthermore, there is a set of actions, organized in
phases, that characterize the context life-cycle for IoT systems.
For example, Perera et al. [15] propose a life-cycle and explain
how acquisition, modelling, reasoning, and distribution of
context should occur.
In tion process, context needs to be acquired from various
sources of information. The sources could be physical or
virtual devices. The techniques used to acquire context can
vary and are based on responsibility, frequency, context source,
sensor type, and acquisition process. More details are presented
in [15].
Context modelling is organized in two steps [16]. First,
new context information needs to be defined in terms of
attributes, characteristics, and relationships with previously
specified context. In the second step, the outcome of the first
step needs to be validated and the new context information
needs to be merged and added to the existing context information repository. Finally, the new context information is made
available to be used when needed. The most popular context
modelling techniques are surveyed in [15] and [16].
Context reasoning can be defined as a method of deducing
new knowledge based on the available information [17]. It can
also be explained as a process of achieving high-level context
deductions from a set of contexts [18]. For more details about
reasoning techniques, see [16] and [17].
Finally, context distribution is a fairly straightforward task.
It provides methods to deliver context to the consumers.
From the end user perspective this task can be called context
acquisition. The context can be distributed in two ways [15].
The first way is by querying, and the end user has the initiative
and make a query in a context service mechanism. The second
way is by using a publishing/subscribing pattern in which the
consumer informs the context mechanism of its interest and
receives notification updates with new information.
C. IoT Search Engines
An IoT directory must support search in order to discover
heterogeneous devices [15]. Searches enables the retrieval
of derived information based on syntactic, semantic, and
structural information contained in data. Let’s assume that a
possible IoT device can have the following characteristics:
”The device is a temperature sensor that is located in the
Northwest pendulum, level 1 of the silo number 13, and its
status is online”. A search engine furthers the understanding
of variations in queries and our previous description can be
retrieved by the following query: ”available temperature device
situated in Northwest silo 13”.
Technically, a search engine is a system that aims to create
an index of objects and use this index to respond queries from
users. This kind of process enables, for example, a term-based
search allowing that the sensor previously described can be
rescued by a search that was made using synonyms, variations
of characters, or even written in another language.
In terms of existing systems, Linked Sensor Middleware
(LSM) [5] [19] provides limited functionality such as selecting
devices based on location and device types. Nevertheless, all
the searching capability uses SPARQL query language, which
is not intuitive. GSN [6] is another IoT middleware similar
to LSM that provides a middleware to address the challenges
of device data integration and distributed query processing. In
short, GSN lists all devices available in a combo-box, which
is used by the user to select the desired device. Xively [20]
(formely known as COSM) is another approach that connects
and collects data from devices to provide real-time control and
data storage. Xively also offers only keyword search.
According to the study provided by the GNS Team [6],
there are over 12,000 working and useful Web services on
the Web. Even in such condition, making a choice among
the available alternatives (depending on context characteristics)
has become a challenging issue. Perera et al. [21] reinforce that
”similarities” strengthen the argument that device selection is
an important challenge at the same level of complexity as Web
services. On the other hand, ”differences” demonstrate that
device selection will become a much more complex challenge
over the coming decade due to the scale of IoT environments.
III.
R EAL -W ORLD C HALLENGE
This section presents a real-world application example
to reinforce our arguments and to strength the necessity to
provide an easily understandable manner for end users and
programmers of IoT applications to search, select, and use
IoT devices by middleware functionality. It will also help to
understand the related challenges more clearly.
Spontaneous heating of carbonaceous materials is a common phenomenon, occurring in particular when large quantities
of materials are stored for extended periods. In large-scale silo
storage of wood fuel pellets self heating has become a serious
problem, sometimes causing self-ignition [22]. The challenge
can be addressed by deploying monitoring and actuator devices
in the environment. Moreover, querying the collected data of
these devices is essential to understand what is happening in
the silo. For example, monitoring the temperature of a silo can
be useful for identifying outbreaks fermentation. However, a
manual temperature monitoring of a silo is very difficult and
sometimes impossible due to its possible physical size. The
utilization of smart monitoring devices (e.g. temperature, air
humidity) can be useful to solve this problem.
To monitor the temperature of a single silo, an average of
124 monitoring devices are needed [23]. Another perspective
can be a scenario of an industrial environment that contains 10
storage silos with several devices monitoring the temperature
of each silo. The number of possible devices to cover this
environment is able to reach 1240. The challenge in this
case is that after the deployment of the infrastructure of the
IoT middleware and physical and logical arrangement of the
devices, end users or IoT application programmers (who are
not aware of the environment disposition of the devices) face
several difficulties regarding how to search, select, and use the
data provided by the monitoring devices.
The challenge is to develop a system that be able to search
the devices available in the middleware (based on their context
characteristics), and provide to users an easy and transparent
method of using these devices.
IV.
Fig. 3.
Overview of the COBASEN framework
A. COBASEN Framework
The COBASEN framework is composed of two main
components (see Figure 5). The first is the Context Module
that is responsible for gather the device context from the
middleware and send this context to the Search Engine. The
second component is the Search Engine that is responsible
for indexing the obtained device context and answer queries
using the index. The Search Engine also provides a graphical
interface that allows users to select one or more devices, as
well as to set the aggregation specification through specific
parameters. Finally, the Search Engine sends the specification
to the middleware layer and gives a feedback to the user.
The steps proposed for the COBASEN are presented in
Figure 3. The framework allows users to search and select
middleware devices according to the users needs (steps 1
and 2). After the aggregation (selecting a set of devices), the
user fills in a specification form (step 3). Next, the Search
Engine creates the aggregation specification according to the
middleware patterns and submits it to the middleware (steps 4
and 5).
1) Context Module: The aim of the Context Module is to
assemble an structure of information of each device connected
to the middleware and pass this information to the Search
Engine. In this way, the Search Engine will be aware of the
context of the devices.
S YSTEM A PPROACH
The goals of our system are two-fold: (1) to allow users
to search, select, and interact with middleware devices that
best suit the application requirements, and (2) to make the
IoT middleware patterns transparent to users (e.g., users do
not have to understand the middleware standards to define and
subscribe specification reports). In order to make this possible,
IoT middleware systems should follow some standardized architecture. We believe SOA is a consolidated and well-defined
system architecture pattern that provides an architecture able
to support the interactions needed to make our system goals
possible. In this sense, we propose a software framework
(called COBASEN - COntext BAsed Search ENgine) that
is complied with any SOA-based middleware solution that
supports the Subscribe/Notify communication pattern, as well
as data requesting mode using XML and Web Services.
The first step to start the contextualization is to obtain
the information of the devices. Context Module monitors the
middleware, and each time a device is registered or updated,
the Context Module updates the Search Engine device list.
Having the information of each device, the next step is
to perform the modeling of these data in an understandable
way for the Search Engine. Following a pre-established pattern
and also a standard widely used in the context-aware area,
the Context Module mounts a file in XML format with the
information of the devices. An example of this can be seen
in Figure 4. This XML file contains all necessary information
about the device, following the standard of the five W’s (Who,
What, Where, When, and Why) [14]. Finally, this XML file is
sent to Search Engine that creates the index of the devices in
a database.
Fig. 5.
Overview of the COBASEN architecture
play functions such as check synonyms to search on words
with equivalent meanings, stopwords (keywords that are not
considered relevant), and so on [25].
Fig. 4. Example of a XML file with information about a middleware device
2) Search Engine: Search engines are structurally similar
to database systems. Documents are stored in a repository,
and an index of the documents is maintained. An index is a
data structure that makes the engine efficient to retrieve objects
given the value of one or more elements of the objects. Queries
are evaluated by processing the index in order to identify
similarities, which are then returned to the user. However,
there are also many differences: database systems must contend
with arbitrarily complex queries, whereas the vast majority of
queries to search engines are lists of terms and phrases [24].
There are many ways to implement indexes, and we shall
not attempt to discuss the matter here. The most common
situation is where the objects are recorded, and the index is on
one of the fields of that record (e.g. books are objects recorded
and their titles are the index field).
A popular method of indexing is called Inverted Index [25].
Inverted File Index is a variation of Inverted Index that contains
a list of references to documents for each word. For example,
given two devices with the subsequent characteristics: D[1]:
”The device is a temperature sensor”; and D[2]: ”This sensor
measures the humidity” – we have the following Inverted File
Index (where the integers in the set notation brackets refer
to the indexes of the text symbols, D[1], and D[2]): ”a”:{1},
”device”:{1}, ”humidity”:{2}, ”is”:{1}, ”measure”:{2}, ”sensor”:{1, 2}, ”temperature”:{1}, ”the”:{1, 2}, ”this”:{2}. Another Inverted Index variation is the Full Inverted Index. This
method contains a list of references to documents for each
word and additionally contains the positions of each word
within a document.
Search engines also have procedures to analyze variations
in documents and queries. The verification of these variations
can improve the searching process. These procedures can
In COBASEN, the Search Engine is responsible for performing the following tasks:
1)
2)
3)
4)
5)
6)
To index the list of devices that are received from the
Context Module using an Inverted Index strategy;
To enable the search of devices through a query with
the utilization of analyzer functions;
To enable the selection of one or more middleware
devices (aggregation);
To generate the specification of the respective devices
aggregation created by the user;
To send the specification to the middleware; and
To send the feedback to the user containing the
necessary information to make use of the aggregation.
B. COBASEN Architecture
The architecture of COBASEN is an extension of COMPaaS architecture (see Subsection II.A). The proposed framework interactions consist of nine steps and are presented in
Figure 5. The steps with the letter ”A” correspond to the
acquisition process. The steps with the letter ”S” correspond
to process related to the search engine and internal middleware
functionalities. These steps may occur independently. Next, we
will explain the flows of activities shown in Figure 5.
The steps regarding to the letter ”A”: (A1) in this step
the context module gather information related to devices that
are connected to the middleware. This information contains
characteristics of each device. (A2) The context information
of devices is sent to the search engine; (A3) the search engine
receives and indexes the information about the devices context.
The steps regarding to the letter ”S”: (S1) The user searches
for device using a query; (S2) after the processing of user’s request, the search engine returns the result list by relevance. The
user sets aggregation and parameters; (S3) the specification is
sent to middleware. At the same time, the essential data is sent
Fig. 7. Aggregation List interface of the prototype tool. (1) Allows to select
the device, (2) Removes the selected devices from the aggregation list, (3)
Displays a window that contains all device characteristics.
during an indexing activity. We conducted each experiment
50 times and averages were considered in the results.
The application prototype was developed using Java. The
data used was stored in PostgreSQL database. As shown in
Figure 6, 7, and 8, the prototype allows to capture user needs
through a query to discover and select devices, and finally
create and validate the middleware specification.
Fig. 6. Search interface of the prototype tool. (1) Users express their needs
through a query, (2) Shows list of devices ranked according to index, (3)
Allows to select the device, (4) Add the selected devices to the aggregation
list. In addition, this step provides features to enhance user interaction: table
pagination, number of devices per page, among others.
to user (specification name) to make a subscription request;
(S4) the user makes a subscription request to middleware using
the specification name. In this moment the middleware event
cycle is started; (S5) middleware starts the devices included
in the specification report; (S6) middleware receives data from
devices and makes the processing according to the specification
report; (S7) finally, middleware sends a report to user with the
data from devices.
Note that after the creation of the middleware specification,
it is stored in the middleware and the user application can
access this specification as many times as necessary without
the need to perform the steps A1, A2, A3, S1, S2, and S3
again.
V.
P ROTOTYPE I MPLEMENTATION AND E VALUATION
In terms of evaluation, we assumed that to the achievement of ”transparency and usability tests” in the COBASEN
framework (which is an important requirement to validate the
relevancy of the COBASEN to fill the middleware gaps already
mentioned), first we must make ”performance tests” in order
to verify that the platform that implements the framework is
functional. In this way, the results of the performance test are
demonstrated at the end of this section. We reinforce that the
usability and transparency tests will come in a next stage of
this work.
We developed an application prototype that stimulates the
searching features of the COBASEN. Basically, we made
experiments that tested 2 main requirements: (1) time elapsed
while processing a query from user; and (2) time elapsed
In Figure 8 we can see the parameters of the middleware
specification definition interface. We can describe this Figure
as follows: (1) It allows user to choose the desired parameters
for setting the middleware specification. Repeat Period is the
time interval between event cycles without collecting data from
devices. Duration is the total time of a data collection cycle in
the middleware. Data set allows user to choose which collected
data will form the data set. There are three options: Additions:
it adds data of the current cycle but not from previous cycle,
Deletions: it adds data that are present only in the previous
cycle but not from current cycle, and Current: it adds only data
presented in the current cycle. Group By allows aggregation
of the resulting data by: Resource: aggregates data by URI,
Location: aggregates data by location, and None: data does
not have a aggregation parameter. Operation allows the user
to choose the type of processing on the aggregate data, which
can be: average, maximum, minimum, sum and none, (2) User
can see details and examples of each of the fields, (3) Creates
a specification containing the selected devices and chosen
parameters, which is sent to the middleware. These parameters
compose the XML specification, and an example can be seen
in Figure 2.
We used a computer with AMD FX-8350 (8 core) 4.0GHz
and 16GB RAM to evaluate COBASEN. For the search engine
(to manage device context and related data), we employed the
open source Apache Lucene API [26] to index data. Apache
Lucene API is a high-performance search engine library written entirely in Java. This API can be used to provide consistent
full-text indexing across both database objects and documents
since it utilizes Inverted Index strategies. Salesforce, LinkedIn
and Twitter are examples of large-scale Lucene deployments.
We made the following assumptions regarding the evaluation. We assume that device context characteristics are already
retrieved by the context module. Besides, we collected data sets
from COMPaaS and generated a synthetic data set. In other
words, we have used a synthetic method of data generation in
our evaluation, which provided device descriptions and context
information for one million of devices.
Fig. 8. Parameters definition interface of the prototype tool. All illustrated
fields are previously validated.
Fig. 10.
This graph shows processing time taken by indexing process
when number of context characteristics and numbers of device get increased.
Synthetic characteristics properties are used for that experiment.
transparency provided by the COBASEN is due to the system
interface (see Figures 6, 7, and 8) that hides the middleware
layer complexity and guides the user in the creation of the
middleware specification. In addition, an industrial environment that uses our framework will be able to develop different
applications to improve their process. The discussed example
in Section IV is only one among the various categories of
the industry that can take advantage of IoT technologies.
Some application examples are: monitoring, automation, cost
reduction, accident prevention, among others.
Fig. 9. This graph shows processing time taken when the number of devices
and the number of results per page gets increased. The number of context
properties used for searching kept at 10.
As depicted in Figure 9, the ”querying processing time”
is acceptable since we are not using pagination to restrict the
number of returned devices per page. Even in an extreme case
with 1 million of devices and a user making queries that returns
up to 20000 results, the processing time did not exceed 500
milliseconds. As depicted in Figure 10, reducing the number of
context characteristics per each device allows to improve the
performance of the search engine. The processing time starts
to get increased after 100000 devices. During the evaluation
phase that used 10 context characteristics and one million of
devices, the index size has reached 79,1MB, which is a positive
result when considering the total number of devices involved.
VI.
D ISCUSSION
With the constant growth of the IoT and the provision of a
huge number of IoT devices in the near future, it is unfeasible
that application programmers need to find the desired devices
manually and without a standard middleware support. This
limitation strengthens the fact that the adoption of a contextbased IoT system support like COBASEN in an industrial
environment has becoming even more necessary.
COBASEN is able to provide improvements in the IoT
application development process that are coupled with the
process of finding and usage of middleware devices, since
we provide a transparent method for users that do not know
the domain and/or the middleware configuration patterns. The
These improvements are possible due to the system components of the COBASEN framework. The acquisition of the
devices context characteristics provides the necessary information that enables the use of techniques for the retrieving of
heterogeneous devices (in this case the search engine). Based
on Figure 10, we can say that the indexing time increases with
the increasing of amount of devices context characteristics.
As shown in Figures 9 and 10, with the use of Inverted
Indexing strategies we can perform precise and faster full text
searches in exchange of greater difficulty in the act of inserting
and updating documents. It increases the efficiency of search
and makes the system scalable. We must point out that the
search method currently implemented in the prototype tool
uses pagination only in its interface to improve user interaction
with the system. In other words, the search method returns the
entire list of results sorted by relevance and then the interface
uses pagination to show this list. Therefore, Figure 9 shows
that is evident that the use of techniques which allow restrict
the number of resources per page can improve the searching
process and the efficiency of COBASEN. For example, if we
return 100 devices per page, the time would not exceed 7ms.
COBASEN presents itself as a essential tool to improve
the IoT applications development. In IoT environments is
very usual to come across the fact that people that deploy
middleware are not the same that develop the applications.
In this way, with the support of COMPaaS and COBASEN,
users from IoT environments (IIoT, smart cities, etc.) will be
enabled to develop applications for their environments without
having to learn the middleware patterns and/or understand
the devices modeling. It is a substantial improvement ms of
business processes and can be widely used to help users in
large scale environments.
VII.
[7]
C ONCLUSIONS AND F UTURE W ORK
In this paper we proposed COBASEN framework to allow
scalable search and transparent usage of computational devices
in IoT environments. The framework is composed of a context
module and a search engine that enables the use of context
information to discover, select, and usage of devices that are
best suited for user and application requirements. It also makes
the middleware specification patterns transparent to the users,
generating the necessary outputs.
Our experimental results demonstrated that the proposed
framework is efficient and can help users in the development
of their applications to IoT environments. Besides, industrial
environments can benefit from the use of COBASEN since
is difficult for an outsider of the IIoT environment to understand the complex characteristics of the domain, which
can be facilitated by the context-based and integration-driven
characteristics of the systems of COBASEN.
In future, we are planning to perform tests related to
usability and transparency of the platform that implements
COBASEN, and also improve both context module and search
engine. In the context module we will explore techniques to
analyze and categorize devices in order to contextualize environments. In the search engine we will explore the possibility
of develop functions to improve the querying (e.g. pagination,
faceting, and filtering) and the security (authentication and
access control).
We believe the pagination technique, as stated earlier, will
enhance the search engine response time. Further, the faceting
technique will allow to divide the results of a query into
multiple categories. Finally, the filtering technique will be able
to allow to filter query results according to a custom filtering
process, which is a way to apply additional data restrictions.
Some interesting use cases of filters are: security (e.g. returns
only devices where the logged user has credentials), temporal
data (e.g. view only last month’s data), and population filter
(e.g. search limited to a given category).
ACKNOWLEDGMENT
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
Our thanks to CAPES/CNPq for the funding within the
scope of the project numbers 381657/2014-0 and 058792/2010.
R EFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
A. Kevin, “That internet of things thing, in the real world things matter
more than ideas,” RFID Journal, vol. 22, 2009.
P. Guillemin, P. Friess et al., “Internet of things strategic research
roadmap,” The Cluster of European Research Projects, Tech. Rep.,
September, 2009.
H. Sundmaeker, P. Guillemin, P. Friess, and S. Woelfflé, “Vision and
challenges for realising the internet of things,” 2010.
C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos, “Ca4iot:
Context awareness for internet of things,” in Green Computing and
Communications (GreenCom), 2012 IEEE International Conference on.
IEEE, 2012, pp. 775–782.
Digital Enterprise Research Institute, “Linked sensor middleware (lsm),”
http://lsm.deri.ie/, accessed: 2015-03-26.
GSN
Team,
“Global
Sensor
Network,”
http://sourceforge.net/apps/trac/gsn/, accessed: 2015-03-11.
[22]
[23]
[24]
[25]
[26]
L. Amaral, R. Tiburski, E. Matos, and F. Hessel, “Cooperative
middleware platform as a service for internet of things applications,” in
Proceedings of the 30th Annual ACM Symposium on Applied Computing
(to be published), ser. SAC ’15. New York, NY, USA: ACM, 2015.
[Online]. Available: http://dx.doi.org/10.1145/2695664.2695799
B. Christophe, “Managing massive data of the internet of things through
cooperative semantic nodes,” in Semantic Computing (ICSC), 2012
IEEE Sixth International Conference on. IEEE, 2012, pp. 93–100.
P. Barnaghi, W. Wang, C. Henson, and K. Taylor, “Semantics for the
internet of things: early progress and back to the future,” International
Journal on Semantic Web and Information Systems (IJSWIS), vol. 8,
no. 1, pp. 1–21, 2012.
Q. Jing, A. Vasilakos, J. Wan, J. Lu, and D. Qiu, “Security of the internet
of things: perspectives and challenges,” Wireless Networks, vol. 20,
no. 8, pp. 2481–2501, 2014.
L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,”
Computer Networks, vol. 54, no. 15, pp. 2787 – 2805, 2010.
S. Bandyopadhyay, M. Sengupta, S. Maiti, and S. Dutta, “Role of
middleware for internet of things: A study,” International Journal of
Computer Science & Engineering Survey (IJCSES), vol. 2, no. 3, pp.
94–105, 2011.
G. D. Abowd, A. K. Dey, P. J. Brown, N. Davies, M. Smith, and
P. Steggles, “Towards a better understanding of context and contextawareness,” in Handheld and ubiquitous computing. Springer, 1999,
pp. 304–307.
G. D. Abowd and E. D. Mynatt, “Charting past, present, and
future research in ubiquitous computing,” ACM Trans. Comput.-Hum.
Interact., vol. 7, no. 1, pp. 29–58, Mar. 2000. [Online]. Available:
http://doi.acm.org/10.1145/344949.344988
C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos, “Context
aware computing for the internet of things: A survey,” Communications
Surveys & Tutorials, IEEE, vol. 16, no. 1, pp. 414–454, 2014.
C. Bettini, O. Brdiczka, K. Henricksen, J. Indulska, D. Nicklas, A. Ranganathan, and D. Riboni, “A survey of context modelling and reasoning
techniques,” Pervasive and Mobile Computing, vol. 6, no. 2, pp. 161–
180, 2010.
A. Bikakis, T. Patkos, G. Antoniou, and D. Plexousakis, “A survey
of semantics-based approaches for context reasoning in ambient intelligence,” in Constructing ambient intelligence. Springer, 2008, pp.
14–23.
D. Guan, W. Yuan, S. Lee, and Y.-K. Lee, “Context selection and
reasoning in ubiquitous computing,” in Intelligent Pervasive Computing,
2007. IPC. The 2007 International Conference on. IEEE, 2007, pp.
184–187.
D. Le-Phuoc, H. N. M. Quoc, J. X. Parreira, and M. Hauswirth, “The
linked sensor middleware–connecting the real world and the semantic
web,” Proceedings of the Semantic Web Challenge, 2011.
LogMeIn, “Xively,” http://xively.com/, accessed: 2015-04-10.
C. Perera, A. Zaslavsky, P. Christen, M. Compton, and D. Georgakopoulos, “Context-aware sensor search, selection and ranking model for
internet of things middleware,” in Mobile Data Management (MDM),
2013 IEEE 14th International Conference on, vol. 1. IEEE, 2013, pp.
314–322.
P. Blomqvist, H. Persson, J. Vinterbäck et al., “Self-heating in storages
of wood pellets.” in Proceedings of the World Bioenergy Conference
and Exhibition on Biomass for Energy, Jönköping, Sweden, 27-29 May
2008. Swedish Bioenergy Association, 2008, pp. 172–176.
S. H. Larsson, T. A. Lestander, D. Crompton, S. Melin,
and S. Sokhansanj, “Temperature patterns in large scale
wood
pellet
silo
storage,”
Applied
Energy,
vol.
92,
no.
0,
pp.
322
–
327,
2012.
[Online].
Available:
http://www.sciencedirect.com/science/article/pii/S0306261911007094
A. Rajaraman and J. D. Ullman, Mining of massive datasets. Cambridge University Press, 2011.
J. Zobel and A. Moffat, “Inverted files for text search engines,” ACM
computing surveys (CSUR), vol. 38, no. 2, p. 6, 2006.
Apache
Software
Fundation,
“Apache
Lucene,”
https://lucene.apache.org/, accessed: 2015-04-04.