A microservice-based smart room application: model and prototype

(1)

University of Pisa

Department of Computer Science

A microservice-based smart room

application: model and prototype

MSc in Computer Science

(ICT Solutions Architect Curriculum)

Candidate:

Alessandro Bocci

Supervisors:

Antonio Brogi

(2)

(3)

Acknowledgements

I would like to express my gratitude to my supervisors, Prof. Antonio Brogi, Prof. Stefano Chessa and Stefano Forti of the Computer Science Department, University of Pisa, who made this work possible, with the patient guidance, encouragement and advice they have provided me throughout the period of my work. I would also like to thank the members of the the Giò Lab, Andrea,

Jacopo and Alessia. We have spent several months working side by side through hard times and funny moments.

I must express gratitude to my mother Isabella and my brother Emanuele, for all the fantastic support they gave me throughout my life, I wouldn’t be here without you.

Finally, I want to thank Caterina, the love of my life, that encourages and endures me daily together with the rest of our family, Bianca and Kate.

(4)

Abstract

This thesis proposes a simple model to design interoperable, goal-oriented, IoT applications with a microservice-based architecture. The model has driven the prototyping of a smart room application coordi-nating an indoor plant irrigation service and an interior light controller service.

(5)

Chapter 1 Introduction

1.1 Context

Nowadays the diffusion of electronic devices has become pervasive [1]. Cyber-physical systems have been deployed successfully in industries, agriculture, cities, private homes and even on people, relying upon connected devices that exchange

data or perform actions in response to sensed events. This multitude of

de-vices constitutes the so-called ’Internet of Things’ (IoT) and it is growing more and more in numbers, computational power and capabilities [2] [3]. Such a phe-nomenon is, for instance, the core of what is called Industry 4.0, smart cities and smart agriculture, permitting the automation of complex decision processes without human involvement [4] [5]. Similarly, in health-care, the IoT is expected to help with live monitoring of patients situations, and techniques of prediction based on the acquired data [6]. Finally, in the home automation field, there are

(8)

1.1 Context

large amounts of data coming from the IoT, closer to both end-users and data sources [7]. The Fog aims at exploiting a continuum of computing capabilities -from personal devices to ISP smart switches, -from micro data centers to the public Clouds - so to improve performances and to suitably support latency-sensitive or bandwidth hungry IoT applications.

In this context the Department of Computer Science, University of Pisa, funded a project, Giò, aiming at realising a Fog computing testbed for research and educational purposes. Among the first goals of Giò there are the design, implementation and actual deployment of three microservice-based IoT applica-tions, namely:

1. GiòPlants, a service that manages the automatic irrigation of a plant, based on the level of soil moisture and it provides the levels of brightness and temperature of the environment to better monitor the plant status,

2. GiòMaps, an interactive map of the Computer Science Department that, through a virtual assistant interface, guide the visitors of the department where they want to go,

3. GiòShader, a service that manages a motorized roller shutter to bring the levels of natural brightness to the desired ones by the users, and

4. GiòRoom, orchestrating 1 and 3 so to realize a system that satisfies users’ expressed goals exploiting the capabilities offered by those two services. As we will better detail in the rest of the next sections of this chapter, this thesis focuses on the design, implementation and assessment of the latter two systems, viz. GiòShader and GiòRoom.

(9)

1.2 Considered Problem

The context we have described so far is characterized by a large diffusion of IoT devices which are heterogeneous in the communication protocols and technologies they feature [8]. Often a device can interact only with another one of the same vendor or implementing the same protocols. This might prevent people to buy devices with desired capabilities but incompatible with those already in their possession and it can be even more problematic for companies that buy tools in large batches.

Resolving those compatibility problems can enable to build more interesting applications that use the devices. From the point of view of the final users, we can imagine expressing a will in natural language to make it automatically fulfilled by the devices, for example: "I want a comfortable living-room" so a relaxing background music starts, the temperature is regulated to a sensation that is optimal for the person in the room and the artificial light is adjusted to be suitable for the eyesight. Similar scenarios can be imagined for every possible IoT-enabled environment, from industrial to agriculture fields, from health-care to domotics.

From the point of view of applications developers, resolving the problems of the communication of the underlying devices can make reusable the applications in different environments with similar capabilities and compose them to create new and more usable ones. For example, with an application oriented to the artificial light management and another one that controls the windows of a room,

(10)

1.3 Thesis Objectives

Broadly speaking, we can classify IoT devices in sensors and actuators, the former measuring data in the cyber-physical systems, the real world, the latter doing actions to interact with these systems [9]. So the natural way to deal with them for automatic systems is to use the sensors to "feel" the real world as we use our five senses and to use the actuators to "do something" as we do, for example, with our hands. In this work, the sensed values and the actions that can be performed are treated side by side with the goals, because we believe that is the combination of these three that can permit to realise a goal-oriented application. Overall, the research problems we address with this thesis can be summarized as follows: end-users with little or no knowledge and interest of configuration will often be the only humans who are present at deployment, runtime, and

maintenance of IoT systems. Having the possibility to only express goals in

natural language to see them automatically satisfied by a system is an interesting problem that can be achieved by enhancing interoperability and composition of IoT systems.

1.3 Thesis Objectives

To face the diffusion, the mobility and the large number of the IoT devices,

we thought to exploit a microservice architecture. Microservices are services

built around single business functionalities that communicate using web protocols to be programming language agnostic. Their features of major interest in our context are the ease of communication between microservices and the horizontal scalability, i.e. the possibility to replicate the microservices with the growing of need of their functionality without touch their communication partner. So adding a great number of IoT device to a microservice-based system can be managed to exploit the horizontal scalability.

(11)

1.4 Thesis Outline

The objective of this thesis is two-fold. First, is to research the IoT field to enhance the interoperability of the devices and the microservice oriented architec-tures, sketching a pragmatical model that tries to enable composition of existing services and to be focused on the users’ goals. Second, to validate this model, a prototype has been developed, that is an application inside the Giò project, composed of several microservices with the aim to control a shutter, to interface with a smart vase and to mix them together in a "room" application that re-ceives goals from users. The functionalities of this application are defined with software engineering techniques involving the real users, that are the people of the Department of Computer Science.

1.4 Thesis Outline

The rest of this manuscript is organized as follows:

Chapter 2, a basic background to make the reader understand better the context of the thesis,

Chapter 3, the main one, where the sketched model to prototype a goal-oriented system based on IoT devices is illustrated, together with the design and implementation of the microservices realised,

Chapter 4, explains the case study, with the testbed of the project and the techniques to deploy, test and assess the work done, and

(12)

Chapter 2 Background

This work focuses on developing an approach to enhance IoT device interoper-ability with a microservices-oriented architecture giving importance to final users goals using a Fog testbed to deploy the developed prototype. To define a base background, this chapter will bring fundamentals of IoT and some notions of (micro)service-oriented architectures will be given before focusing on the goal-oriented paradigm. Ere concluding with a brief explanation of Fog computing, some possible conflicts between goals that could appear in this system will be described.

