COBASEN (COntext-BAsed Search ENgine)
Framework: Discovery of Computing Devices in IoT
Environments
Willian T. Lunardi
1, Everton de Matos
1, Ram˜ao Tiburski
1, Leonardo A. Amaral
1, Sabrina Marczak
2,
Fabiano Hessel
2, Marcelo Thielo
2Pontif´ıcia Universidade Cat´olica 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 develop-ment 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 neces-sary. 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 function-ality 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. INTRODUCTION
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 (aggre-gating) 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 appli-cation 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: environ-mental temperature and environenviron-mental 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.
Fig. 1. COMPaaS architecture overview
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.
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 plat-forms, 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.
II. BACKGROUND ANDRELATEDWORK
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].
A. IoT Middleware
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, high-level system layers as the application layer are composed of
Fig. 2. Example of specification report
IoT applications and middleware system, which is a software layer interposed between the infrastructure of devices and ap-plications, 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.
Many of the system architectures proposed for IoT mid-dleware 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 communica-tion through all layers of web services.
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.
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. In order to get data from devices using COMPaaS, we describe here the necessary interactions and exchange of data [7]:
• The application uses the API to get access to mid-dleware web service interface (SOAP) to define and
subscribe its specification, which contains some im-portant 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 spec-ification 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 informa-tion repository. Finally, the new context informainforma-tion 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. REAL-WORLDCHALLENGE
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 com-mon 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. SYSTEMAPPROACH
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 ar-chitecture. 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.
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.
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. 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}, ”sen-sor”:{1, 2}, ”temperature”:{1}, ”the”:{1, 2}, ”this”:{2}. An-other 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
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].
In COBASEN, the Search Engine is responsible for per-forming the following tasks:
1) To index the list of devices that are received from the Context Module using an Inverted Index strategy; 2) To enable the search of devices through a query with
the utilization of analyzer functions;
3) To enable the selection of one or more middleware devices (aggregation);
4) To generate the specification of the respective devices aggregation created by the user;
5) To send the specification to the middleware; and 6) 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 COM-PaaS architecture (see Subsection II.A). The proposed frame-work 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 re-quest, 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. 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. PROTOTYPEIMPLEMENTATION ANDEVALUATION In terms of evaluation, we assumed that to the achieve-ment 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
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.
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.Durationis the total time of a data collection cycle in the middleware.Data setallows 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 writ-ten entirely in Java. This API can be used to provide consiswrit-tent 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 evalua-tion. 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. 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. DISCUSSION
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 context-based 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
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 environ-ment 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.
These improvements are possible due to the system com-ponents of the COBASEN framework. The acquisition of the devices context characteristics provides the necessary infor-mation 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. CONCLUSIONS ANDFUTUREWORK
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 un-derstand 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 envi-ronments. 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
Our thanks to CAPES/CNPq for the funding within the scope of the project numbers 381657/2014-0 and 058792/2010.
REFERENCES
[1] A. Kevin, “That internet of things thing, in the real world things matter more than ideas,”RFID Journal, vol. 22, 2009.
[2] P. Guillemin, P. Friess et al., “Internet of things strategic research roadmap,” The Cluster of European Research Projects, Tech. Rep., September, 2009.
[3] H. Sundmaeker, P. Guillemin, P. Friess, and S. Woelffl´e, “Vision and challenges for realising the internet of things,” 2010.
[4] 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.
[5] Digital Enterprise Research Institute, “Linked sensor middleware (lsm),” http://lsm.deri.ie/, accessed: 2015-03-26.
[6] GSN Team, “Global Sensor Network,”
http://sourceforge.net/apps/trac/gsn/, accessed: 2015-03-11.
[7] 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 [8] 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. [9] 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.
[10] 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.
[11] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,”
Computer Networks, vol. 54, no. 15, pp. 2787 – 2805, 2010. [12] 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.
[13] G. D. Abowd, A. K. Dey, P. J. Brown, N. Davies, M. Smith, and P. Steggles, “Towards a better understanding of context and context-awareness,” inHandheld and ubiquitous computing. Springer, 1999, pp. 304–307.
[14] 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
[15] 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. [16] C. Bettini, O. Brdiczka, K. Henricksen, J. Indulska, D. Nicklas, A.
Ran-ganathan, and D. Riboni, “A survey of context modelling and reasoning techniques,”Pervasive and Mobile Computing, vol. 6, no. 2, pp. 161– 180, 2010.
[17] A. Bikakis, T. Patkos, G. Antoniou, and D. Plexousakis, “A survey of semantics-based approaches for context reasoning in ambient intel-ligence,” in Constructing ambient intelligence. Springer, 2008, pp. 14–23.
[18] D. Guan, W. Yuan, S. Lee, and Y.-K. Lee, “Context selection and reasoning in ubiquitous computing,” inIntelligent Pervasive Computing, 2007. IPC. The 2007 International Conference on. IEEE, 2007, pp. 184–187.
[19] 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.
[20] LogMeIn, “Xively,” http://xively.com/, accessed: 2015-04-10. [21] C. Perera, A. Zaslavsky, P. Christen, M. Compton, and D.
Georgakopou-los, “Context-aware sensor search, selection and ranking model for internet of things middleware,” inMobile Data Management (MDM), 2013 IEEE 14th International Conference on, vol. 1. IEEE, 2013, pp. 314–322.
[22] P. Blomqvist, H. Persson, J. Vinterb¨acket al., “Self-heating in storages of wood pellets.” inProceedings of the World Bioenergy Conference and Exhibition on Biomass for Energy, J¨onk¨oping, Sweden, 27-29 May 2008. Swedish Bioenergy Association, 2008, pp. 172–176.
[23] 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 [24] A. Rajaraman and J. D. Ullman,Mining of massive datasets.
Cam-bridge University Press, 2011.
[25] J. Zobel and A. Moffat, “Inverted files for text search engines,”ACM computing surveys (CSUR), vol. 38, no. 2, p. 6, 2006.
[26] Apache Software Fundation, “Apache Lucene,” https://lucene.apache.org/, accessed: 2015-04-04.
