*2.2. IoT Platform*

The IoT platform applied in this research is based on the middleware called thethings.io [49]. As shown in the Figure 3, the architecture of the IoT platform has been structured in five layers. The aspects of IoT middleware which are relevant for the understanding of the developed system are described below.

**Figure 3.** Architecture of the IoT platform.

At the lowest layer are the *assets* and *devices*. Assets are the reason for the development of IoT applications. The assets of interest are the real-world objects and *entities* subject to monitoring, as well as having digital representations and identities. Assets are instrumented with embedded technologies that bridge the digital realm with the physical world, and that provide the capability to monitor the assets as well as providing identities to the assets. Sensors and actuators in various devices, e.g., Wireless Sensor Networks, provide the main functional capabilities of sensing and embedded identities.

The second layer corresponds to the information management middleware, which is based on the specification of an information model and an Application Program Interface (API) based on the Representational State Transfer (REST) software architectural style (see Zhou [27]), as well as the adoption of communication protocols to manage and exchange information. All the information handled by the IoT platform is modeled by defining an information model composed of seven types of entities. Figure 4 illustrates these entities, as well as the relationships between them.

**Figure 4.** Entity relationship diagram. All the information handled by the platform is modelled by defining an information model composed of seven types of entities.

An entity can refer to hardware, that is called *thing*, e.g., IoT device, or software, that is called *resource*, e.g., hosted in the device, and to high-level abstractions, that are called *product*, that group entities of different types, e.g., product can have different types of things. An *organization*-type entity represents an account associated with the IoT platform and is uniquely identified by a name. An organization has *applications*. Applications are characterized by a pair <name\_app, id>. Applications have *products* and *users*. Users are characterized by a pair <email, permissions>. Products are identified by a triplet <id, name\_product, payload>. Each product has *things* also characterized by triplets <name\_thing, thingid, thingtoken>. Finally, things have *resources* and *descriptions*. Descriptions are semantic data (metadata) characterized by a pair <\$geo, \$settings>. The attributes of the resources are data associated with a date and time grouped in triplets <key, value, datetime>. The values of these attributes become the information of the system.

The IoT platform provides a complete backend solution to develop IoT applications through an easy and flexible REST API, which allows the mediation between a large number of services. Table 1 shows the operations at thing level supported by information management middleware. Moreover, the IoT platform is agnostic to hardware, being possible to integrate any hardware platform. To do this, it is necessary to use the supported protocols [27,50]: Hypertext Transfer Protocol (HTTP), Websockets, Message Queue Telemetry Transport (MQTT), User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or Constrained Application Protocol (CoAP). Regarding serialization formats, such as JavaScript Object Notation (JSON), Messagepack, and Protocol Buffers, are supported.

The third layer of the platform architecture is responsible for data ingestion and storage. Ingestion consists of getting data from producers, e.g., IoT devices, and making them available to consumers, e.g., IoT applications. For this purpose, a component called *message broker* is used. This component

is based on Redis technology [51]. Producers send data to the message broker using the information management middleware. The data is pushed to the temporary storage of the message broker. The temporary storage consists of a cache that allows later stages (e.g., analytics) a simple and quick access to the incoming data. In doing so, producers can publish messages and consumers can consume them quickly using Redis database engine, which means real-time data management. The message broker persists the information published by the producers in two data warehouses called *DB Time series* and *object repository* that use NoSQL Cassandra [52] and MongoDB [53] technologies, respectively. The time series built from the attributes of the system resources, <key, value> pairs, are stored in the DB Time series. The rest of the information is stored in the object repository. The biggest challenge for the message broker is to be able to dispatch the received requests. For this purpose, a memory and CPU cluster are available. The management of these resources is automated thanks to the application of auto-scaling tasks [54].


At the fourth layer, the IoT middleware allows the modeling of data by scientists who perform analytical tasks to discover valuable insights hidden in the big data stored in the platform. In this analytical architecture, three types of mechanisms can be distinguished: *functions*, *jobs*, and *triggers*. Functions are fragments of code executed using a call from the RESTful API. Functions can be invoked by triggers and jobs. This mechanism is useful for encapsulating logic hosted in the cloud. The execution of functions is limited to 15 s. Jobs are executed automatically each predefined time period. Jobs are used to process data in order to generate *key performance indicators (kpis)* and analytics by aggregating event data. The execution of the jobs is limited to 5 min. Triggers are executed when an event occurs after using the RESTful API, e.g., thingWrite request. Triggers enable alarms to be sent through various methods (e-mail, short message service (SMS), twitter or voice calls). Triggers also allow the creation of aggregated resources or events for the calculation of kpis and analytics using jobs. Triggers execution is limited to 2 s.

The IoT platform provides the cloud code API (see Table 2) and the *Cloud Code Sandbox* to execute JavaScript code associated with triggers and jobs. The cloud code sandbox uses Jailed [55]. Thanks to this library, it is possible to launch an independent and secure sandbox for each request (trigger or job). In addition, Jailed allows to export a set of external functions into the sandbox.

**Table 2.** Description of the cloud code API operations used in this research.


At the top of the architecture is the user interface, which provides to the user data monitoring and management capabilities. For this purpose, both a dashboard system and a global online management panel are accessible from anywhere. The dashboard system incorporates widgets from libraries and proprietary that allow their customization to get the best possible response in the visualization of information. There are three levels of dashboard: main, application, and insight. The main dashboard displays the metrics of the applications and IoT devices, and their activity. The applications show the measurements of a subset of devices and their activity. Finally, the insight dashboard displays the measurements and activity of an IoT device related to an application. Therefore, the dashboard system can monitor the information associated with IoT applications: data from resources, kpis, device status, alarms, and other information.

After presenting the device (see Section 2.1) and the IoT platform, the integration process that results in a smart water quality monitoring system is addressed in the following section by describing a decentralized use case in the field of wastewater treatment.