2.1 Internet of Things and Fog Computing

Internet of Things (IoT) is an expression to intend a global infrastructure for the information society, enabling advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies [10]. In practice, the "things" are all the devices on the boundary between the real world and the information world that can commu-nicate through the net and can operate without the human direct interaction [10].

(13)

2.1 Internet of Things and Fog Computing

The most notable examples are sensors and actuators. Sensors are little devices that sample one or more physical properties, such as temperature or humidity, and send to others, generally more complex, devices through the net. The actua-tors are devices that interact with the physical world and can receive orders from the net, for example, controllers of engines, water pumps or even thermostats are actuators.

IoT has now a wide range of life applications such as industry, transportation, logistics, healthcare, smart environment, as well as personal, social gaming robot, and city information [11]. The devices can have wired or wireless connections. The main wireless communication technologies and protocols that can be used to connect the smart device are Internet Protocol (IP) over Low power Wireless Personal Area Networks (6LoWPAN), ZigBee, Bluetooth Low Energy (BLE), Z-Wave and Near Field Communication (NFC). They are short-range standard network protocols, while SigFox and Cellular are Low Power Wide Area Network (LPWAN) standard protocols [11]. Besides those low-level communication pro-tocols, in IoT applications are used different message-level propro-tocols, like HTTP, CoAP, MQTT or AMQT [12]. This heterogeneity in the communication makes interoperability crucial to permit the building of applications that want to make large use of the IoT systems. Another crucial point regarding the IoT is that the devices generally have low computational and storage resources and often are battery-powered, so the use of those resources, together with the network one, is very important to not drain the energy, making the devices inoperative.

(14)

re-2.2 Microservices

the network [7], helping the QoS of applications (e.g. lowering the latency) and supporting the main characteristics of IoT, like mobility and geographical dis-tribution. Fog computing distributes computation, communication, control and storage closer to the end-users along the cloud-to-things continuum [14]. The description of the testbed representing our fog nodes is in Chapter 4.

2.2 Microservices

The microservice architectural style [15] is an approach to developing a single application as a suite of "small" services, each running in its process and commu-nicating with lightweight mechanisms, often an HTTP resource API, like REST. These services are built around single functionalities and are independently de-ployable. There is a bare minimum of centralised management of these services, which may be written in different programming languages and use different data storage technologies.

[16] define microservice architectures as “a distributed application where all its modules are microservices”. The commonly agreed on benefits of this style in-clude: increase in agility, developer productivity, resilience, scalability, reliability, maintainability, separation of concerns, and ease of deployment. However, those benefits come with challenges, such as discovering services over the network, se-curity management, communication optimization, data sharing and performance [17].

Microservices often emphasises loose coupling of components, to make appli-cations more resilient and their components more reusable, by reducing explicit data and control flow dependencies between services.

The communication in microservice architectures generally use REST (Rep-resentational State Transfer) [18], an architectural style to favour lightweight

(15)

2.3 Goal oriented paradigm

message exchange protocols between services.

2.3 Goal oriented paradigm

The concept of "goal" and "belief" in Computer Science is generally treated in Artificial Intelligent fields, more precisely they talk about Planning or Agent-based systems. The literature defines beliefs as the states of the agents that are considered true that are used to reach the desired goals, that are also considered part of the truth. The beliefs can be inconsistent with each other instead, the goals must be consistent [19]. Planning is the task of finding a procedural course of action for a declaratively described system to reach its goals while optimizing overall performance measures[20]. [21] defines an agent as anything that can be viewed as perceiving its environment through sensors and acting upon that

environment through actuators. An agent can make rational decisions based

on what it believes and what it wants. Agents can make decisions in contexts in which uncertainty and conflicting goals leave a logical agent with no way to decide, a goal-based agent has a binary distinction between good (goal) and bad (non-goal) states, while a decision-theoretic agent has a continuous measure of outcome quality.

[22] propose the Distributed Goal-Oriented Computing, individuating three approaches to put together agents and services because the authors sustain that there is no conceptual distinction between agents and services. The first approach states that both are active building blocks in a loosely coupled architecture, the

(16)

2.4 Negotiating goal conflicts

in a service-based framework where the goal-oriented computing approach is used.

2.4 Negotiating goal conflicts

In an environment with multiple users, multiple devices and multiple services that want to achieve their goals, it is not difficult to generate conflicts between goals. The more simple conflict is the declaration by the same user of two contrasting things, for example, "Turn on the lights" and "I want maximum darkness in this room". This conflict can be resolved considering only the last will expressed by the user.

When the conflict of goals is between multiple users the things became more complex, using the previous example but with the statements said by different people, we need something more to resolve the conflict. This "something more" is individuated in a resolution policy, a rule the decides which goal will be satisfied or if something in the middle will be done. Another way to resolve the conflict can be a negotiation between the parties that decides what course of action will be undertaken. The difference is that a policy is static, predefined, instead, the negotiation is dynamic, decided at runtime. This work starts considering the use of the policies, promising to research in the future the possibility to include the negotiation.

The last source of conflict considered in this analysis is the race conditions on actuators, for example, a user turns on the lights with a remote from outside the room and another one uses a switch inside the room to turn them off. In this case, the users are not aware of each other and cannot negotiate or apply a policy. To resolve this conflict we see two possible choices, create a single way to use the lights, for example, preventing the use of a remote, or preventing that the users can be unaware of each other, perhaps not allowing to use a remote outside

(17)

2.4 Negotiating goal conflicts

the room. In this work, we assume that an actuator is managed by a service that becomes the single entry point for issuing commands to the actuator, in this way there is no possibility of race conditions since the commands are executed in sequence.

(18)

Chapter 3 Design and Implementation

In this chapter, we start by proposing a simple model that can be used to drive the design of goal-oriented IoT services (Sect. 3.1). Then, we describe the require-ments elicitation process that we carried for the actual IoT services GiòShader and GiòRoom (Sect. 3.2), and we discuss how the model we first described was used to drive their design and implementation (Sect. 3.3 and Sect. 3.4).

3.1 Modelling IoT services

To address the problem of communicating with IoT devices from different vendors, (with their specific protocols and technologies), there is a need to create a field in which different IoT services speak the same language and thus enable service users to express their goals uniformly.

In this context, we sketched a model to guide the development of microser-vices that manages IoT demicroser-vices and to exploit the characteristic of microservice architectures to improve the interoperability of such devices. In order to embed user goals and their satisfaction, each microservice implements a system to deal with users goal and expose an API to permits the interaction with such system.

(19)

3.1 Modelling IoT services

Such a model, which we named ’GASP’, would naturally - as per microser-vices principles - enable service interoperability. The REST API of any GASP microservice can expose a set of different operation relating to one of the following types (from which the GASP acronym):

