A number of scienti c and technological advancements enabled turning the Internet of Things vision into reality. However, there is still a bottleneck in designing and developing IoT applications and services: each device has to be programmed individually, and services are deployed to speci c devices. The Fluidware approach advocates that to truly scale and raise the level of abstraction a novel perspective is needed, focussing on device ensembles and dynamic allocation of resources. In this paper, we motivate the need for such a paradigm shift through three case studies emphasising a mismatch between state of art solutions and desired properties to achieve.
To reveal the full potential of large-scale IoT deployments demands for novel
models and programming abstractions [
Copyright c 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0)
A novel programming model for IoT services and applications has been
conceived in [
In this paper we advocate the need for such a paradigm shift in designing and developing IoT services and applications by discussing three envisioned deployment scenarios: a smart retirement centre, a smart university campus, and a generic stress-free workplace. Accordingly, the paper is organised as follows: Section 2 overviews the Fluidware approach to IoT systems engineering; Section 3 describes the issues in developing IoT services according to current practice, and how Fluidware may overcome them, in a smart retirement centre scenario, whereas Sections 4 and 5 do the same for a university campus and a generic workplace, respectively; nally, Section 6 provides nal remarks. 2
The key idea of Fluidware is that IoT services and applications can be conceived and designed as transformations of widely distributed event streams (\ ows") encompassing ensembles of devices. This is achieved by means of the \funnel process" abstraction, acting as both producer and consumer of ows, and able to capture, merge, split, replicate, redirect, lter, process, namely manipulate them in time and space, over the network of distributed IoT devices, and ranging the whole spectrum from Edge to Cloud. As a consequence, Fluidware raises the abstraction level for developers willing to design an IoT service or application: they no longer think in terms of programming physical devices and orchestrating their communications, but rather in terms of programming purely logical processes (the funnels) dealing with event streams detached from the physical devices actually producing and consuming them|as depicted in Figure 1.
Funnel processes are declaratively speci ed in a totally agnostic and
orthogonal way with respect to their actual allocation to computational nodes, and
distribution across the Edge-Cloud spectrum|which are aspects delegated to
the Fluidware middleware. Such a speci cation de nes which ows to capture
and what to get out of them depending on contextual, spatio-temporal, and
semantic constraints (e.g., \gather all temperatures from this area in the last 15
mins which are above the de ned critical threshold, then chart a heatmap").
This enables to de ne scale-independent computational processes inherently to
contextual conditions and seamlessly tting heterogeneous computing and
network infrastructures. More speci cally, an event ow is manipulated by funnel
processes to produce a new ow, by a combination of techniques typical of stream
processing and self-organising systems, such as merging, splitting, ltering,
aggregation, spreading, and so on [
For instance, a funnel process collecting temperature measures from a given area to chart a heatmap of that area may be actually composed by three subprocesses: one gathering temperatures from sensors, thus directly deployed onboard Edge devices, one aggregating results to average out temperatures depending on sub-areas (e.g., the kitchen, the living room, 1st oor, 2nd oor, left-wing, right-wing, etc.), hence deployed in Fog gateways, and the last one charting the heatmap, deployed on the Cloud (as it needs global information and more computational capacity). Such sub-processes, which can be funnel processes themselves, are opportunistically connected to the most suitable event ows (Figure 2), and deployed to the most suitable device (Figure 3). For instance, should the Fluidware middleware detect failure of a sensor, it could replace the connection to the event ow coming from such sensor with another, non faulty one. Also, should the middleware detect a performance drop in processing at the Edge, it could decide to re-locate the correspondent sub-process to an available Fog gateway.
In next sections, we discuss three Fluidware deployment scenarios so as to shed light on why the kind of paradigm shift proposed by Fluidware is needed, how it advances beyond the current state of art in delivering services in the IoT, and what bene ts it delivers. 3
We envision the scenario of a retirement facility for elderly people or people with chronic diseases, both requiring peculiar care and continuous assistance. There, we assume guests can live together with a member of their family or an assistant (social worker, nurse) in small furnished ats, properly equipped with IoT devices and services meant to support health and general lifestyle monitoring (e.g., smart cameras, A/C, illumination, doors, etc.). Also, we assume that the centre has dedicated rooms for providing care to guests (e.g., rehabilitation rooms and spa services) as well as rooms for social and leisure activities (e.g., the canteen, and common living rooms), also equipped with smart devices (e.g., smart TVs, pill boxes, refrigerators, beds, sofas, chairs and wheelchairs, etc.).
Several speci c IoT services can be delivered to guests, which usually require coordination of several components (software and hardware), and each having its solutions and issues to deal with|as summarised in Table 1. 3.1
In the ats of the facility, other than services to access and control individual appliances, one can think at providing coordinated services that, by accessing and directing the lightening system, the light sensors, and the window curtains in a speci c room, can modify the overall light situation of that room depending on the speci c needs/preferences of the persons occupying it. Similarly, sensors and actuators associated to the heating and A/C systems can set up the climate conditions in accord to the speci c comfort levels of the inhabitants.
Concerning care delivery, one can think at services to monitor the health conditions of patients and their everyday activities, and possibly send noti cations to the medical personnel to alert about unusual or potentially safety-critical situations. Furthermore, in presence of suitable actuators (e.g, robotic personal assistants or properly instrumented furniture such as electro-mechanical beds and sofas) the system can directly trigger the necessary actions to prevent damage (e.g.,, put the bed in vertical position upon sensing choking). All of the aforementioned IoT services are local in the sense that they do not require a global understanding of the situation.
In addition to the local services conceived to orchestrate speci c portions of the facility, a number of global ones can be envisioned to regulate its overall functioning. For instance, services to control the heating and lightening systems, and in particular to monitor and keep under control energy expenses. Services to monitor re and other dangerous situations, and automatically organise evacuation plans upon need. Services to control the overall distribution of people in the facility and steer assistance personnel accordingly. 3.2
In order to set up the aforementioned services, the following sensors and actuators are needed: { general ambient sensors and actuators: light and heat controllers, gas and smoke detectors, presence and motion sensors, energy consumption sensors on electric appliances, shutter/curtain controllers, as well as daily life objects augmented with sensing capabilities (e.g, cup, fork, cane). SafeOtScymc-cuar&pritaticncaltail-melcreaatnusttet&roecmdonnaoidtltleiiutdmicopanirntsoiaoctneiodsnures ASuttaomraotuedtiEnengveaarcgnuydateoiocnccuipepnlaacnnytsgesnteeerraitnigon SmBarrSottkaOSetriybc-njbe2cach/st3.e-/dRtiWEperuSosbTTalirssrcehehr-svisotuiuecbcrestcscuerri/ebeWS EvCenlSot-ueCrdvo-ihncodesitctieoodmn-ppAroocsctitieoisonsninrugles
SO abstraction level WoT full network stack Adding device/service
Simple message-based interaction
Static network topology Design-time process allocation
Semantic pattern matching Dynamic network re-con guration
Run-time process allocation { speci c sensors and actuators needed to monitor and assist with the health conditions peculiar to each guest, there including body sensors such as heart rate, glucose, blood pressure, temperature, or medical devices such as ECG monitors, sleep quality monitors, spyrometry devices, smart scales. Besides devices inside guests' ats, all other places in the facility may include sensors to detect people presence and ambient conditions, actuators to regulate ambient conditions, and digital signals (e.g., audio system) or screens to provide noti cations, messages, and alerts. 3.3
At the modelling level, solutions readily available to deliver the aforementioned
services are either based on the concept of Smart Object (SO) [
The above considerations imply that, for instance, realising services for monitoring patient clinical conditions and trigger appropriate action in case anomalies are detected would amount, essentially, at developing a web services stack for data processing and the appropriate communications with sensor and actuator devices. For instance, these may be connected to a local gateway (e.g., a RasPi or a desktop computer) for sending data, which is then processed by an ensemble of web services to realise the system functionalities. Cooperation between services may happen in a point-to-point fashion through simple RESTful endpoints, or by relying on a publish-subscribe broker. Finally, deployment would be mostly decided at design-time: the web service backends would be likely deployed on the Cloud, or possibly to a su cient powerful Fog node, and devices connected to the gateway would have their own logic embedded to send data and listen for commands. This practice limits scalabilty as forces developers to individually deal with each speci c device individually. 3.4
The solutions described above have a few limitations which current research proposals fail to address in a holistic and conceptually sound way. WoT modelling requires a full network stack to be available on connected devices, which is impractical for the resource-constrained ones usually employed at the Edge. SOA does not cope well with moving services across tiers' boundaries depending on available resources. The 2/3-tiered network topology model is usually accepted as a static one, where services are allocated to one speci c tier at design time.
This means that, for instance, adding a new device to the system usually implies adding a new service to the stack, taking care of connecting the device to the rest of the application, re-wiring service composition routing paths, and such. Also, scaling the service to, for instance, a whole at instead of a single room usually requires a re-deployment of the whole application. 3.5
Fluidware would enable developers to de ne the event streams they are interested in (e.g., the blood pressure or heart rate time series), the funnel processes they want to deploy (e.g., one triggering alerts if a combination of vital signs is worsening, and another one gathering vital signs measurements from body sensors) and how they combine the aforementioned streams, and let the Fluidware middleware taking care of (a) connecting the event streams to the actual source devices' data, and (b) allocating the funnel processes to the computational nodes composing the network. This means that developers need no longer to bother with re-wiring service connections if new applications are deployed, or to re-con gure the network topology if new devices come in, nor to deal with device failures as long as other providing the same data are available.
Overall, this means that not only system designers have an higher abstraction level provided, but also a higher degree of decoupling between system hardware and software components. With Fluidware, indeed, \ ows" decouple computational processes from the actual data sources they need, while \funnels" decouple developers from the burden of statically deciding where to deploy their services. 4
Another scenario suitable for Fluidware is a smart university campus, as it should provide comfortable living spaces for both students and faculty sta to support individual studies and research, as well as student teamwork and sta collaborative research. There, spaces could be re-organised on a per-need basis, such as in the case of planned temporary events (e.g., meetings, conferences, seminars, industry recruiting, etc.) or unexpected contingencies. For instance the earthquake of October 2016 seriously damaged the whole city centre of Camerino, causing damage to buildings of the Department of Computer Science, among the many. In presence of scarcity of space, organisation is thus even more critical, and opportunistic exploitation of available rooms is of paramount importance. Several services can then be conceived to deal with the shortage of spaces|as summarised in Table 2. 4.1
A rst service that can be delivered to students and faculty sta is the real-time (a) tracking of rooms occupancy and (b) adjustment of rooms' environmental conditions to the occupants' needs. At the local level, students, researchers, and professors may utilise a smartphone app indicating the place that better matches the users' requirements: for instance, some students require a study place which is isolated, quiet, warm, and bright, whereas others are just interested in nding the closest spot. At the global level, administration sta and campus managers may nd convenient to have a Decision Support System for governance, aimed at analysing data generated from the university IoT infrastructure to better understand how to allocate the available spaces and to nd the most suitable spaces for locating new services.
Another service could be a navigation system to steer people towards their destination, featuring integrated contextual information such as current or future crowded areas, planned events, etc. Di erent path optimisation methods (e.g., the shortest distance, the shortest time, accessible paths only, stairs minimisation, etc.) can be applied according to individual preferences and conditions. Another example is assisted parking: free parking slots (for cars or bikes) can be suggested according to planned activities of individuals; for instance, slots nearby the branch of the campus where activities will be located could be prioritised.
Lastly, an interesting service would be a recommendation system informing about opportunities of interaction and activities contextual to students' and researchers' goals and preferences. For example, in a multi-disciplinary campus, students may grow interest in seminars or events which belong to di erent degree courses; in these cases, it may be easy not to get appropriately noti ed. If the campus is big enough, it is also likely the opposite happens: students receive so many noti cations about upcoming events that they simply ignore them all. In this case, the recommender system should be able to customise the information conveyed to each student, dynamically considering dominating interests, as well as maximising the interests of groups, as people are more likely to attend an event if an entire group is involved. 4.2
Several devices have to be scattered across the campus to support the aforementioned services: presence and motion sensors; temperature, humidity, light, and noise sensors; RFID tags and readers; cameras; electric actuators; Edge devices such as single-board computers (e.g., Raspberry Pi). These devices will not form a nite and static set, immutable for the whole services lifetime: instead, it can dynamically change for device addition or failure and replacement. Moreover, it is worth emphasising that students and faculty sta , too, can serve as crowdsensing sources sharing data through their own personal devices, for instance by simply accepting to communicate their position to the smart campus services. 4.3
Several techniques are available for designing the aforementioned functionalities, however, none of them takes a holistic stance, which is instead quintessential for a system where decisions depend on a variety of factors. Also, existing solutions do normally require to send data through the Cloud to third parties, which can be undesirable. From the point of view of the developers, traditional approaches such as object orientation or web services quick fall short in terms of expressiveness, extendability, and integration in such highly and heterogeneous scenarios such as the IoT. 4.4
Using graphical notations for representing processes is a well-known practice in the areas of Model-driven engineering and Business Process Management (BPM). For instance, in our scenario we can represent processes for the search of a room, the information retrieval from sensors, the analysis of sensors information, the activation of sensors failure procedures, the engagement of users and their devices in the data retrieval procedure. However it is challenging to capture all the required details about sensors and smart devices with the actually available notations (e.g., BPMN). Especially, there is no standard way to represent an IoT device, and data are generally represented by a single element called data-objects. No support is given for the concept of ow/streaming of data which are necessary in many IoT deployments. 4.5
The objective of Fluidware funnel processes is to leverage on sensors opportunistically, so as to enable seamless provisioning of timely and reliable data for supporting the services o ered to users. We may conceive a uid process in two way: on one side, a top-down approach can be used by designing all the process variations that may be activated in some circumstances, whereas on the other side a bottom-up approach based on mining techniques can be used to discover relevant emerging processes. We could of course also think about a mixed approach. In any case, the activated processes are strongly dependent from sensors data, which means the processes are di erentiated in terms of control- ow but also in terms of data- ow, which is something Fluidware can nicely support thanks to device decoupling and dynamic resource allocation.
As sensors and actuators can dynamically change, the decoupling between devices and data ows o ered by Fluidware becomes of paramount importance. E.g., if each student has a dedicated application on his smartphone, hence is working as a crowdsensing source, as he/she moves around the campus the information that his/her smartphone provides changes context, hence may be opportunistically connected to another funnel process by the Fluidware middleware. Not only connection between event ows and funnel processes may change, but also allocation of such processes across the IoT network can: for instance, funnel process may migrate across Fog nodes (e.g., RasPis deployed in strategic positions across the Campus) with the goal of minimising latency in delivering services to students and researchers. 5
Overworking, con icting relationships, psychological harassment, etc., contribute to workplaces stress, with negative impacts on workers' productivity and, especially, health. Cardiac monitoring is a key activity to detect high-stress conditions and the ECG monitoring has become one mainstream activity in ambient assisted living. A variety of services may be engineered to relieve workers and to help the governance to manage stressful collective situations (e.g., noisy ofce rooms, dangerously overcrowded canteen, etc.) while improving the livability and safety of the workplace. 5.1
At a local level, a cardiac monitoring IoT service can acquire the real-time ECG of a single user from a worn chest band, process the received heart signals, and enable the individual HRV analysis. Eventually, doctors and psychologists can outline the stress pro le of the monitored individual and take actions to preserve worker safety and well-being (e.g., notify a worker to take a break).
At the global level, instead, the IoT service can exploit distributed acquisition of ECG ows related to several monitored workers. In this case, a multi-user stress monitoring, along with other contextualised data, allows the workplace governance to identify both common uncomfortable situations (e.g., a noisy o ce room) and episodic dangerous ones (e.g., an overcrowded parking slot). Therefore, situations threatening the workplace livability and safety can be properly managed through immediate actuation (e.g., opening a window) or plan future actions (e.g., re-thinking distribution of parking spaces). 5.2
The envisioned stress monitoring service would hence need wearable, speci cpurpose devices, such as Polar H10 chest band, for the heart signal acquisition and the Bluetooth-based communication to the user smartwatch/smartphone; portable, general-purpose devices, such as Android-based smartwatches Huawei Watch2, to be interfaced with the wearables; a single-board computer (e.g., Raspberry Pi3, Zotac CI540 NANO Pc, etc.) acting as a gateway for collecting and locally processing ECG data. These IoT devices are all commercially available and a ordable. Besides these devices, the monitored workplace might include sensors to detect people presence and ambient conditions, actuators to regulate ambient conditions, and the like. 5.3
Conventional ECG-based stress monitoring systems are typically designed for
a single, speci c (indoor or outdoor) setting provided with a set of (both xed
and mobile) physiological and wearable devices [
The aforementioned solutions are typically tailored on a single, well-de ned scenario (e.g., a highly instrumented infrastructure of an o ce room) and do not e ectively handle the gradual transition between di erent environments. Device/worker mobility introduces the need for the seamless, dynamic execution of computational task according to changes in the devices' availability (e.g., a worker's smartphone might run out of battery and be automatically replaced by the smartwatch). Ad-hoc mechanisms are also typically provided to make heterogeneous devices interoperable (software bridges, data model translators, etc.), but these solutions often result in not scalable architectures, di cult to be extended. maintained, and upgraded in the future. 5.5
The Fluidware approach allows overcoming many of the aforementioned limitations. Being device independent, Fluidware does not assume the existence of speci c types of devices in speci c locations: this allows continuous and mobile monitoring of the workers, thus enabling the ECG-based stress monitoring system to (a) adaptively and reliably serve its purpose, despite contingencies like unreachable devices; (b) dynamically integrate new devices; (c) support semantic interoperability specifying the event/data ow in a declarative way. Indeed, Fluidware design and programming abstractions natively and seamlessly support Edge to Cloud computations, thus fostering the development of a scalable ECGbased stress monitoring system which adapts to the application requirements (ECG acquisition responsiveness, HRV calculation accuracy, etc.). 6
In this paper we discussed three case studies motivating the need for a paradigm
shift in engineering and programming IoT services and applications. Such a
paradigm shift is actually envisioned by the Fluidware approach already
presented in [