Context-aware information services provision for IoT environments

(1)

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULTY OF INFORMATICS

GRADUATE PROGRAM IN COMPUTER SCIENCE

CONTEXT-AWARE

INFORMATION SERVICES

PROVISION FOR IOT

ENVIRONMENTS

EVERTON DE MATOS

Dissertation presented as partial requirement for obtaining the degree of Master in Computer Science at Pontifícia Universidade Católica do Rio Grande do Sul.

Advisor: Prof. Fabiano Passuelo Hessel Co-Advisor: Prof. Leonardo Albernaz Amaral

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)

ACKNOWLEDGMENTS

Agradeço primeiramente aos meus pais, Alberto e Rosemari, e a minha namorada, Luana, pelo apoio, paciência e compreensão durante minha pesquisa. Também os agradeço por sempre me incentivarem a estudar e correr atrás de meus sonhos, apoiando todas as minhas decisões.

Agradeço aos meus amigos, e colegas de mestrado, Ramão e Willian pelo companherismo e parceria em todas as etapas do curso.

Agradeço aos meus amigos, Jean, Rafael Maroso e Rodrigo, por estarem presente em momentos difíceis, encurtando as distâncias entre Porto Alegre, Passo Fundo e Belo Horizonte.

(12)

(13)

PROVIMENTO DE SERVIÇOS DE INFORMAÇÃO CIENTES DE

CONTEXTO PARA AMBIENTES IOT

RESUMO

O paradigma da computação Internet das Coisas (IoT) irá conectar bilhões de dispositivos ao redor do mundo em um futuro próximo. Nos últimos anos, a IoT vem ganhando mais atenção. Esse paradigma tornou-se popular por embarcar redes móveis e pelo seu poder de processamento em uma vasta gama de dispositivos computadorizados utilizados na vida cotidiana de muitas pessoas.

Um elemento importante da IoT é o middleware, que é um sistema capaz de abstrair a gestão de dispositivos e prover serviços baseados nestes dispositivos. Os serviços providos são usados por aplicações para obter informações do ambiente. Desta forma, existem muitas pesqui-sas relacionadas com o desenvolvimento de middleware que abordam não só interoperabilidade dos dispositivos, mas também a característica de ciência de contexto. Ciência de contexto é uma carac-terística importante dos sistemas da IoT. Esta caraccarac-terística facilita o descobrimento, compreensão e armazenamento de informações relevantes relacionadas aos dispositivos. Estas informações podem ser usadas para prover serviços e tomada de decisão com base no contexto do ambiente.

Neste sentido, este trabalho apresenta o Context-Aware System (CONASYS), que é um sistema para provimento de serviços de informação contextulizada sobre dispositivos da IoT em ambientes heterogêneos. O sistema é acoplado ao middleware COMPaaS e é capaz de agir conforme o ambiente que está inserido. A arquitetura do CONASYS é apresentada em detalhes, assim como os testes realizados. Nosso objetivo é prover serviços contextualizados que atendam às necessidades dos usuários que não possuem conhecimento especíﬁco do ambiente, melhorando assim a Qualidade da Experiência (QoE).

(14)

(15)

CONTEXT-AWARE INFORMATION SERVICES PROVISION FOR IOT

ENVIRONMENTS

ABSTRACT

The computing paradigm called Internet of Things (IoT) will connect billions of devices deployed around the world together in a near future. In the last years, IoT is gaining more attention. This paradigm has become popular by embedding mobile network and processing power into a wide range of physical computing devices used in everyday life of many people.

An important element of the IoT is a middleware, which is a system able to abstract the management of physical devices and to provide services based on the information from these devices. The services provided are used by application clients to perform queries and obtain environmental information. In this way, it is already a subject in literature studies that address middleware systems not only interoperability of devices, but also context awareness feature. Context-aware is an impor-tant feature of IoT systems. This feature makes easy to discover, understand, and store relevant information related to devices. This information can be used for a reﬁned provision of services based on the environment context and also for decision making.

(16)

(17)

LIST OF ACRONYMS

API – Application Programming Interface

CEP – Complex Event Processing

COMPAAS – Cooperative Middleware Platform as a Service

CONASYS – Context-Aware System

ECA – Event Condition-Action

GPS – Global Positioning System

HTTP – Hypertext Transfer Protocol

IOT – Internet of Things

LHS – Left Hand Side

M2M – Machine-to-Machine

ODMRP – On-Demand Multicast Routing Protocol

ORM – Object Role Modelling

QOE – Quality of Experience

REST – Representational State Transfer

RFID – Radio-Frequency IDentiﬁcation

RHS – Right Hand Side

SOA – Service-Oriented Architecture

SOAP – Simple Object Access Protocol

SQL – Structured Query Language

TCP – Transmission Control Protocol

UDP – User Datagram Protocol

UML – Uniﬁed Modelling Language

URI – Uniform Resource Identiﬁer

WOT – Web of Things

WSN – Wireless sensor networks

(18)

(19)

LIST OF FIGURES

Figure 1.1 – City pollution scenario. . . 27

Figure 2.1 – Generic layered architecture of the Internet of Things. . . 29

Figure 2.2 – Structure of a Rule. . . 37

Figure 4.1 – COMPaaS architecture overview. . . 48

Figure 4.2 – CONASYS layers and modules overview. . . 50

Figure 4.3 – Case study example. . . 52

Figure 4.4 – Interface that shows CONASYS available services. . . 53

Figure 4.5 – CONASYS activity ﬂow. . . 54

Figure 4.6 – The data life-cycle to provide an information service. . . 55

Figure 4.7 – Example of an XML ﬁle with information about a device. . . 56

Figure 4.8 – Example of a Drools rule. . . 57

Figure 4.9 – Overview of CONASYS database modelling. . . 58

Figure 4.10 –CONASYS access through subscription. . . 59

Figure 4.11 –CONASYS access through query. . . 59

Figure 4.12 –Example of an XML that CONASYS must interpret. . . 60

Figure 4.13 –Phases of the Processing Cycle. . . 60

Figure 4.14 –Example of a speciﬁcation report. . . 61

Figure 5.1 – Time taken by the CONASYS function to process rules. . . 64

Figure 5.2 – CONASYS background functions execution time variation. . . 66

Figure 5.3 – Measuring time of real-time processing function divided in three phases. . . 68

(20)

(21)

LIST OF TABLES

Table 3.1 – IoT-middleware comparison. . . 39

Table 3.2 – Context-aware systems comparison. . . 40

Table 4.1 – Comparison between real-time processing and no real-time Processing Cycle ﬂow. . . 61

Table 5.1 – Execution time (ms) for modelling the knowledge base. . . 64

Table 5.2 – Execution time (ms) of the background functions. . . 66

Table 5.3 – Execution time (ms) of the real-time processing function. . . 67

(22)

(23)

1. INTRODUCTION