• Goals, which is the set of operations related to the users’ goals, i.e. add, modify, read or delete goals. The G element is in direct contact with a user (through a suitable interface) and it constitutes the goals system, the main part of the logic of the entities,

• Act, which is the set of actions executable by actuators, • Sense, which is the set of values sampled by the sensors, and

• Policies, which represent the possibility to read or set a policy. The policies are optional, they are needed only if the goals can generate conflicts, for example with goals expressed by multiple users.

Figure 3.1 shows the graphical representation of a GASP-designed service. The topmost part of the figure represents the operations exposed by the service, categorized into either G, A, S or P. To sense a value or to do an action, a GASP entity must be able to communicate with a thing, directly or through other services as shown in the bottom part of the figure.

(20)

G A S P

Device

}

API

}

IoT requirements

Figure 3.1: Graphical representation of a GASP

Goals can be set on properties that the entity can read from some sensors and possibly influence with connected actuators. For example, a GASP entity can satisfy a goal on a certain temperature range if can sense the temperature and can turn on the air conditioner. It is worth noting that sensors or actuators can be directly connected to a GASP service or be reached through other services that expose a suitable S and A operations, respectively. A goal can be expressed as shown in Listing 3.1, in which we can see the principals fields of a goal:

• User, in which is represented who has expressed the goal with its identifier and name,

• Conditions, which represent Boolean expressions that determine if a goal is active, and

• Boundaries, which, for every property, give the range of values that satisfy the goal.

(21)

Listing 3.1: The structure of a goal

" u s e r " : { t h e u s e r who e x p r e s s e d t h e g o a l } , " c o n d i t i o n s " : { c o n d i t i o n s i n which t h e g o a l i s a c t i v e } , " b o u n d a r i e s " : { b o u n d a r i e s on t h e p r o p e r t y t o s a t i s f y }

When a goal is set a GASP entity stores it and checks periodically its ac-tivation and if the conditions are not satisfied the goal is "inactive", else it is active and it competes with others goals of the GASP. The boundaries are inter-vals in which the measured value of a property should stand to consider a goal satisfied. A property is "something" measurable by the sensors and influenceable with actuators. Every entity should operate to satisfy its goals, competing and cooperating with others using sensing to acquire information of the real world and actuation to interact with it. Listing 3.2 shows a concrete example of a goal, with the user, the conditions of activation of the goal (from 8 AM to 8 PM) and the property with the desired objective range. So the goal is active when the current time is between the specified values and it is satisfied when the TEMPERATURE property is between the specified boundaries (temperature from 18 to 22).

(22)

Listing 3.2: Example of a goal

" u s e r " : {

"name" : " John ␣Doe" } , " c o n d i t i o n " : { " t i m e " : { ">" : " 0 8 : 0 0 " , "<=" : " 1 9 : 5 9 " } } , " bounds " : {

"TEMPERATURE" : { " lowerBound " : 1 8 , " upperBound " : 2 2 } }

In the current version of GASP, we put some constraints on service composi-tion so to keep the goals system as simple as possible and to guarantee interop-erability. Particularly, a GASP that uses S or A of another service inherits those operations and disables the G and the P of the other service. As a consequence only the topmost entity has G and P enable in its API.

Figure 3.2 shows a GASP ecosystem so to illustrate the bottom-up process that permits building a new application by composing services that have S and A active. In Figure 3.2a there is a GASP that controls the air conditioner and

another one that controls the temperature sensor and the artificial light. In

Figure 3.2b those services are composed into a new GASP that adds a light sensor and can interact with brightness and temperature, permitting to express and satisfy goals on those properties. In what follows, we will refer to services that communicate directly with devices as Drivers. Such services have the important function of abstracting the protocols and the underlying technologies of actuators and sensors, permitting to include them in a GASP application. In the current

(23)

3.2 Requirements Elicitation for GiòShader and GiòRoom

version of the model, we allow only one topmost service as the entry point API of the final application for its users.

G A S P G A S P

(a) Two GASP standalone drivers

G A S P

(b) Composition in a new GASP appli-cation

Figure 3.2: Composition of GASP entities

In the next sections, after dismissing the requirements elicitation process for two actual IoT services, we show the GASP model in action on their design and implementation.

(24)

to the potential users of the system, in order to perform informal semi-structured interviews and to produce our requirements. Those surveys are useful to have a guideline to the interviews, offering hints to the users to generate possible ideas and to show our point of view of the possible capabilities that the system should have.

Listing 3.3 shows the survey targeting potential users of:

• GiòShader, which has to manage a roller blind, exposing an API usable by a conversational virtual assistant.

• GiòRoom, which has to manage several IoT devices in a room to satisfy goals expressed by the users, implementing a GASP microservice.

Listing 3.3: Survey for smart shader

1 ) How many t i m e s do you c h a n g e t h e b l i n d s s e t t i n g s ? − 1 t i m e i n a day

− 2−3 t i m e s i n a day − More t h e n 3 t i m e s i n day

2 ) Why do you c h a n g e t h e s e s e t t i n g s ? To m o d i f y : − The BRIGHTNESS o f t h e room

− The TEMPERATURE o f t h e room − Both o f them 3 ) Do you f o l l o w a p a r t i c u l a r r o u t i n e t o manage t h e b l i n d s ? I f so , d e s c r i b e i t : Open a n s w e r 4 ) Do you f i n d e a s i l y an a g r e e m e n t w i t h t h e o t h e r members o f t h e room a bo ut t h e b l i n d s s e t t i n g s ? − Yes − No

5 ) Would you l i k e t h i s p r o c e s s t o be automated a c c o r d i n g t o t h e p r e f e r e n c e o f t h e members o f t h e room ?

− Yes − No

(25)

The interviews were proposed to:

• 3 members of the administration office of the Department, • 2 Supervisors of the Department plants, and

• 5 Department office members.

We started with the prepared script of questions but adapt these according to the responses that we got from different people. The interviews were good for getting an overall understanding of what users do, how they might interact with the new system and the difficulties that they face with current systems.

Afterwards, we produced a document with user stories based on the content of the interviews, using Connextra format [25]:

As a hrolei I can hcapabilityi so that hreceive benef iti

Table 3.1 lists all user stories related to GiòShader, being it a simple service, they describe all operations that the user can perform with the roller shutter so to adjust the room natural brightness and other related properties (e.g. temper-ature). So we can see that there are the operations to move the height of the roller shutter, e.g open, close, go to a position, and the request to set a daily routine to automatize the movements. Table 3.2 lists the user stories related to GiòRoom, which revealed the need to have an administrator user to decide the policies to resolve the conflicts of the room members’ goals and a room user. We

(26)

Table 3.1: User stories of GiòShader

AS A Room User I CAN close the shader SO THAT Avoid direct sunlinght

in the room

AS A Room User I CAN tilt open the

shader SO THAT

I can read something on paper

