Autonomus air Quality Management System Based on Web of Things Standard Architecture

The present work seizes the opportunity to counter IoT technology fragmentation that the World Wide Web Consortium is offering with the upcoming standard Web Of Things. A gateway service based on this standard and an air quality manager sensor were designed and implemented in a Smart Home with the aim to develop a tool to manage this critical parameter and improve people's quality of life. The system proved to be able to report and manage the Smart Home devices to reduce Fine Particulate Matter concentration on demand and in real time, also allowing to record data to be consulted by the Smart Home users. The technology produced is agnostic, scalable and replicable in other environments and contexts such as industry, healthcare and Smart Cities among others.

Currently, numerous and large developer communities through internet, mobile communications and autonomous entities are contributing to deliver services and applications for IoT [12]. On the other hand, industry has a major challenge on building interoperable devices due to its expensiveness [13]. According to Benoit Lheureux from Gartner's IoT research group prediction for 2018, half the costs implementing IoT solutions would be attributed to integration, and companies keep treating integration as a second-tier focus. Surprisingly, rapid IoT development led several actors in industry to launch ambitious projects based on key technologies that are not fully specified, including IoT architecture, which also exacerbates the issue [12].
Recently there have been advances in incorporating IP Protocol stack into a smart object but some adaptations are still to be made to meet the new requirements. In that aim, the Internet Engineering Task Force (IETF) standardized protocols such as CoAP, 6loWPAN, and routing over lossy links. Also, the European Telecommunications Standards Institute (ETSI) is preparing the long-term evolution (LTE) networks for massive low-throughput nonhuman communications in order to achieve full IP connectivity in individual things. On the other hand, there are some platforms developments such as Kuksa and Eclipse Hono that provide remote services interfaces, several protocols implementation (e.g. HTTP, REST, MQTT, etc.), cloud based approaches among other solutions to deal with this matter [12].
To solve IoT fragmentation, the W3C consortium [14], is currently developing a novel proposal of standard called Web Of Things (WoT. WoT proposes a web-based semantic architecture for the connectivity of devices allowing an interoperability from the cloud, bringing as a consequence to extend the spectrum of solution for intelligent environments.
A central aspect of this standard is the WoT Thing Description. It describes the metadata and interfaces of "things", which are representations of physical devices and services in terms of their properties, data interaction models, communication requirements and security requirements, allowing to formally and comprehensively describe them in a machine-understandable format [15]. This is the foundation to build a fully interoperable IoT platform with the power to integrate IoT entities and allow the creation and implementation of services to process and link heterogeneous data, improving overall system performance and versatility [16].
In this context, this paper presents the design, development and initial testing of a solution for the autonomous management of air quality condition within a Smart Environment, using the WoT standard and implementing it within the UPM's Smart House Living Lab as a testbed. This management, in particular, consists in actuating over different devices associated to the air quality sensor, given their impact or mitigation capacity over PM2.5 and PM10 concentration, orchestrated by a gateway service. This solution aims to take a step forward to improve the interoperability of IoT devices and to implement a novel air quality sensor solution in multiple scenarios.
The next sections are organized as follows: section II presents the methodology and material used to develop the proposed solution; section III includes the results of design, develop and evaluation of the system; finally, section IV presents discussions, conclusion and future steps to extend this work.

II. METHODS AND MATERIALS
The proposed solution includes the design, development and evaluation of both Software and Hardware elements within an intelligent environment, enabling the interaction with each other using the WoT standard. For this, the following work methodology has been established: First Phase, study of W3C standard For this phase an exhaustive investigation of the W3C standard has been carried out. This research includes programming language, protocols and their application in different use cases. (e.g. Industrial, Smart City, Smart House, etc.) [15].

Second Phase: system design
The design of the solution was based on the W3C standard, studied in the first iteration and taking into consideration the elements of hardware and software needed for the design.  [19].
WoT Gateway: It is a REST server able to manage clients, devices and services, and all their possible interactions, supporting HTTPS protocol and implementing JSON Web Token (JWT) authentication [20].
Postman App: It is a free tool, used for developing and test APIs [21], it was used to test the communication protocol developed.

III. RESULTS
In this section we present the results obtained related to the design, development and implementation of the autonomous system, according to the methodology and materials described in section II.

Design and architecture
Based on the description of the WoT standard, our system is composed of three elements: the air quality sensor, the WoT Gateway, and the Smart House devices. The interrelation of these elements is presented in Figure 1.
Air quality sensor: which has the peculiarity of being managed with an ESP8266 microcontroller, with WiFi connection capability. This element has the ability to communicate both in client mode and server, to allow the device to operate passively (i.e. responds only to requests from the WoT Gateway) and proactive (send notifications in case of detection of high levels of contamination).
WoT Gateway: Using HTTPS protocol and JSON-LD to transmit information it is capable of managing read and write request from external clients (i.e. a user or service outside Smart House environment) or internal clients (i.e. Smart House devices and services). It exposes a list of associated devices including a short description through WoT Thing description specification, which provides communication and security requirements to access the devices´ available properties, actions (or programmed functions) and events [22]. The list of devices and their current status are updated in a cloud database to maintain system consistency and ease service creation.
Smart House Actuators: Windows, doors, lights and air circulation systems are connected to the KNX ® [23] hardware and fully operable through WoT Gateway, ready to respond to its requests.
The WoT architecture allows several combinations Thingto-Thing and gateway models [24]. This approach allows not only to improve and extend the network but also to compose new services taking advantage of existing ones by simply merging their data, functions and measurements into a new one. Given the flexibility that WoT provides, it was possible to reconfigure the proposed standard models and adapted them to improve our use case. We have named this adaptation Thing-to-Thing-to-gateway. These functions are applied as follows: Gateway Mode: This mode operates by default in the network over all devices of the Smart House Living Lab (controlled through KNX ® ) and those outside must have an established communication through the gateway by previously authenticating credentials, in order to centralize communication and data to obtain greater possibilities of control and create new services.
Thing-to-Thing-to-Gateway mode: is executed in case of triggering a security protocol. When the air quality sensor (Thing 1) detects that the pollutant values in the dwelling are harmful to the health of the users, it sends directly to the corresponding actuator (Thing 2) the instruction to be activated and in parallel the gateway is informed regarding the current status and the Start Emergency Protocol activation.

Development
In this subsection we present the developments made for each of the elements that are part of the final solution: Air quality sensor: For the development of this element the Arduino IDE [25] has been used as programming software for the microcontroller, taking advantage of the compatibility of the ESP8266 with this development platform. On the other hand, a serial communication was implemented between the SDS011 sensor and the microcontroller to obtain the sensor data.
To establish the priority of the data received, the calculation of the Air Quality Index (AQI) has been implemented according to the standard of the European Environment Agency [26], so that depending on the index obtained the device will make the appropriate decision to interact, as shown in the following diagram presented in Figure 2.
As can be seen in Figure 2, an action priority was established according to the air quality measured by the sensor. When the pollution levels are within the acceptable range (PM 2.5 concentration between 0 and 20 μg/m3), the microcontroller simply stores the data in order to send the information when the WoT Gateway requests an update of this sensor. In case of detecting moderate levels of pollution (between 20-25 μg/m3), the ESP8266 proactively sends a notification to the WoT Gateway with the pertinent information, with which an intervention could be made to the user (e.g. a recommendation to open the windows to have a natural ventilation). Finally, when the AQI reaches high-risk levels (above 25 μg/m3), the emergency protocol is activated, where the microcontroller sends directly to a house appliance (e.g. air extractor of the kitchen, air purifier, windows, etc.) an activation signal to turn it on, off or make an adjustment in order to reduce the pollution levels in the room. In addition, a notification is sent to the WoT Gateway.
WoT Gateway: It is an implementation of the WoT architecture as seen in Figure 3. This WoT Gateway offers the possibility to access, find, share and compose services based on IoT technology. The main functions that allow gateway's deployment are: Access through Authentication (Layer 1): For nonauthenticated clients the WoT Gateway offers guidelines to perform login via JWT authentication,  which consists in a HTTPS POST request to "/auth" endpoint including username and password. If those are correct, a JWT is generated and returned to the client in order to be used for every further interaction.
Find (Layer 2): After authentication it is possible to find out which devices belong to the network through a GET request to "/things" endpoint. Figure 4 shows a simplified description for all available devices returned after this request, showing the methods and requirements to access each one, as well as the authentication path to allow access and control any of them. In this example, the list can be found as a Living Lab Property, under "devices" key.

Share (Layer 3):
Devices description (containing its properties, actions and associated events) are presented in a JSON-LD format [27]. By means of a JSON-LD processor it's possible to map machine understandable vocabulary, from one or many ontologies, into hardware controller commands. Through a GET request to "/things/ThingID" endpoint, a device description is returned including their formal names, access URL and specific interaction method (see Figure 5). An important detail to be mentioned is that the Smart House devices are semantically defined by JSON-LD which annotate the universAAL IoT Device Ontology [28]. This description makes possible to share semantic data when needed to other applications. By executing a GET request to "/things/ThingID/properties" it is possible to discover device properties. These are presented as a list (see Figure 5) of variables related to each device's nature and will expose the input and output value types that will be returned.
Device Register to Compose (Layer 4): external devices are also allowed to join WoT Gateway's device list by performing a PUT request to "/things/add" endpoint including a well formed JSON-LD as a descriptor of a universAAL IoT device. Through this action, the gateway will include them in the same format as the fix ones, assigning them the same properties in terms of security, interaction modes, actions definition and so on. This feature allows to the gateway to compose a WoT ecosystem. Furthermore, this is a main functionality to allow the system to be executed, as it allows to compose the service that will control and manage air quality parameters.
Smart House: The SHLL is a completely automated environment. It has windows, blinds, ventilation systems, refrigeration, lights and automated doors that are controlled by KNX protocol [20]. For our development we use the windows and ventilation systems, necessary to manage air quality. The WoT Gateway interacts with the KNX buses to read and write devices commands and values, acting as an orchestrator, allowing the exposure, consumption of devices and new services composition [17].

Test and Evaluation
Once the different elements of the solution were developed, the corresponding tests were carried out to verify their functionality. For the WoT Gateway tests, the following scenarios were simulated using the Postman App [21], in order to see the response of the different elements of the solution according to the established protocol: Register a new device.  On the other hand, tests were carried out at the microcontroller level, to evaluate the action protocol described in the previous subsection. In addition, tests were performed simulating the same scenarios described for the WoT Gateway in other observe correct performance of the solution. Figures 5, 6 and 7, present the results of the different test performed of the developed system.
As we can see, Figure 5 shows AQSensor description using the WoT thing descriptor where name, properties, security schema, context definition, device and properties URL and general description are displayed. Figure 6 presents a GET request to "/things/ThingID/properties/status" returned Air Quality sensor PM2.5 and PM10 values in a JSON format. Response also adds relevant information such as sensor current status, IP address and last measurement time stamp as a reference to its internal measurement data log. Finally, Figure 7 shows WoT Gateway response issuing a Token when receiving the correct parameters (username and password) in JSON.
As a final test, the full system was deployed in the SH living lab in order to evaluate the performance of the solution according the flow described in Figure 2. The system was constantly monitoring pollution levels in the kitchen area of the SH, and PM 2.5 was produced deliberately by burning cooking oil in order to stimulate the system to activate the emergency protocol. Table 1 present the results of this procedure.
As shown in Table 1, the system is reacting accordingly when the pollution levels detected rises over the established threshold. In the described scenario, the Air quality sensor activates the emergency protocol (sensor status) and sends the command to open the kitchen window (Message), saves the timestamp of the activity and, finally, updates the new device status in the gateway. When the pollution levels are low, the system does not activate any protocol and keep monitoring.

IV. DICUSSION AND CONCLUSION
The developed system is a novel tool to improve people's quality of life based on the autonomous management of air quality. In addition, it is a contribution to expand the interoperability of multiple devices in an agnostic and simple way with the use of the WoT Standard. Moreover, we set the foundations to support merging technologies from diverse areas of interest without losing the platform usability and replicability, as a key factor to build a solid, scalable and agnostic platform. Ultimately, Web of Things Standard`s flexibility and adaptability was implemented by designing and testing a modular system which adapts to our Living Lab model but, at the same time, allows us to extrapolate to other tests conditions by simply rearranging Things attributes' hierarchy and interaction schema.
The solution is easily scalable and can be extrapolated to other environments thanks to the Web of Things standard. Future work should expand WoT Gateway functionality by completing full standard implementation, as final version has not been released yet. Actions and events will be further developed in order to better describe all possible interactions for every entity. Additionally, agnostic functions, models and methods could be integrated to be adopted by every service or device within the network in order to compose complex and powerful services which will store data in a unique database, enabling to generate useful resources for machine learning and analytics engines. Once these improvements are included, our development can be implemented in more complex scenarios such as industries, which seek to improve the efficiency of their processes and the safety of their workers; as well as in cities, which seek improvement in the management of the public services they provide and that allow implementing new and more efficient public policies that benefit citizens. Other interesting area that could benefit from implementing this technology is Healthcare system. By adopting FHIR HL-7 [29], healthcare records, images, wearable technology data and professional recommendations can be integrated, combined and processed within this service aiming to obtain better and faster diagnostics and better recommendations. The integration of innovative technological solutions like the one presented in this work will be fundamental to make a change that benefits everyone equally.