During the past few years in the area of wireless communications and networking, a novel computing paradigm called Internet of Things (IoT) has gained increasingly attention in academia and industry [39]. By embedding mobile networking and information processing capability into a wide array of gadgets and everyday computing items, and enabling new forms of communication among people and things, and between things themselves, IoT has been adding new dimensions to the world of information and communication technology [6].

Unquestionably, the main strength of IoT is the high impact it has had on several aspects of everyday-life and behavior of potential users. From the point of view of a private user, the most obvious effects of IoT have been in both working and domestic fields. In this context, assisted living, e-health, enhanced learning, and smart cities are only few examples of possible application scenarios in which IoT has been playing a leading role. Similarly, from the perspective of business users, the most apparent consequences have been equally visible in fields such as, automation and industrial manufacturing, logistics, business/process management, and intelligent transportation of people and goods [4].

In IoT, when large numbers of sensor and actuator devices are deployed and start gen-erating data, the traditional device-oriented application approach (i.e., connect sensors directly to applications individually and manually) becomes infeasible, since all the complex responsibility re-garding the management of IoT devices and their data becomes an application role, which can bring scalability problems for large scale scenarios. In order to mitigate this ineﬃciency, signiﬁcant amounts of middleware solutions have been introduced by researchers [35].

Developing middleware solutions in the domain of IoT is an active area of research. In this way, it is available in literature a large number of studies on building up middleware systems addressing interoperability of devices, adaptation, device discovery and management, scalability, management of large data volumes, privacy, and security aspects of IoT environments [8]. Another feature of middleware systems is the context-awareness, that is a challenge of this area according to [35].

(26)

26

In context-aware environments, there is a cycle for the creation of the information that will be delivered to the users, which consists of data acquisition, information modeling, reasoning, and sharing or distribution of contextualized information. Thus, the architecture of a context-ware system must be able to provide services for the integration and automation of all stages of the information cycle. This work aimed to develop a system mechanism to provide context-aware information services to IoT environments. This mechanism is attached to an IoT middleware system which is the reference platform used in this work [3].

Other goal of this work is to provide a system able to produce context-aware information in order to give semantic meaning or context to entities and their data in IoT environments. Entities are persons, places, or objects that are considered relevant to the interaction between users and applications, including the users and applications themselves. The main intention is to avoid the manual user intervention in the interpretation of the data and also facilitates the systems/entities interactions. We also present in this work a study of the deﬁnitions, characteristics, and some components of IoT environments. Besides, we make a research on context-aware IoT systems, which is an important area of the IoT. The analysis of works regarding IoT middleware and context-aware systems is important to identify the next trends in IoT, as well as discover gaps that can be mitigated.

1.1 MOTIVATION

IoT tends to grow and gain space on a global level [4]. As a consequence, the data generated by any type of IoT devices will increase. Besides, even though there have been some IoT systems that provide an amount of context-aware functionality, they do not satisfy all the context requirements demanded by the IoT, since IoT is an evolving computing paradigm that blends couples of heterogeneous system technologies, which diﬃcult the uniﬁcation of the context management [35].

In context-awareness, there are some steps in order to produce context information. In each one of these steps there are diﬀerent consolidated techniques. No standard architecture for contextualization was seen. Therefore, the deﬁnition of a standard architecture to provide context-aware information services is an open issue and remains a topic of extreme importance.

(27)

27

Figure 1.1 – City pollution scenario.

In this work, we aim to identify the context-aware computing requirements and character-istics that are required by an ideal IoT system. Furthermore, we propose a solution able to provide context-aware information services to IoT users and applications in order to satisfy the identiﬁed requirements.

Another motivation is the fact that the COMPaaS middleware to be used as reference platform for this work does not provide context-based services [3], which hinders its diﬀusion for many IoT application areas.

1.2 CONTRIBUTIONS

The main contributions of this work are:

• A detailed state of the art of the Internet of Things and contextualization in IoT environments, that presents the deﬁnitions and techniques of each topic. Moreover, a detailed state of the art of context-aware systems, the features and characteristics of the systems, in addition to a discussion comparing them.

• The deﬁnition of a context-aware architecture composed of context acquisition, context mod-elling, context reasoning and context distribution (i.e., the context life-cycle). This architecture must be possible to be used in an IoT environment.

(28)

28

• The implementation of the context-aware system features in the COMPaaS middleware (i.e., in our reference platform). In this sense, COMPaaS can provide contextualized information services with the context-aware feature.

1.3 WORK SCOPE

This is a research work focused on context-aware in IoT environments in order to provide contextualized information services. The goal is to present the four steps of contextualization that must be used in the IoT context-aware systems to provide information services. In addition, this work presents the implementation of the context-aware approach as a system, called CONASYS, to be attached to the COMPaaS IoT middleware and shows the advantages of data contextualization in IoT environments. This work can be applied to different application scenarios since the context-aware services are requested in every applications. In our approach, the application scenarios can be identified as domains, as healthcare, industry, smart city, just to name a few. The system can be deployed in different domains, since the domain depends on the rules that are inserted in the system. In this sense, the proposed system is domain-specific and for our experimentation and tests we use different domains examples.

1.4 OUTLINE

(29)

29

2. THEORETICAL BACKGROUND

This Chapter introduces concepts and deﬁnitions that are mentioned in this work. Sec-tion 2.1 presents the concept of the Internet of Things. SecSec-tion 2.2 provides an overview of mid-dleware technology. Section 2.3 provides deﬁnitions of the context-aware area and the related chal-lenges. Finally, Section 2.4 shows the context life-cycle process needed in order to obtain context information.

2.1 INTERNET OF THINGS

Internet of Things (IoT) is a novel computing paradigm that is rapidly gaining space in scenarios of modern communication technologies. The idea of IoT is the pervasive presence of a variety of things or objects (e.g., RFID tags, sensors, actuators, smart phones, smart devices, etc), that are able to interact with each other and cooperate with their neighbors to reach common goals through unique addressing schemes and reliable communication media over the Internet [4] [21].

During the past decades, IoT has gained signiﬁcant attention in academia as well as in industry. The main reasons behind this interest are the capabilities that IoT is able to oﬀer. It promises to create a world where all the objects around us (also called smart objects) are connected to the Internet and communicate with each other with minimum human intervention [27]. The ultimate goal is to create a better world for human beings, where objects around us know what we like, what we want, and what we need and act accordingly without explicit instructions [19].

Implementation of IoT environments is usually based on a standard system architecture consisting of several layers [6]: from the data acquisition layer at the bottom to the application layer at the top. Figure 2.1 presents a generic architecture for IoT, adapted from [4].

(30)

30

The two layers at the bottom contribute to data capturing while the two layers at the top are responsible for data utilization in applications. Next, we present the functionality of these layers [6]:

• Edge layer: This hardware layer consists of sensor networks, embedded systems, RFID tags and readers or other IoT devices in different forms. These entities are the primary data sources deployed in the field. Many of these hardware elements provide identification and information storage (e.g. RFID tags), information collection (e.g. sensor networks), information pro-cessing (e.g. embedded edge processors), communication, control and actuation. However, identification and information collection are the primary goals of these devices, leaving the processing activities for the upper layers.

• Access gateway layer: The ﬁrst stage of data handling happens at this layer. It takes care of message routing, publishing and subscribing, and also performs cross platform communication, if required.

• Middleware layer: This layer acts as an interface between the hardware layer at the bottom and the application layer at the top. It is responsible for critical functions such as device management and information management, and also takes care of issues like data ﬁltering, data aggregation, semantic analysis, access control and information discovery.

• Application layer: This layer at the top of the stack is responsible for the delivery of various services to diﬀerent users/applications in IoT environments. The applications can be from diﬀerent industry verticals such as: manufacturing, logistics, retail, environment, public safety, healthcare, food and drug etc.

In the last years, researchers have proposed and analyzed the advantages of using middle-ware systems in the existing solutions for IoT (e.g., management of devices, interoperability). One of the main roles of an IoT middleware is to provide continuous communications among diﬀerent devices and use communication channels characterized by heterogeneous technologies. Furthermore, in some cases the connectivity could be intermittent due to mobility or interferences. In this sense, middleware systems are used to ensure interoperability among several diﬀerent devices and applica-tions, for example: medical instruments, body and environmental sensors, logic applicaapplica-tions, graphic interfaces, etc [9].

2.2 SERVICE-ORIENTED IOT MIDDLEWARE

(31)

31

which is the development of speciﬁc applications enabled by IoT infrastructures [4]. In this way, IoT middleware has received much attention in the last years due to its major role of simplify the development of application and the integration of devices.

IoT middleware systems are required for various reasons. Some reasons are described next [7]: (i) Diﬃcult to deﬁne and enforce a common standard among all the diverse devices belonging to diverse domain in IoT; (ii) Middleware acts as a bond joining the heterogeneous components together; (iii) Applications of diverse domains demand abstraction/adaptation layer; and (iv) Middleware provides API (application programming interface) for physical layer communications, and required services to the applications, hiding all the details of diversity.

Many of the middleware system architectures proposed comply with the Service-Oriented Architecture (SOA) approach. The SOA standard has been used as a viable choice to cope with middleware since it helps to ensure high levels of systems interoperability, providing system services that are based on devices and used by applications. The adoption of SOA principles allows the decomposition of complex systems into applications consisting of a system of simpler and well-deﬁned components. In a SOA architecture, each system oﬀers its functionality as standard services. Moreover, a SOA architecture supports open and standardized communication through all layers of web services that can be used in the IoT [4]. The architecture of a SOA-based IoT middleware is composed of following items:

• Services Provision: This is the highest level middleware layer in which services are available to be used by applications. In this layer there is no notion of devices and the only visible assets are services. Each available service has a respective infrastructure of devices connected to the middleware.

• Management Core: This is the main layer of the middleware. It is composed of functions that allow the management of each device of the environment. The basic set of functions encompasses: dynamic discovery of device, status monitoring, service conﬁguration, data management and context management. This layer can provide a catalogue of services to the upper layer. The upper layer can then compose complex services by joining services provided at this layer.

• Devices Abstraction: This is the lowest layer of the middleware and facilitates the manage-ment of devices through a common language and procedures. This layer is useful because IoT is composed of heterogeneous set of devices, each one providing speciﬁc functions accessible through its own addresses.

(32)

32

2.3 CONTEXT AWARENESS

Context is considered any information that can be used to characterize the situation of an entity [1]. Entity is a person, place, or computing device (also called thing) that is relevant to the interaction between a user and an application, including the user and the application themselves. A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task [1]. In this way, an IoT ecosystem requires a context-aware mechanism to be aware of the environment situation in order to help the user in the most useful way. In various cases, context-awareness becomes a feature of an IoT middleware. For example, when a middleware works based on the environment that it was inserted in.

Several researchers have identified different context types based on different perspectives. Abowd et al. [1] introduced one of the leading mechanisms of defining context types. They identified location, identity, time, and activity as the primary context types. Further, they defined secondary context as the context that can be found using primary context [35]. For example, given primary context such as a person’s identity, we can acquire many pieces of related information such as phone numbers, addresses, email addresses, etc. Some examples defined by Perera et al. are:

• Primary context: Any information retrieved without using existing context and without performing any kind of sensor data fusion operations (e.g., GPS sensor readings as location information, the temperature of a sensor, the amount of oxygen in the air).

• Secondary context: Any information that can be computed using primary context. The secondary context can be computed by using sensor data fusion operations or data retrieval operations such as web service calls (e.g., identify the distance between two sensors by applying sensor data fusion operations on two raw GPS sensor values). Further, retrieved context such as phone numbers, addresses, email addresses, birthdays, list of friends from a contact information provider based on a personal identity as the primary context can also be identiﬁed as secondary context. For example, we can use the data of primary context as the information of a user and the location that he was to inferring the preferences of the user.

2.4 CONTEXT LIFE-CYCLE

(33)

33

2.4.1 CONTEXT ACQUISITION

In the acquisition process, context needs to be acquired from various information sources (e.g., physical or virtual devices). The techniques used to acquire context can be varied based on responsibility, frequency, context source, sensor type, and acquisition process [35].

1) Based on Sensor Types: In general usage, the term ‘sensor’ is used to refer the tangible hardware sensor devices. However, among the technical community, sensors refer to as any data source that provides relevant context. Therefore, sensors can be divided into three categories: physical, virtual, and logical.

• Physical sensors: These are the most commonly used type of sensors. These sensors generate sensor data by themselves. Most of the devices we use today are equipped with a variety of sensor (e.g. temperature, humidity, microphone, touch).

• Virtual sensors: These sensors do not necessarily generate sensor data by themselves. Virtual sensors retrieve data from many sources and publish it as sensor data (e.g. calendar, contact number directory, twitter statuses, email and chat applications). These sensors do not have a physical presence.

• Logical sensors (also called software sensors): They combine physical sensors and virtual sensors in order to produce more meaningful information. A web service dedicated to providing weather information can be called a logical sensor.

2) Based on Responsibility: Context acquisition can be primarily accomplished using two methods [36]: push and pull.

• Push: The physical or virtual sensor pushes data to the data consumer which is responsible to acquiring sensor data periodically or instantly. Periodical or instant pushing can be employed to facilitate a publish and subscribe communication model.

• Pull: The data consumers make a request from the hardware sensor periodically or instantly to acquire data.

3) Based on Frequency: There are two diﬀerent types: Instant and Interval.

• Instant: These events occur instantly. The events do not span across certain amounts of time. In order to detect this type of event, sensor data needs to be acquired when the event occurs. Both push and pull methods can be employed.