AS A Room User I CAN open the shader SO THAT I can have full light in

the room

AS A Room User I CAN open\close the

shader SO THAT

I can lower\increase the temperature

AS A Room User I CAN stop the moving

shader SO THAT

I can do a different action on it

AS A Room User I CAN

change the opening percentage of the shader

SO THAT I can change the brightness

in the room

AS A Plant supervisor I CAN open\tilt the shader SO THAT I can give the right amount

of light to the plants

AS A Room User I CAN set a routine SO THAT I can have the shutter position

automatically arranged

Table 3.2: User stories of GiòRoom

AS A Admin I CAN set the policies

of the room SO THAT

contrasting users goals can be resolved

AS A Room user I CAN set a desired

shading routine SO THAT

I can avoid the direct sunlight when the sun face my window AS A Room user I CAN set a brightness

goal SO THAT

I can have the desired brightness in my room AS A Plant supervisor I CAN set the vase

requirement SO THAT

the system manage the plants in the room AS A Room user I CAN act directly

on the shader SO THAT

fulfil a brightness goal directly AS A Room user I CAN request the

temperature SO THAT

I can now the temperature

From all these user stories, we produced the use case diagrams. Figure 3.3, that graphically depicts the actors and the functionalities of the two services.

The GiòShader microservice will be used by room members of offices with the smart blinds or by a plants supervisor that takes care of plant near a smart roller

(27)

3.2 Requirements Elicitation for GiòShader and GiòRoom Room user Plant Supervisor System: GioShader Open shader Close shader Stop shader Tilt shader Set a routine

(a) Use Case diagram of GiòShader

Administrator

System: Giò Room

Set a new Goal

Actuate the shader

Change Policy Request the temperature

Irrigate the vase Room member

\ Plant supervisor

(b) Use case diagriam of GiòRoom

Figure 3.3: Use case diagrams

shutter. The operations that the service offers are common to both the actors and are the expected ones by a roller shutter:

Open the roller shutter, bringing all the strips to the top of the frame window, Close the roller shutter, bringing all the strips to the bottom of the frame

win-dow, closing the angle of the strips,

Tilt the angulation of the strips, offering the choice of 4 possible levels, close, low, medium and open,

(28)

3.3 Architecture Overview

Set a goal that concern the height of the strips at determined hours, i.e. "I want 40% of strips height from 10 AM to 5 PM".

How those operations are implemented will be explained in details in section 3.4.2.

GiòRoom is usable principally by a room member or a plant supervisor that can set a goal to make it satisfied by the GASP or can access directly the actuation or the sensing functionalities. Naming those goals, such users can:

Set a goal regarding natural brightness of the room, imposing a lower bound and an upper bound in which the brightness should be regulated,

Set a goal regarding the moisture of the vase soil, setting a lower bound and an upper bound in which the moisture should be regulated,

Set a goal with hour condition giving a start time and a stop time in which the goal set should be active, and

Set a goal with presence condition giving the indication that the goal should be active if the user is present in the room.

The possibility of having multiple users calls for the need to have resolution policies, which can be decided by an administrator, an actor with special per-missions that stands above the room members. For instance, an example policy could be the choice to use the average values from to different goals boundaries. How those functionalities are implemented is explained in details in Section 3.4.3.

3.3 Architecture Overview

In this section, we describe the architecture of the GiòRoom system, a sub-part of the Giò project, that allows the users to manage indoor plants and natural brightness. Then, the GASP view of the system is showed and explained.

(29)

3.3.1 Big Picture

Figure 3.4 shows a high-level representation of the architecture of GiòRoom.

GiòRoom GiòPlants GiòShader Vocal assitant ROOM MEMBER ADMIN WEB GASP adapter

(30)

GiòPlants is a system developed by another member of the Giò project, it man-ages a smart vase that offers the irrigation operation and exposes sampled values of temperature and brightness of the environment and the moisture of the soil in the vase.

GASP Adapter is the adapter to the GASP world of GiòPlants. It implements a goals system regarding the soil moisture and offers the common API of the GASP microservices exploiting what GiòPlants offer.

GiòShader is the system that manages the roller shutter, reading its state and sending actuation commands. It implements a goals system regarding the roller shutter’s strips position and is itself a GASP microservice.

GiòRoom is the top-level component that interacts with the things through the other services and receives inputs from the two possible kinds of users: admins and room members. The admins must authenticate through a web site and can contact GiòRoom specifying the policy to resolve multi-user goals conflicts. The room’s members express their goals or interact with sensors/actuators, using devices with vocal assistants. Given a set of goals and one policy, GiòRoom checks the status of the room read from the sensors and, if the goals are not satisfied, use the actuators to bring the status of the room in an acceptable one.

Web Interface Which is the tool used by an administrator to set the policies of the room.

If a user wants to use an actuator directly, it can give a direct order disabling temporarily the goals system. Some of the sensed values of the room are accessible directly by the room users, such as the temperature of the environment.

(31)

3.3.2 A GASP View of GiòRoom

Figure 3.5 switches to the GASP view of the architecture of GiòRoom.

GiòPlants Vocal Assitant ROOM MEMBER ADMIN WEB GiòRoom GiòVase

(VaseDriver) (ShutterDriver)GiòShader

G A S P

A S A S

G P G P

Figure 3.5: GASP view of GiòRoom

(32)

com-3.3 Architecture Overview

while ShutterDriver is a service that manages the roller shutter directly (and is part of this thesis work). In this way, the top-level service is only communicating with GASP services and it is totally oblivious of the devices and their technolo-gies, thus realising interoperability. If the drivers were standalone, their G and P would be enabled, permitting to set goals and policies. GiòVase could satisfy goals about the vase moisture and GiòShader could satisfy goals about the blind height.

[GET] /height: it

returns the percentage of the height of the strips of the roller shutter.

[GET] /tilt: it returns the

level of the strips of the shutter from: (0) dark, (1) low, (2) medium, (3) bright.

[PUT] /open: it moves the

strips to the higher position in the window frame.

[PUT] /close: it moves the

strips to the lower position of the window frame.

[PUT] /goto?pos=x: it

moves the strips to the x height position.

[PUT] /tilt?pos=x: change

the x level of the slats, x = [0, 3].

[PUT] /stop: arrests the

motion of the roller shutter.

G A /act S /sense P /api

Figure 3.6: Operations of GiòShader

G A /act S /sense P

[PUT] /watering: it

irrigates the vase increasing the soil moisutre.

/temperature: it returns

the temperature of the environment next to the vase.

/brightness: it returns

the brightness of the environment next to the vase.

/moisture: it returns the

soli moisture of the vase.

/api

Figure 3.7: Operations of GiòVase

(33)

Those operations are almost all those featured by the composed services, GiòVase and GiòShader. Additionally, Policies operations are offered to the users via a connected web interface, and Actuate, Sense and Goals are callable from a Voice User Interface. A room user can express goals about the brightness of the room and the vase moisture, it can query the room temperature or brightness and take complete control over the cyber-physical systems by ordering to move the roller shutter or irrigate the vase.