(34)

34

4) Based on Source: Context acquisition methods can be organized into three cate-gories [14] .

• Acquire directly from hardware sensor: In this method, context is directly acquired from the sensor by communicating with the hardware sensor and related APIs. Software drivers and libraries need to be installed locally.

• Acquire through a middleware infrastructure: In this method, sensor data (context) is acquired by middleware solutions. The applications can retrieve sensor data from the middleware and not from the hardware sensor directly.

• Acquire from context servers: In this method, context is acquired from several other context storages (e.g. databases, web services) via diﬀerent mechanisms such as web service calls.

5) Based on Acquisition Process: Here are three ways to acquire context: sense, derive, and manually provided.

• Sense: The data is sensed through sensors, including the sensed data stored in databases (e.g. retrieve temperature from a sensor, retrieve appointments details from a calendar).

• Derive: The information is generated by performing computational operations on sensor data. These operations could be as simple as web service calls or as complex as mathematical functions running over sensed data (e.g. calculate distance between two sensors using GPS coordinates).

• Manually provided: Users provide context information manually via predeﬁned settings options such as preferences (e.g. understanding that user does not like to receive event notiﬁcations between 10pm to 6am).

2.4.2 CONTEXT MODELLING

Context modelling is organized in two steps [10]. 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 [13] and [41]. These surveys discuss a number of systems that have been developed based on the following techniques. Each technique has its own strengths and weaknesses.

(35)

35

storage such as less complex application configurations and user preferences. It models context information as key-value pairs in different formats such as text files and binary files. This is the simplest form of context representation among other techniques. They are easy to manage when they have smaller amounts of data. However, key-value modelling is not scalable and not suitable to store complex data structures.

2) Markup Scheme Modelling (Tagged Encoding): It models data using tags. An example of tags can be seen as the fields of an eXtensible Markup Language (XML) file (e.g., <field>). Therefore, context is stored within tags. This technique is an improvement over the key-value modelling technique. The advantage of using markup tags is that it allows efficient data retrieval [13]. Markup schemas such as XML are widely used in almost all application domains to store data temporarily, transfer data among applications, and transfer data among application components. In contrast, markup languages do not provide advanced expressive capabilities to allow reasoning.

3) Graphical Modelling: It models context with relationships. Some examples of this mod-elling technique are Unified Modmod-elling Language (UML) [43] and Object Role Modmod-elling (ORM) [33]. Actual low-level representation of the graphical modelling technique could be varied. For example, it could be a SQL database, noSQL database, etc. Further, as we are familiar with databases, graphical modelling is a well known, easy to learn, and easy to use technique. Databases can hold massive amounts of data and provide simple data retrieval operations, which can be performed rel-atively quickly. In contrast, the number of different implementations makes it difficult with regards to interoperability.

4) Object Based Modelling: Object based (or object oriented) concepts are used to model data using class hierarchies and relationships. The Object Oriented paradigm promotes encapsulation and re-usability. As most of the high-level programming languages support object oriented concepts, modelling can be easily integrated into context-aware systems. Object based modelling is suitable to be used as a non-shared, code based, run-time context modelling, manipulation, and storage mechanism. Validation of object oriented designs is diﬃcult due to the lack of standards and speciﬁcations.

5) Logic Based Modelling: Facts, expressions, and rules are used to represent information about the context. Rules are primarily used to express policies, constraints, and preferences. It provides much more expressive richness compared to the other previously models discussed. There-fore, reasoning is possible up to a certain level. Logic based modelling allows new high-level context information to be extracted using low-level context.

(36)

36

2.4.3 CONTEXT REASONING

Context reasoning can be deﬁned as a method of deducing new knowledge based on the available context [11]. It can also be explained as a process of giving high-level context deductions from a set of contexts. Reasoning is also called inferencing. Broadly, reasoning can be divided into three phases [32]:

• Context pre-processing: This phase cleans the collected sensor data. Due to ineﬃciencies in hardware sensor and network communication, collected data may be not accurate or can be missing. Therefore, data need to be cleaned by ﬁlling missing values, removing outliers, validating context via multiple sources, and many more.

• Sensor data fusion: It is a method of combining sensor data from multiple sensors to produce more accurate, more complete, and more dependable information that could not be achieve through a single sensor [23].

• Context inference: It is a method of generation of high-level (secondary) context information using lower-level (primary) context. The inferencing can be done in a single interaction or in multiple interactions. For example in a situation where the context is represented as tuples (e.g. Who: Leonardo, What: walking:1km/h, Where: Porto Alegre, When: 2016-01-05:11.30am). This low-level context can be inferred through a number of reasoning mechanisms to generate the ﬁnal results. For example, in the ﬁrst iteration, longitude and latitude values of a GPS sensor may be inferred as Rei do Cordeiro restaurant in Porto Alegre. In the next iteration Rei do Cordeiro restaurant in Porto Alegre may be inferred as Leonardo’s favourite restaurant. Each iteration gives more accurate and meaningful information.

Context reasoning techniques are classify into six categories [35]: supervised learning, unsupervised learning, rules, fuzzy logic, ontological reasoning, and probabilistic reasoning.

1) Supervised learning: In this category of techniques, we ﬁrst collect training examples. We label them according to the results we expect. Then we derive a function that can generate the expected results using the training data. Decision tree is a supervised learning technique where it builds a tree from a dataset that can be used to classify data.

2) Unsupervised learning: This category of techniques can ﬁnd hidden structures in un-labelled data. Due to the use of no training data, there is no error or reward signal to evaluate a potential solution.

(37)

37

(see Figure 2.2 ). The rules also supports Complex Event Processing (CEP), which can be broadly deﬁned as being an event processing concept that deals with the task of processing multiple events (e.g., data generation, device update) with the goal of identifying the meaningful events within the event cloud [5].

Figure 2.2 – Structure of a Rule.

4) Fuzzy logic: This allows approximate reasoning instead of ﬁxed and crisp reasoning. Fuzzy logic is similar to probabilistic reasoning but conﬁdence values represent degrees of membership rather than probability [38]. In traditional logic theory, acceptable truth values are 0 or 1. In fuzzy logic partial truth values are acceptable. It allows real world scenarios to be represented more naturally; as most real world facts are not crisp.

5) Ontology based: It is based on description logic, which is a family of logic-based knowledge representations of formalisms. The advantage of ontological reasoning is that it integrates well with ontology modelling. In contrast, a disadvantage is that ontological reasoning is not capable of ﬁnding missing values or ambiguous information where statistical reasoning techniques are good at that. Rules can be used to minimize this weakness by generating new context information based on low-level context.

(38)

38

2.4.4 CONTEXT DISTRIBUTION

Finally, context distribution is a fairly straightforward task. It provides methods to deliver context to the consumers. From the consumer perspective this task can be called context acquisition. There are two methods that are commonly used in context distribution [35]:

• Query: A context consumer makes a request in terms of a query, so the context management system can use that query to produce results.

(39)

39

3. RELATED WORK

In this chapter we make an analysis of two types of related work. First, section 3.1 presents a comparison among IoT middleware systems. Second, section 3.2 presents a comparison among systems that provide context-aware features. The systems of section 3.1 can appear at section 3.2 if it had the context-aware feature. Finally, Section 3.2.2 argue about CONASYS features comparing with others systems.

3.1 IOT MIDDLEWARE SYSTEMS

This section presents and classifies some prominent IoT middleware systems. The idea is to discover the existing gaps in this area of research in order to verify if context-aware is a challenge in this role. Table 3.1 depicts the classifications of these systems according to five key requirements for IoT environments: device management, interoperation, platform portability, context-awareness, security and privacy [8].

Table 3.1 – IoT-middleware comparison.

IoT Middleware Device Management Interoperation Platform Portability Context Awareness Security and Privacy

Hydra X X X X X

ISMB X _- X _-

-ASPIRE X _- X _-

-UbiWARE X _- X X

-ubiSOAP X X X _-

-UbiRoad X X X X X

GSN X _- X _- X

SMEPP X _- X X X

SOCRADES X X X _- X

SIRENA X X X _- X

WhereX X X X _-

-COMPaaS X X X _- X

According to Table 3.1, we can notice that the majority of the analyzed IoT middleware solutions do not provide context-awareness functionality. In contrast, all the solutions are highly focused on device management, which basically involves connecting sensors to the IoT middleware. In the early days, context-awareness was a requirement strongly bounded to pervasive and ubiquitous computing. However, even though there were middleware solutions that provided context-aware functionality, today this scenario is diﬀerent, and most of the existing middleware systems do not satisfy the context requirements demanded by IoT [35].

(40)

40

has a lot of items that can be analyzed. In the next section we evaluate some systems that help ﬁnding the existing gaps in the context-aware area.

3.2 CONTEXT-AWARE SYSTEMS

Table 3.2 presents a comparison between systems with context-aware features. The com-parison covers the main features of context-aware systems according to [35] and [1]. The items used for the comparison are: (1) Modelling, (2) Reasoning, (3) Distribution, (4) History and Storage, (5) Knowledge Management, (6) Event Detection, (7) Level of Context Awareness, (8) Data Source Support, (9) Quality of Context, (10) Data Processing, (11) Dynamic Composition, (12) Real Time Processing and (13) Registry Maintenance and Lookup Services. We only analyzed systems that provide details of these items in the literature. The deﬁnition of each item is given after the table.

Table 3.2 – Context-aware systems comparison. IoT

Systems

Context-Aware Features

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)

Hydra K,On,Ob R,O Q X X X _H _P _V _- _- _-

-COSMOS Ob R Q - - X _H _P _- _A X _- X

SALES M R Q - - X _L _P _- _F _- _- X

C-Cast M R P,Q X _- X _H _A _- _- _- _- X

CoMiHoc Ob R,P Q - X X _H _A _V _- _- _-

-MidSen K R P,Q - X X _H _P _- _- _- _- X

CARISMA M R Q - - - H M C - - -

-ezContext K,Ob R Q X X X _H _A _- _A _- _- X

Feel@Home G,On O P,Q - X X _H _A _- _- _- _- X

UbiQuSE M R Q X _- X _H _A _- _- _- X

-CONASYS K,M R P,Q X X X _H _A _V _F _- X X

1) Modelling

It has been discussed in detail in Chapter 2, Section 2.4.2. The following abbreviations are used to denote the context modelling techniques employed by the system: key-value modelling (K), markup Schemes (M), graphical modelling (G), object oriented modelling (Ob), logic-based modelling (L), and ontology-based modelling (On).

2) Reasoning

It has been discussed in detail in Chapter 2, Section 2.4.3. The following abbreviations are used to denote the reasoning techniques employed by the system: supervised learning (S), un-supervised learning (U), rules (R), fuzzy logic (F), ontology-based (O), and probabilistic reasoning (P). The symbol (X_{) is used where reasoning functionality is provided but the}

speciﬁc technique is not mentioned.

3) Distribution

(41)

41

used to denote the distribution techniques employed by the system: publish/subscribe (P) and query (Q).

4) History and Storage

Storing context history is critical in both traditional context-aware computing and IoT [18]. Historic data allows historic sensor data to be better understood. Speciﬁcally, it allows user behaviours, preferences, patterns, trends, needs, and many more to be understood by using the historic information in order to provide new context. The symbol (X_{) is used to denote}

that context history functionality is facilitated and employed by the system.

5) Knowledge Management

Most of the tasks that are performed by IoT middleware solutions require knowledge (context) in diﬀerent perspectives, such as knowledge on sensors, domains, users, activities, and many more. Knowledge can be used for tasks such as automated conﬁguration of sensors to IoT middleware, automatic sensor data annotation, reasoning, and event detection. The symbol (X_{) is used to denote that knowledge management functionality is facilitated and employed}

by the system in some perspective.

6) Event Detection

IoT envisions machine-to-machine (M2M) and machine-to-person communication. Most of these interactions are likely to occur based on an event. An occurrence of event is also called an event trigger. Once an event has been triggered, a notiﬁcation or action may be executed. For example, detecting current activity of a person or detecting a meeting status in a room, can be considered as events. Mostly, event detection needs to be done in real-time. However, some events such as trends may be detected using historical data, detecting patterns. The symbol (X_{) is used to denote that event detection functionality is facilitated and employed by}

the system in some perspective.

7) Level of Context Awareness

Context-awareness can be employed at two levels: low (hardware) level and high (software) level. At the hardware level, context-awareness is used to facilitate tasks such as eﬃcient routing, modelling, reasoning, storage and event detection [24]. The software level has access to a broader range of data and knowledge as well as more resources, which enables more complex reasoning to be performed. The following abbreviations are used to denote the level of context awareness facilitated and employed by the system: high level (H) and low level (L).

8) Data Source Support

(42)

42

9) Quality of Context

It denotes the presence of conﬂict resolution functionality (C) and context validation func-tionality (V). Conﬂict resolution is critical in the context management domain [20]. Context validation ensures that collected data is correct and meaningful. Possible validations are checks for range, limit, logic, data type, cross-system consistency, uniqueness, cardinality, consistency, data source quality, security, and privacy.

10) Data Processing

Denotes the presence of context aggregation functionality (A) and context filter functionality (F). Context filter functionality makes sure the reasoning engine processes only important data. Filtering functionality can be presented in different solutions in different forms: filter data, filter context sources, or filter events. One of the simplest forms of aggregation of context is just collect similar information together.

11) Dynamic Composition

IoT solutions must have a programming model that allows dynamic composition without re-quiring the developer or user to identify speciﬁc sensors and devices. Software solutions should be able to understand the requirements and demands on each situation, then organize and structure its internal components according to them. The symbol (X_{) denotes the presence}

of dynamic composition functionality in the system in some form.

12) Real Time Processing

Most of the interactions are expected to be processed in real time in IoT. This functionality has been rarely addressed by the research community in the context-aware computing domain, even it being an of the most important context-aware features for IoT. The symbol (X₎

denotes the presence of real time processing functionality in some form.

13) Registry Maintenance and Lookup Services

The (X_{) symbol is used to denote the presence of registry maintenance and lookup services}

functionality in the systems. This functionality allows diﬀerent components such as context sources, data fusion operators, knowledge bases, and context consumers to be registered.

3.2.1 SYSTEMS APPROACHES

Some systems provide context-aware functions to IoT environments. This subsection presents a review about context-aware features of the systems presented in Table 3.2. We also show how these systems generate the context information. The last row of the Table 3.2 presents CONASYS, the system developed by this work.

(43)

43

is a system that enables the processing of context information in ubiquitous environments. COSMOS consists of three layers: context collector (collects information), context processing (derives high level information), and context adaptation (provides context access to applications). COSMOS follows distributed architecture which increases the scalability of the system.

SALES [16] is a context-aware system that achieves scalability in context dissemination. XML schemes are used to store and transfer context. C-Cast [37] is a system that integrates WSN (Wireless sensor networks) into context-aware systems by addressing context acquisition, dissemina-tion, representadissemina-tion, recognizing, and reasoning about context and situations. The data history can be used for context prediction based on expired context information.

CoMiHoc [44] is a framework that supports context management and situation reasoning. CoMiHoc architecture comprises six components: context provisioner, request manager, situation reasoner, location reasoner, communication manager, and On-Demand Multicast Routing Protocol (ODMRP). MidSen [34], as C-Cast, is a context-aware system for WSN. MidSen is based on Event-Condition-Action (ECA) rules. The system has proposed a complete architecture to enable context awareness in WSN.

CARISMA [12] is focused on mobile systems where they are extremely dynamic. Adaptation is the main focus of CARISMA. Context is stored as application proﬁles (XML based), which allows each application to maintain meta-data. The framework ezContext [29] provides automatic context life cycle management. The ezContext comprises several components that provides context, retrieves context, does modelling and storage context.

Feel@Home [22] is a context management framework that supports interaction between diﬀerent domains. Feel@Home decides what the relevant domain needs to be contacted to answer the user query. Then, the framework redirects the user query to the relevant domain context managers. Feel@Home consists of context management components responsible for context reasoning and store context. UbiQuSE [40] (Ubiquitous Queries for Sensing Environments) is a framework to manage streaming, contextual and data mining queries, providing a query interface. UbiQuSE shows how real time query processing can be done incorporating live streaming data and historic context in repositories.

The ﬁrst feature to be analyzed in Table 3.2 is related to systems context modeling. The modeling approaches that more appeared in the comparison were markup schemes, key-value and object-oriented modeling. Modeling through key-value is made by Hydra for simplicity of use [5]. CARISMA uses markup schemes, because the way it models the context can be easily understood, both by machines and by human [12].

(44)

44

analyzed systems use query. However, some systems as C-Cast, MidSen and Feel@Home also oﬀer the possibility of using publish/subscribe as an additional feature.

As shown in Table 3.2, the function of history and storage (4) is a differential of the analyzed systems, only a few systems have this feature. For the C-Cast, the history can be used for context prediction based on expired context information [37]. Another differential feature is knowledge management (5). One of the few that provide this functionality is CoMiHoc. In this system, knowledge is required to overcome the limitations of the environment and to provide reliable support for the applications [44]. Detection of events (6) is a feature provided by almost all systems. When specific context events occurs, event detection takes action such as shutting down if the battery is low [5].

In terms of level of context awareness (7), only one system has a low level, which works with the context in hardware. All other analyzed systems work with context in terms of software, which allows a greater capacity for reasoning [35]. Regarding data source support (8), most analyzed systems support physical sensors. CARISMA supports mobile sensors because it is a speciﬁc solution for this area [12]. A better alternative is to support the largest possible range of diﬀerent sensors, since IoT provides heterogeneous environment [4].

A comparison was made between systems on quality of context (9). A low number of analyzed systems control quality of context. In CoMiHoC the quality of context is addressed by validation that is integrated into the communication protocol [44]. Data processing (10) is another analyzed functionality. Only a few systems perform some kind of processing. SALES uses ﬁltering techniques to reduce traﬃc [16].

Another feature compared between systems was dynamic composition (11). This is only attended by COSMOS [15]. The real time processing (12) becomes a challenge of future context-aware systems, as only one of the analyzed systems had this feature. Finally, the last item used for systems analysis was registry maintenance and lookup services (13). Many of compared systems have this feature. Through it, the systems can have a history of performed processes, thus facilitating future operations [35].

3.2.2 OUR SYSTEM APPROACH

Context-awareness is an important feature of IoT middleware and the process to provide context-aware services encompasses some procedures including: context acquisition, context mod-eling, context reasoning, and context distribution. For all these phases, the selection of techniques that fulﬁll the system’s necessities is essential.

(45)

45

to meet the heterogeneous devices types. In the context modeling, both Key-Value and Markup Scheme techniques were used. These techniques are simple to use and facilitate the organization and storage of the context.

For context reasoning, rules supply the necessities of the system, as it has a good cost-benefit compared to other technologies. Rules are simple to define, have a well-defined structure, and consume few resources (e.g., processing, storage). Finally, to give different options to the user, we intended to provide context distribution by two ways: query and subscription. In this sense, a user can make a simple request or subscribe one or more services by the time that he wants.

Custom context-aware approaches offered by the IoT research community mostly not offer details of its architecture. In Chapter 3, we shown that the context-aware systems have well-defined functions to obtain and provide contextualized information. However, they may differ in terms of architecture and technologies according to the need of the systems. Moreover, just one of the studied solutions address real-time processing of the context, which is considered a gap in the area [35].

The real-time feature of CONASYS appears as a good characteristic. This feature makes the user request be answered in less steps compared with the normal ﬂow (see Figure 4.13). This shortcut reduces the processing eﬀort of the cycle and eliminates the need of create a middleware connection, what could add a communication delay caused by the network.

Comparing with other works, through Table 3.2, we can see that CONASYS is a good alternative to be implemented in IoT environments. CONASYS addresses almost all the context-aware requirements. The real-time requirement, that is a key feature of context-context-aware systems [35], is only addressed by one of the analyzed systems. Although this system addresses real-time, it fails in address other basic context-aware IoT requirements, like the registry maintenance that allows components such as context sources and knowledge bases to be registered. CONASYS can stand out in IoT context-aware scenario as being a complete system.

(46)

(47)

47

4. PROPOSED APPROACH