[PUT] /shutter/open: it

moves the strips to the higher position in the window frame.

[PUT] /shutter/close: it

moves the strips to the lower position of the window frame.

[PUT] /shutter/goto? pos=x: it moves the strips to

the x height position.

[PUT] /shutter/tilt? pos=x: change the x level of

the slats, x = [0, 3].

[PUT] /shutter/stop: arrests

the motion of the roller shutter.

[PUT] /vase/watering: it

irrigates the vase increasing the soil moisutre.

[GET] /temperature: it

returns the temperature of the environment next to the vase.

[GET] /brightness: it

returns the brightness of the environment next to the vase.

[GET] /vase/moisture: it

returns the soli moisture of the vase.

[GET] /height: it returns

the percentage of the height of the strips of the roller shutter.

[GET] /tilt: it returns the

level of the strips of the shutter from: (0) dark, (1) low, (2) medium, (3) bright.

[GET] /: returns the list

of the set goals.

[POST] /: add a new

goal related to brightness or vase moisture.

[GET] /{id}: returns the

goal by id = {id}.

[GET] /user? id=x: returns the goals

of the user with id=x.

[Delete] /{id}: delete the

goal with id = {id}.

[Delete] /user?id=x:

delete the goals the user with id=x.

[PUT] /avg: set the

avarage as policy of the room.

[PUT] /priority: set the

priority as policy of the room.

[PUT] /schedule: set the

schedule as policy of the room.

[GET] /: it returns the

current policy.

G /goals A /act S /sense P /policy /api

Figure 3.8: Operations of GiòRoom

The current version of GiòRooms feature the policies to negotiate among different users of the same room. The conflicts between goals from the same user are resolved considering only the last one that was set. Indeed, if a new goal has the same user and the same activation conditions of others previously set, the

(34)

3.4 Implementation Details

of each goal, if such intersection does not exist, then the rule stated by the policy is applied with the result of obtaining a single range on the property that becomes part of the goal state. The policies that are embedded in the current version of GiòRoom are:

• average, which calculate the center of each boundary and calculate the average of every center, taking the minimum range extension,

• priority, which need the list of the users in priority order to favourite the goals of the more "important" users,

• schedule, which add to the priority the possibility to be scheduled in different time slots with different priority lists.

Possible race conditions on actuators are resolved by using the drivers as single entry point to handle the devices and the top-level microservice (GiòRoom) as the only entity to manage the goals of the users. Doing so, we avoid having multiple contrasting actuation commands toward the same actuator, since all received commands pass through a single driver (i.e. the top-level microservice), thus avoiding conflicting contemporary requests.

3.4 Implementation Details

All implemented microservices, GiòRoom, GiòVase and GiòShader, are written in Java language, exploiting Spring Boot [26] as a framework to manage the common web technologies. To realise the GASP model, all of them expose a RESTful API

like the one shown 1 _{in Listing 3.4.}

1_{The current implementation assumes that an IP address is associated with each room.}

Future extensions to the prototype will include the possibility of managing more rooms at the same IP.

(35)

Listing 3.4: Base REST API

h t t p : / /ROOM_IP: p o r t / a p i / g o a l s h t t p : / /ROOM_IP: p o r t / a p i / a c t h t t p : / /ROOM_IP: p o r t / a p i / s e n s e h t t p : / /ROOM_IP: p o r t / a p i / p o l i c y

The collected user requirements gave us the information that the actuation should not be exclusive of the goals system, as the users want to be able to act directly on the available IoT devices. The actions of a user could conflict with those taken by the goals system, so we choose to disable the goals system wherever a user performs directly an actuation. To enable again the goals system, an explicit request is needed or a new goal should be set.

The common schema of the microservices is sketched in Figure 3.9.

G ENDPOINT A ENDPOINT S ENDPOINT P ENDPOINT GOAL SYSTEM Configuration ENDPOINT

(36)

The main components of a GASP microservice are:

Goals System is managed by the main thread that is the one that periodically

checks the actual state again the set goal state. The goal state is the

principal objective of the goals system and it consists of the combination of all the active goals resulting in a unique range for each property, in which every sensed value must stay to be considerate the state satisfied. If the goal state is not satisfied, there is a decision-making phase to choose what actions to take to try to fulfil it. The remaining logic is managed through the REST API.

The sensing endpoint deliver the samples without interfering with the central logic.

The actuation endpoint notifies when the goals system should be disabled to avoid conflicts as explained in Section 3.3.

The goals endpoint has the most interaction with the central logic because the list of goals expressed to the GASP service is shared between them.

The policies endpoint is also involved directly with the main logic because the information on which policy to use to resolve conflicts between users is crucial to generate the goal state.

The configuration endpoint is exposed to help the management of the com-munication between the microservices and permits to set at runtime the IP addresses and the ports of the other services that must be contacted. For example, if GiòShader is deployed to a different location, it is possible to call the configuration endpoint of GiòRoom setting the new location of the GiòShader without rebooting GiòRoom.

(37)

Following the philosophy of design for failure of microservices [15], every in-vocation is ready to handle errors of connection, trying to reconnect periodically until success.

3.4.1 GiòVase

GiòVase is the microservice that adapts the external service GiòPlants to the GASP world. GiòPlants manages a smart vase and is directly connected to an IoT device composed of a water pump, a light sensor, a moisture sensor and a thermometer. For our purposes, it is a black box that supplies the temperature and the brightness of the room, the moisture of the vase and the possibility to trigger an irrigation action of the vase, through a REST API.

GiòVase implements the API described in Listing 3.7, supplying the irrigation action under /act and the single values of each property under /sense. The brightness is calculated using the median of five samples of GiòPlants to tame the instability of the measurements. The moisture instead is the maximum value of ten samples, because it has in the peaks the correct value. The temperature is the more reliable value and it’s delivered as it is.

The unique action of irrigation can influence only the moisture, so the goals acceptable concern this property only and, as this is a driver service, it supports only a single goal at time, without multiple users or the possibility to set policies. When GiòVase is included to compose a more complex application, its goals system is disabled, accepting exclusively requests of sensing or actuation. In this case GiòVase pings periodically the presence of the above application, ready to

(38)

3.4.2 GiòShader

GiòShader is a driver service that directly connects to the roller shutter device and exposes a REST API to access the state of the device or to send commands to it. The particular shutters at the Department of Computer Science, University of Pisa are Venetian blinds that open the strips when going up and closes them

when going down. The deployed relay 1 _{admits the operation of open and close,}