In this chapter we present the deﬁnitions and characteristics of our context-aware system for IoT environments, CONASYS. Section 4.1 presents our prior work COMPaaS, which was the reference platform used as basis for our context-aware system. Section 4.2 presents all the charac-teristics of CONASYS. Moreover, we present an example of use in addition to some deﬁnitions of the system services provision and a technical overview of the system.

4.1 REFERENCE PLATFORM

COMPaaS (Cooperative Middleware Platform as a Service) is an IoT middleware developed by the GSE/PUCRS [3]. COMPaaS is a software system that provides to users a simple and well-deﬁned infrastructure of middleware services to be used in IoT environments. Behind the services provided by the middleware, there is a set of system layers that deal with the users and applications requirements, for example, request and notiﬁcation of data, discovery and management of physical devices, communication issues, and data management. COMPaaS is the reference platform for this work and will be extended to support the proposed context-aware services provision system. We chose COMPaaS for the easily access to the source code, architecture that supports the services provision, and because COMPaaS did not has context-aware features.

The goals of COMPaaS can be summarized as follow:

• Abstract the integration and interoperability with physical devices (physical resources) through the provision of hierarchical services according to the proﬁle of the device.

• Abstract the collection and management of the data provided by physical devices through the provision of application level services.

• Provide high-level services to facilitate the development and integration of IoT applications.

• Provide well-deﬁned software architecture based on IoT/M2M and WoT (Web of Things) standards.

(48)

48

main ﬂow of information. The idea is to present the communication interfaces, communication patterns, and information that are exchanged between the systems.

Figure 4.1 – COMPaaS architecture overview.

To help the description of the systems we use a simple use case regarding “a generic application requesting data from an RFID reader”. First we describe the main characteristics of the environment and some technical details of the systems. Further, we present the basic interactions and the data exchanged by items.

• The operational environment is composed of the Aplication, Middleware Core, and Logical Device, that encapsulates and controls an RFID reader.

• Each Logical Device provides its own services to the Middleware Core through a standard RESTful API (HTTP protocol for subscription). These services abstract the main methods of each device and allow Middleware Core to send commands like start, stop, subscribe, unsubscribe and join. Each Logical Device must be implemented in order to deﬁne its “proﬁle” and to “encapsulate the low-level API of the device (device driver)”. Thus, the native API of the device can be mapped into the RESTful API.

• Logical Device use a WebSocket channel (a data notiﬁcation service provide by the Middleware Core) for asynchronous responses (TCP-based protocol for notiﬁcation of data). The Web-Socket is used not only to avoid the lack of performance of the HTTP (request-response style), but also to allow that physical devices can notify the Middleware Core without a synchronous request.

(49)

49

• Middleware Core provides its on services to the application through Web Service SOAP. The SOAP is used as the communication pattern between applications and Middleware Core be-cause SOAP is a standard and ﬁts well in scenarios with “medium-performance” in terms of real-time communication requirements. Furthermore, SOAP is “neutral” in terms of transport protocol. It runs over any transport protocol (HTTP, TCP, UDP) and also allows indepen-dence of any client-programming model (loosely-coupled distributed communication pattern) what is an important requirement for the interoperability required by the middleware project.

• WebSocket is used for asynchronous responses from Middleware Core to applications (TCP-based protocol for notiﬁcation of data). The WebSocket is used to allow that the Middleware Core can notify the application without a synchronous request.

• Both systems architectures (Middleware Core and Logical Device) are based on “Subscribe/Notify” and “Observer” communication pattern. “RESTful + WebSocket” for the Logical Device, and “SOAP + WebSocket” for the Middleware Core.

Although COMPaaS has many features in its architecture, it is not able to work according to the context in which it is inserted. An middleware must be context-aware in order to work with IoT environments, which is considered a challenge for these systems [6]. In this way, we intend to address this important challenge providing context-aware features in this system.

4.2 CONASYS: CONTEXT-AWARE SYSTEM

The Context-Aware System (CONASYS) aims to provide to user/application a set of ser-vices of contextualized information by a well-deﬁned structure of features that understands the environment in which the system is inserted and provides services based on this environment, both on-line (i.e., through newest contextualized data) and oﬀ-line (i.e., through historical contextu-alized data). These services are called information services because they provide somehow with data/knowledge/information. The information services must be used independent of the knowledge of the environment. In other words, a user can request the information services without knowing exactly which things or devices will be used in the process to collect/provide the information.

CONASYS interacts with the infrastructure provided by COMPaaS middleware, including the devices connected to it, in order to have access to the IoT environment infrastructure (e.g, devices). Moreover, several instances of COMPaaS middleware may be connected to CONASYS and each one is responsible for dealing with a specific domain (e.g., smart home, smart office, healthcare, and mobile). Each domain should have a specific set of business rules that must be registered in the system.

(50)

50

provision, showing how the system composes the information services that is displayed to the ﬁnal user. We also present the technical overview of the system, focusing in how the system works. Finally, we present an example of system usability in a real use case scenario.

4.2.1 ARCHITECTURAL OVERVIEW

An API was developed to allow users (developers) to interact with the system. In this sense, the users must send an XML ﬁle containing information regarding their requests. In addition to the API, CONASYS provides a system architecture composed of three main layers (see Figure 4.2): Communication Layer, Storage Layer and Processing Layer. Each layer has speciﬁc goals that are presented next:

(51)

51

• Communication Layer: The process of receiving and interpreting the user’s request is made by the Communication Layer. This layer is also responsible for the context distribution process related to context life cycle (send results to users). The Communication layer is composed of three modules: Query, Publish/Subscribe, and Request Interpreter.

The Request Interpreter is responsible for understanding the user’s request and also for start-ing the response process. For example, if a user wants to subscribe a service, the Request Interpreter module communicates with the Publish/Subscribe module informing the user con-tact information. On the other hand, if a user wants to query some information without subscription, the Query module is communicated with the user information. Both Query and Publish/Subscribe modules are responsible for maintaining user contact information and also for sending the request result.

• Storage Layer: This layer is responsible for storing the content of all modules presented in CONASYS. The Storage layer is composed of four modules: Knowledge Base, Speciﬁcations, Devices Information, and Events Information. In addition, the Information Service module belongs to both Storage and Processing Layers. It is shared with the Processing Layer because it has context reasoning functions.

The context modeling phase of context life-cycle can be identified in the Storage Layer. The Knowledge Base module is responsible for storing the context information. Thus, this module has great importance in the system off-line mode, which uses historical data. In some cases, if the desired information is properly updated, the interaction with the middleware is not necessary. In addition, it is also responsible for interpreting the Drools rules [25] of the system, as well as for storing the key parts of each rule. The Specifications module of Storage layer is responsible for storing the information that allows CONASYS to interact with the middleware. The characteristics of each device connected to the middleware are stored in Devices Information module. Finally, the Events Information module stores contents of each event (e.g., change of state, data generation) that happens related to any device connected to the middleware.

• Processing Layer: This layer is very important in the context generation since it is responsible for the context reasoning phase of the context life-cycle. The context life-cycle was explained in more detail at Chapter 2. The processing layer has six speciﬁc modules: Spec Creator, Primary Context, Secondary Context, Reasoning, Event Interpreter, and Device Interpreter.

(52)

52

related to two or more device data. For example, a fusion method can receive the information that two devices data are needed to answer a user request and transform it in a single data. The Event Interpreter module is responsible for receiving events from the middleware. The Device Interpreter module has functions that collect information from devices connected to the middleware. The Reasoning module is responsible for giving meaning (i.e., context reasoning process) to the information collected by Event and Device Interpreter modules.

4.2.2 SYSTEM USABILITY

With the dissemination of the IoT, an increasing number of devices will be connected to the Internet in the coming years. These devices will be of a variety of types, as sensors, tags, and smartphones. Bearing in mind this scenario with heterogeneous devices, we can create a case study. In this case study, CONASYS has a speciﬁc service. This service is responsible for notifying a user of the buses that stop at the user’s nearest station in an smart city environment. In addition, the service is responsible for showing the distance between the bus and the station (Figure 4.3). In this case, the user’s smartphone acts as a source of location data (GPS) as well a consumer of the service provided by CONASYS. The actions are taking automatically by the CONASYS according to the occurrence of events. Moreover, location sensors can be identiﬁed in the buses and in the station for context acquisition.

Figure 4.3 – Case study example.

(53)

53

this list are strictly linked to one or more rules. If one of the devices that compose a service had the status offline (OFF), the service can not be used. A service only can be used if all the devices of the rule that compose a service has the status online (ON). Before that, the user selects the service responsible for informing about the buses. If desired, the user can select more than one service. The second option that must be defined is which type of request has to be performed: Query or Subscription. If the Subscription option is chosen, then it must be specified certain parameters related to the subscription duration time, which are: Duration and Repeat Period. The Duration parameter is a numeric type and indicates the amount of time that the service will be subscribed. The Repeat Period parameter is also of a numeric type and indicates how long it takes to receive new data for the chosen service. However, depending on the type of service, the user can be notified when changes related to the service occurs. The Query option does not have parameters.

Figure 4.4 – Interface that shows CONASYS available services.

From this moment, the user stops the interaction with the system and only waits the request result. CONASYS receives this request and interprets it. After that, the system understands the user needs and communicates with the Information Service in order to ﬁnd out if the information that user requested is stored and updated. However, if the information is not stored or updated, the information capturing process is started, and the system communicates with the middleware in order to collect the data in real-time. The Knowledge module contains the necessary information to know what devices are needed. After the CONASYS collects data from middleware, the system interprets these data and does the real-time processing in order to give context to the event. Thus, through the Drools rules, it is possible to know if the event interests the user, and the notiﬁcation to the user is done. Moreover, if the data requested by the user are part of the knowledge of CONASYS but the system has no rules to treat them, the system has the ability to adapt to this request by creating real-time rules through a preset template.

(54)

54

Figure 4.5 – CONASYS activity ﬂow.

system. These two ways are shown with letters “Q” and “S”. The letter “Q” is when the user sends a request and receives the answer immediately (i.e., query). The letter “S” indicates the ﬂow taken when it is desired to subscribe any available service and receive updates (i.e., subscription).

4.2.3 SERVICES PROVISION

There are two different ways for services provision in CONASYS. The first is when a user sends a request to the system and receives an answer immediately. The second one includes a subscription. In this case the user sends requests to the system informing which services he wants to subscribe. The system monitors these services and notifies the subscriber when the services status change or suffer an update. For the provision of both types of services is necessary to take some steps to have contextualized data. These steps are shown in Figure 4.6 and detailed next.

(55)

55

Figure 4.6 – The data life-cycle to provide an information service.

when sensors do not have knowledge about when to send the data to the consumer. In CONASYS the acquisition process is made through a middleware interface. The CONASYS starts a thread to capture new information (i.e., data) about devices and events related to the environment that it is inserted. In this way, every new event is captured by the system.

The modeling of the acquired context is an important step in CONASYS. The system uses two different types of modeling: Key-Value and Markup Scheme modeling. With the use of Markup Scheme, context can be stored using tags. These tags are related to the main characteristics of the events. With the Key-Value it is possible to use a key in order to make easy the future search for data. In CONASYS, the key of every event is the URI (Uniform Resource Identifier) of the device, because each device has his own and unique URI. For each query on a specific data, the device URI need to be informed. The implementation of these techniques takes place after the acquisition process. The modeled data are stored in a database of the Storage Layer (see Figure 4.2) and be available for the reasoning process.

It is in the context reasoning step that the modeling context is used to generate knowledge. CONASYS uses rules to make this process. After the data was modeled and stored it is possible to reason over these data. The reasoning process is responsible for deﬁning the available services to the users based on the set of rules. The data is contextualized through Drools [25] rules which give a meaning to the event. These rules are in a Working Memory and each event that happens are added to these memory. In this way, if the event meets determinate condition of one or more rules, a sequence of actions is triggered to give meaning to the event. These sequence of actions can be a simple label to the event or a more complex action like run a method.

(56)

56

4.2.4 TECHNICAL OVERVIEW

There are some background functions in the CONASYS that occur before users send their requests. The ﬁrst step is recognize the environment that CONASYS is inserted. CONASYS is strictly connected to an IoT middleware (e.g., the COMPaaS middleware). With a thread that receives all the updates that occur in the middleware, there will be possible to understand the envi-ronment (i.e., devices). These threads monitor the communication channel of the middleware and every time that a device connects/disconnects or update the information with the middleware, it triggers a function to acquire the content and type (e.g., connection, update) of these communi-cations. Figure 4.7 shows an example of a device connection XML that the device sends to the middleware. CONASYS gets this XML ﬁle, understands it, and stores the information in a database (i.e., Storage Layer - Devices Information). The information is stored respecting all the individual characteristics of the device (XML tags). The most important information acquired from the XML is the individual URI, that is the device identity.

Figure 4.7 – Example of an XML ﬁle with information about a device.

Context-aware information services provision for IoT environments

CONTEXT-AWARE

INFORMATION SERVICES

PROVISION FOR IOT

ENVIRONMENTS

EVERTON DE MATOS

PROVIMENTO DE SERVIÇOS DE INFORMAÇÃO CIENTES DE

CONTEXTO PARA AMBIENTES IOT

CONTEXT-AWARE INFORMATION SERVICES PROVISION FOR IOT

ENVIRONMENTS

LIST OF ACRONYMS

LIST OF FIGURES

LIST OF TABLES

CONTENTS

1.

INTRODUCTION

2.

THEORETICAL BACKGROUND

3.

RELATED WORK

4.

PROPOSED APPROACH