moving all the strips respectively to the top and the bottom of the window, and the operation of going to a certain position. For instance, to close the shutter to make the environment as dark as possible, two actions are required: a close operation followed by a go to the 4% position, which tilts the strips and fully closes them. To facilitate the actuation by users or invoking services, GiòShader manages situations like the one described, making the required multiple calls transparent to the users, and suitably handling all timings. The fact that the operations offered by the service are often two calls to the device imposes a choice to how to manage an invocation during the interval between the first and the second call. To avoid inconsistent states of the device due to interleaved operations, we made them atomic, possibly responding with HTTP 423 Locked to the invoker. The only exception to this behaviour is the stop operation, that stops whatever the roller shutter is doing.

The actions offered by GiòShader are those in Table 3.6 (i.e., open, close, go to a percentage, tilt to a level of angulation and stop). The readable states of the device are the percentage of the height and the tilt level, considering that the first one can be wrong of plus-minus 2%.

The goals system has the same behaviour as GiòVase. Only one goal can be set at a time, no policies are offered and the possibility to stop the goals system

1_Shelly _2.5 _a _wireless _dual _relay

https://shelly.cloud/ shelly-25-wifi-smart-relay-roller-shutter-home-automation/

(39)

when the service is used to compose a more complex application. The goals are settable only on the state of the blind, so on values of height, under the optional condition of time constraints.

3.4.3 GiòRoom

GiòRoom is the entry point GASP service which composes GiòVase and GiòShader into a multiuser application. Given a set of goals from multiple users and one negotiation policy, GiòRoom exploits the other two services to sense the status of the room and to try to change it toward the negotiated goal state.

Settable goals concern the moisture of the vase and the natural light in the room, since the actuators of the current testbed can interact only with those properties. Every goal is associated with the user that has expressed it and can have a condition of activation regarding the presence of the user in the room or the time interval as discussed in Section 3.1.

Goals can be set by means of Voice User Interfaces available in Giò. For instance, a concrete example of a goal can be: "I’m Alessandro and I want that from 8 AM to 6 PM and if I’m in the room, the brightness is at least to 20%". This example shows the user (i.e. Alessandro), the conditions (i.e. from 8 AM to 6 PM and the presence of the user in the room) and the boundaries on a property (i.e. brightness from 0% to 20%) respecting the schema illustrated in Section 3.1. The GiòRoom microservice accepts numerical time and bounds, but a suitable user VUI interface can accept levels of brightness in words, such as "high", "medium" and "low", and convert them in numerical values.

(40)

3.4 Implementation Details how long. while(!stop){ if (Goal_sytem_Active){ plan(); } sleep(); } GOAL ENDPOINT GOAL LOGIC Goal List Schedule

Figure 3.10: Goals system of GiòRoom

The main behaviour of the goals system is sketched in Figure 3.10, we can see that the list of goals is shared between the Goal Logic, the main thread of the goal logic, and the Goal endpoint. The Schedule data structure divides the time of a day into slots, based on goals specified conditions. An example of Schedule is shown in Figure 3.11, with three goals with different activation times, illustrating the splitting based on the goals.

Goal1: from 06 to 16 Goal2: from 10 to 14 Goal3: from 14 to 22

00:00 06:00 10:00 14:00 16:00 23:59 Goal1 Goal1 Goal1

Goal2 Goal3

Goal3

22:00

(41)

Every time that there is an update to the goal list, the Schedule is modified and the Logic is alerted, interrupting an eventual sleep time. The loop of the Logic checks if the goals system is active, this because a direct actuation by a user disables the goals system. If the goals system is active, there is a planning phase to decide how to achieve the goals. Finally, there is a sleep time to make periodic every loop execution. This time depends on different factors: if the goals system is disabled the time is of 90 seconds; if the actual state satisfied the goals, it is of 120 seconds; if there was an actuation, it depends on the time to end the action; if there is a communication error, it is of 30 seconds. Those values can be adjusted to accommodate other verticals withing Giò.

The planning phase consists of creating the goal state, sense the real state and decide what action do if the second does not satisfy the first. Creating the goal state is required to resolve possible conflicts on the goals coming from different users. Whenever this happens, the list of goals in the current time slot is retrieved from the Schedule, then this list is pruned by excluding the goals with false presence condition, and finally, the boundaries on the same property that do not have an intersection are resolved with the set policy (among those discussed in Section 2.4). After those operations, there is a goal state with one range for each property as a result.

Next, the current state is calculated invoking the drivers for the sensed values and it is checked whatever the current state satisfies the goal state, i.e. if every range of the goal state contains the sensed value. In case the goal state is not satisfied, suitable actions are invoked on the drivers to try to change the situation

(42)

the brightness in the room, depending on the distance from the goal state. Regarding the moisture of the vase, the only operation possible is the irrigation one, that is activated when the sensed value is too low, then a couple of minutes are waited before checking the moisture and possibly retry a new irrigation.

The Sense endpoint and the Act endpoint of GiòRoom inherit the requests from the underlying microservices used to compose the room application. When the goals system is disabled because of an actuation request by a user, it is possible to enable it again by expressing a new goal or with a request to the goal endpoint with the option to indicate the amount of time after it should become effective. Every time that GiòRoom connects to the drivers, it sends a request to disable their goals system communicating the information (ip:port/path) where to send a ping request to confirm the microservice is still running.

3.4.4 Web GUI and Backend

From the user requirements elicitation, has emerged the need to individuate the role of an administrator for the room that is in charge to decide the policy used to resolve the conflicts of goal expressed by different users. To achieve this, two components that are not part of the GASP model has been developed, namely a Web GUI and its backend service.

The Web GUI is a simple web site, written with the framework Vue.js [28], that permits the login of an administrator, browsing the rooms and changing the policy of each of them. The graphic of the site is minimal but functional to our purposes. In Figure 3.12 the page related to a single room with the name of the room, the members and the combo box used to change the policy are shown.

The policy change request is the only one that is not directed to the backend service, instead is performed toward a GiòRoom microservice. This to enforce the authentication process as will be explained later.

(43)

Figure 3.12: Room management form

The other operations of the web site are all directed to the backend service, a simple server written in Java that manages a small database through the frame-work Hibernate ORM [29]. The database contains the admin credential, the rooms, the users and the policy settable. This service supports the login opera-tion, the query of all the rooms, the query of a single room, the policy update of a room. The login operation checks the admin credentials and, after the valida-tion, creates and returns an alphanumeric token that must be used for successive operations. This token certificates that a request is from an admin and expires after three hours.

To change the policy of a room an authentication schema is implemented as shown in Figure 3.13. The administrator performs the login on the web site,

(44)

3.4 Implementation Details WEB GUI GIO'ROOM BACKEND 1) LOGIN 2) TOKEN

3) CHANGE POLICY (TOKEN)

4) CHANGE POLICY (TOKEN) 5) OK

6) OK

Figure 3.13: Authorization schema

of the room with the new policy and GiòRoom confirms to the web interface the update.

(45)

Chapter 4 Case Study

GiòRoom microservice, described in the previous chapter, were deployed to an ac-tual smart room at the Department of Computer Science, University of Pisa. Such deployment was then used both for testing on prototypes as well as for assessing the desired goal negotiation policies embeds. In this chapter, after describing the available testbed (Section 4.1), we briefly summarize how the implemented software artefacts were deployed on such testbed (Section 3.4). Afterwards, we discuss how testing (Section 4.3), policy assessment (Section 4.4) and user eval-uation (Section 4.5) were carried out.

4.1 Giò Testbed

Our laboratory is situated in the Computer Science Department of the University of Pisa. The Fog infrastructure is composed of 6 Raspberry Pi 3 [30] and a

(46)

4.2 Deployment

and to send actions through HTTP. This device calibrates itself by checking the time to open and close the roller shutter.

The smart vase is managed by a Bluetooth Low Energy device and the service that controls it (GiòPlants) is developed by another member of the project team, we do not need to go into details, it is enough to say that the service offers a REST API and is deployed to a Raspberry.

The main user interface for room members runs on an Echo Show 5 [32], enabling a hybrid (graphical-vocal) interface developed by another room member. The microservices described in Section 3.4 are all deployed by Raspberries, while the Web GUI and the backend are deployed to the personal computer.

4.2 Deployment

The deployment of the microservices1 _{on the Raspberrys is done using Docker.}

For each of them, there is a Dockerfile that, starting from an image with Maven [33] for the ARM architecture, installs git to download the source code. Then the executable file is created with Maven and set as the entry point of the image.

Listings 4.1, 4.2, 4.3 show the Dockerfiles for GiòRoom, GiòShader and Giò-Vase, respectively. The fifth and sixth lines of each file are needed to set the Italian time zone and the CACHEBUST variable is used to force the pull of the code and the compilation without doing the previous commands when not necessary.

1_{The three repositories of the source code with their documentation are https://github.}

com/boccial87/gioRoom.git (GiòRoom), https://github.com/boccial87/gioshader.git (GiòShader) and https://github.com/boccial87/vaseDriver.git (GiòVase)

(47)

4.2 Deployment

Listing 4.1: Docker file of GiòRoom

FROM arm32v7 /maven EXPOSE 8888

RUN apt−g e t u p d a t e

RUN apt−g e t i n s t a l l −−assume−y e s g i t ENV TZ=Europe /Rome

RUN l n −s n f / u s r / s h a r e / z o n e i n f o /$TZ / e t c / l o c a l t i m e && e c h o $TZ > / e t c / t i m e z o n e

RUN g i t i n i t

RUN g i t r e m o t e add o r i g i n h t t p s : / / g i t h u b . com/ b o c c i a l 8 7 / gioRoom . g i t RUN g i t f e t c h RUN g i t c h e c k o u t o r i g i n / m a s t e r −− pom . xml RUN mvn d ep en de nc y : go− o f f l i n e ARG CACHEBUST=1 RUN g i t p u l l o r i g i n m a s t e r RUN mvn p a c k a g e −D s k i p T e s t s ENTRYPOINT [ " / b i n / s h " , "−c " , " j a v a − j a r / t a r g e t / g i o r o o m ∗ . j a r " ]

Listing 4.2: Docker file of GiòShader

RUN g i t i n i t

RUN g i t r e m o t e add o r i g i n h t t p s : / / g i t h u b . com/ b o c c i a l 8 7 / g i o s h a d e r . g i t RUN g i t f e t c h RUN g i t c h e c k o u t o r i g i n / m a s t e r −− pom . xml RUN mvn d ep en de nc y : go− o f f l i n e ARG CACHEBUST=1 RUN g i t p u l l o r i g i n m a s t e r RUN mvn p a c k a g e −D s k i p T e s t s ENTRYPOINT [ " / b i n / s h " , "−c " , " j a v a − j a r / t a r g e t / g i o s h a d e r ∗ . j a r " ]

(48)

4.3 Tests

Listing 4.3: Docker file of GiòVase

RUN g i t i n i t

RUN g i t r e m o t e add o r i g i n h t t p s : / / g i t h u b . com/ b o c c i a l 8 7 / v a s e D r i v e r . g i t RUN g i t f e t c h RUN g i t c h e c k o u t o r i g i n / m a s t e r −− pom . xml mvnw mvnw . cmd RUN mvn d ep en de nc y : go− o f f l i n e ARG CACHEBUST=1 RUN g i t p u l l o r i g i n m a s t e r RUN mvn p a c k a g e −D s k i p T e s t s ENTRYPOINT [ " / b i n / s h " , "−c " , " j a v a − j a r / t a r g e t / v a s e D r i v e r ∗ . j a r " ]

In order to run a microservice on a Raspberry, it is enough to build the image

from the Dockerfile and run a container starting from such image 1_{. An example}

of how to build an image and run a container is shown in Listing 4.4.

Listing 4.4: Docker commands to run a container from the Dockerfiles

d o c k e r b u i l d −−t a g=g i o r o o m − f / room / D o c k e r f i l e −−b u i l d −a r g CACHEBUST =$ ( d a t e +%s )

d o c k e r run −−rm −d −−name=gioRoom −p 8 8 8 8 : 8 8 8 8 g i o r o o m

4.3 Tests

To test each microservice, the platform Postman [34] was used, which permit programming custom HTTP requests and defining assertion on the results. It permits to define a set of sequential requests to test an entire REST API. We

1_{This deployment behaviour is used to easily debug and maintain the code, obviously, in a}

(49)

4.3 Tests

show the results for each microservice in Figures 4.1, 4.2, 4.3 there are the results of the tests for GiòRoom, GiòShader and GiòVase respectively. The effects on the actuation requests are visually attested and may further commented when discussing policy assessment and user evaluation in next sections.

(50)

4.4 Policy Assessment

Figure 4.3: Report on GiòVase tests

The tests were done initially on a single machine in localhost and bottom-up. First, the drivers and then GiòRoom were tested, since GiòRoom depends on the other two. After, the services were deployed to the Giò testbed and tested in the real environment. The final assessments were done using the input from the Amazon Echo Show 5, giving vocal commands to actuate, to sense and to use the goals.

4.4 Policy Assessment

To assess the implemented policies, we did a test in our laboratory involving its four members, let’s name them Member A, Member B, Member C and Member D for privacy reasons. Each member of the laboratory expressed a goal about their desired brightness and all different policies were tested during a short amount of time (15 minutes) to see the effects of the goals system. To express a goal is used the Echo Show and the brightness was divided in four levels corresponding of four different ranges:

(51)

4.4 Policy Assessment

• Low: 16% to 30% • Medium: 31% to 50% • High: 51% to 100%

The first part of the test was about the average policy. Member A, Member C and Member D selected "Dark" level (i.e. 0-15%) and Member B selected "High" level (i.e. 51-100%). The goals system created a goal state with a range of brightness from 16.8 to 31.8 and the roller shutter was adjusted with two strips angulations until the sensed value was included in the boundaries. This goal state is a middle way of the goals expressed and the brightness reached was in the "Low" range. The four members were rather satisfied with their resulting brightness even if none of them had the goal fully fulfilled.

The second part of the test was about the priority policy. With the same goals set, the priority list was: Member A, Member B, Member C and Member D. The goals system created a goal state with a range of brightness from 0% to 15% and the roller shutter was adjusted closing the rolling shutter. Obviously, Member A, Member C and Member D were very satisfied with the result, unlike Member B. Changing the priority list to Member B, Member C, Member D and Member A, the goal state boundaries changed to from 51% to 100% and the rolling shutter was completely opened, making happy Member B at the expense of Member A, Member C and Member D. We can conclude that if there is no hierarchy among the members of a room, this policy is a bit bossy, and the higher priority people are the only ones to be satisfied, together with the people that agree with them.

(52)

4.5 Users Evaluation

To permit the users interviewed during the elicitation phase to evaluate the pro-totype, we organized a live demonstration of GiòRoom. This demonstration con-sisted of showing the various part of Giò developed until mid-September 2019, using the Echo Show 5 as the principal user interface. First, the functioning of GiòRoom was explained, then the list of phrases that the Giò Voice interface can understand was handed over to the users. The first things they tried were all actuation operations, various commands to the roller shutter and an irriga-tion operairriga-tion of the smart vase, then they set a goal regarding a high room brightness. Overall, the users were satisfied by the prototype and appreciated the possibility to set the goals to make the roller shutter move automatically and irrigate their plants. This demonstration suggests us to do a better check on the freshness of the sensors values, because the used ones were too old to be useful to the goals system, moreover, the stress test of actuation performed by the users revealed a minor bug on the shutter driver that did not emerge previously. The position of the light sensor, the goodness of the light ranges and the precision of the moisture sensor are other crucial points that we tested successfully during our demonstration.

(53)

Chapter 5 Conclusions

In this final chapter, we start by presenting the more relevant related work and the state of the art regarding interoperability and goal-oriented IoT systems in Section 5.1. Then, we describe the results obtained by the work on this thesis in Section 5.2, concluding with the future work in Section 5.3.

5.1 Related Work and State of the Art

5.1.1 Interoperability

The interoperability between different IoT systems is a problem addressed by many researchers in literature and we can divide the proposed solution into three main categories, such as extended protocol level, gateway-based architectures and plug-and-play systems. The former is referred to those attempts to extend MQTT [35], CoAP [36] or XMPP [37] to use them as a bridge between IoT devices and other services, using a publish-subscribe pattern or group communication model.

(54)

5.1 Related Work and State of the Art

based approach [41] or an extension of MQTT for the communication between gateways [42]. Recently, a lot of device producers use virtual assistants platforms, such as Amazon’s Alexa, Google’s assistant or Apple’s Siri, to make their devices reachable by the users with smartphone apps or vocal assistants, allowing to create routines of actions triggered by events based on time or vocal orders.

Plug-and-play systems are frameworks or environment in which is easy to add new devices and exploit given services to create and manage a new application. The most famous examples are Microsoft Hub IoT [43], Amazon AWS IoT Green-grass [44] and EdgeX Foundry [45]. They typically use the event-based paradigm to make device communicate with the system, that is typically Cloud-based, and it is possible to react to such events triggering defined actions. They can give support for storage of data and offer services to make costly computations on them, such as machine learning techniques.

The survey [8] on pervasive computing, identifies some open challenges and motivates the need to create a middleware layer to permit IoT applications and systems to be more adaptive to dynamic changes and to support the autonomy and the distributed decision making, everything taking in account the presence of the human users "in the loop". The authors point out the importance of inter-operability as a major requirement to enhance the development of new solutions in the field, together with application composition.

[46] describes a formal model to representing IoT services, where service is intended as "something that receives input contributions from some contributing source, processes them and creates output contributions for some client", so IoT devices are brought to the the service level. Based on these assumptions, the model proposed defines a service from two different angles: compositionally and directly. From the composition angle, the author presented a set of composition rules for constructing complex services by composing simpler ones. From the

(55)

direct creation angle, he defined a service as a set of actors, which are ports and agents. In our work we want to compose services related to IoT device as well, but we put emphasis on the importance of users’ goals, that are not considered by the author of this publication.

Concerning composition in IoT, is worth mentioning IoT Composer [47], a tool that was developed for supporting the development of IoT applications by first providing a behavioural model for objects and their composition. The tool also provides automated validation techniques for verifying that the composition behaves correctly. Finally, a deployment plan is generated and can be run for effectively binding and instantiating all objects involved in the composition. Like the previous, this tool lacks relation with user goals, that are central in our work. [48] presents XWARE, an interoperability framework that allows to integrate discovery and interaction of different middleware platforms in pervasive comput-ing systems. The design allows to configure and extend the framework in order to add new platforms and tailor it for the use in different domains. Furthermore, XWARE instances can communicate with each other enabling interoperability in smart environments as well as in smart peer groups. This is a good exam-ple of interoperability of IoT systems, but it lacks the compositionality and the goal-awareness that we address in our work.

In our work, we decided to use the gateway-based architecture where driver services abstract the hardware of the devices and offer a suitable interface to enable the interoperability of the system. This choice has the disadvantage that every new device needs a service to manage it, but there are a lot of technologies

(56)

the services expose in their interfaces operations about the goals system, treating the goals as "first-class passengers" together with the data of the sensors and the actions of the actuators.

5.1.2 Goal Oriented Paradigm in IoT

In the IoT field, the goal-oriented paradigm was little explored until a few years ago but recently new proposal and solution start to emerge. The most famous example is IFTTT [49], a web service that permits to create a chain of simple conditional statements in the form "If this then that", so it is needed an event trigger and an associated action that can be a sampled value of a sensor and an action of an actuator. Our work wants to achieve the objective to fulfil complex goals, with more articulate conditions that involve different devices.

A more articulate attempt is GrOWTH [50] that stands for "Goal-oriented end user development for web of things devices", this is an architecture to enable users to program IoT devices based on goal-oriented interaction. To fulfil the desiderated goal GrOWTH uses semantic web ontologies for knowledge represen-tation and planning techniques from the artificial intelligence domain to dynam-ically generate plans at runtime taking into account the user goals, context, and available IoT devices. The authors propose a conceptual model to describe the planning as a transition system to reach the goal state through a set of actions. The architecture of GrOWTH is centralized, with a Controller entity that orches-trates the various steps to fulfil the goals. Our work aims to be more distributed, with a microservice-based architecture that permits the horizontal scalability of the components and encourage the composition of applications to create newer and more complex ones.

[51] propose an approach to automate "high level" decisions in pervasive ap-plications, allowing them to be postponed until runtime, this approach consists

A microservice-based smart room application: model and prototype

University of Pisa

Department of Computer Science