Development and Assessment of an Indoor Air Quality Control IoT-Based System

Abstract

Good health and well-being are primary goals within the list of Sustainable Development Goals (SDGs) proposed by the United Nations (UN) in 2015. New technologies, such as Internet of Things (IoT) and Cloud Computing, can aid to achieve that goal by enabling people to improve their lifestyles and have a more healthy and comfortable life. Pollution monitoring is especially important in order to avoid exposure to fine particles and to control the impact of human activity on the natural environment. Some of the sources of hazardous gas emissions can be found indoors. For instance, carbon monoxide (CO), which is considered a silent killer because it can cause death, is emitted by water heaters and heaters that rely on fossil fuels. Existing solutions for indoor pollution monitoring suffer from some drawbacks that make their implementation impossible for households with limited financial resources. This paper presents the development of IdeAir, a low-cost IoT-based air quality monitoring system that aims to reduce the disadvantages of existing systems. IdeAir was designed as a proof of concept to capture and determine the concentrations of harmful gases in indoor environments and, depending on their concentration levels, issue alarms and notifications, turn on the fan, and/or open the door. It has been developed following the Test-Driven Development Methodology for IoT-based Systems (TDDM4IoTS), which, together with the tool (based on this methodology) used for the automation of the development of IoT-based systems, has facilitated the work of the developers. Preliminary results on the functioning of IdeAir show a high level of acceptance by potential users.

1. Introduction

In 2015, the United Nations (UN) listed a set of 17 Sustainable Development Goals (SDGs) [1] to be achieved by 2030, including a target primary goal of good health and well-being (SDG3). In that sense, new technologies, such as Internet of Things (IoT) and Cloud Computing, aim to enable people to live a more comfortable and healthy life, thereby improving their lifestyles [2]. People are directly benefiting from the application of IoT in domains such as patient care and health monitoring [3], elderly care [4], smart cities [5], smart transportation [6], smart agriculture [7,8], and food supply chain [9]. Other IoT application domains include the monitoring and control of water [8] and environmental pollution [8,10]. IoT has been particularly applied to reduce pollution [11]. From the perspective of sustainability, this is of great significance, since one specific goal mentioned by the UN to be able to achieve SDG3 is to monitor and control air pollution, considering that this problem causes around 7 million deaths per year (of which 1.7 million are children) due to both indoor and outdoor exposure to hazardous fine particles [12,13].

Air pollution is determined by the concentration level of toxic gases in the environment. Environmental pollutant gases include ground-level ozone (O₃), carbon monoxide (CO), carbon dioxide (CO₂), ammonia (NH₃), nitrogen dioxide (NO₂), sulphur dioxide (SO₂), benzene (C₆H₆), and airborne particulate matter (PM) [13]. These gases usually arise from burning fossil fuels in vehicles, refineries, thermoelectric power generators, industries, and even in home appliances [14], such as heaters used to warm air and water. Above certain concentration levels, these gases cause potential harm to human health and, in the worst cases, death [14,15]. This problem is especially important in high-altitude populations with a low concentration of oxygen [16]. Concern to prevent these pollution-related deaths worldwide has led researchers to look for possible solutions to determine pollution levels by using sensors [12,13,17] or image perception [18], and by applying machine-learning algorithms to predict pollution [19,20]. This concern has even led the World Health Organization (WHO) to update air quality indicators to improve this universal right [21].

Heaters are used to condition the temperature of rooms, and water heaters are used to heat water at homes in cold climates. These appliances, being powered by fossil fuels, emit gases such as CO, which, due to its characteristics (odourless, invisible, tasteless, and non-irritating to the eyes), is challenging to detect and is therefore one of the most dangerous gases. In fact, CO is considered as the silent killer [22]. This problem, along with the consequences of the possible misuse of space heaters, has concerned several governments, such as those of Argentina [23] and Ecuador [24], among others.

Health care costs due to air pollution reach $150 billion annually in the US [25]. Transport is the leading cause of CO₂ air pollution [26]. In 2021, 70% of vehicles sold were fossil fuel vehicles [27]. Over the years, vehicles emit more polluting gases. In developing countries, such as Ecuador, the valuable life of private service vehicles is unlimited and that of public service vehicles is up to 15 years or more, depending on the type of service (taxis, urban, interstate, and rural buses). These types of policies aggravate the problem of indoor pollution, considering that inhabitants adapt part of their homes as garages, and the ignition of cars can pollute the interior of homes. Likewise, the act of parking a vehicle can also pollute the indoor environment of the home [28].

Bommi et al. [29] present an up-and-coming solution to control and even attempt to solve the problem of environmental pollution. However, due to the considerable financial investment required, applying it to the economically poor households that use the most heaters would not be feasible. Another work on air quality monitoring is proposed by Zhou et al. [30], which consists of a system to alert users through messages when pollution levels exceed certain thresholds. To reduce pollution levels, this system turns on a fan, which would be insufficient in an enclosed space, such as inside a house.

The work presented here proposes an IoT-based system (IoTS) to reduce the number of people suffering from poisoning by hazardous gases, such as CO, CO₂, NO₂, NH₃, and C₆H₆ [13]. This system, called IdeAir (contraction of “Ideal Air”), fulfils the functions of monitoring and trying to reduce indoor pollution levels as well as alerting users when pollution reaches dangerous levels. Following its deployment as a proof of concept, a technical demonstration of its implementation was carried out in the cold climate city of Quito, the capital of Ecuador, located at an altitude of 2850 m, where several deaths have occurred due to problems with heating systems [15]. In addition, another demonstration was carried out in the city of Quevedo (Ecuador), with a sub-humid-tropical climate, located at an altitude of between 60 and 110 m above sea level, where people from neighbouring cities were brought together.

The main technical contribution of IdeAir is that it delivers an IoTS that provides a reliable solution with a feasible and low-cost implementation to address the social problem described above, which is directly related to the UN’s SDG3. From a scientific perspective, IdeAir is a case study to validate a development methodology proposed by Guerrero-Ulloa et al. [31], as it is a new methodology and one of the few methodologies designed specifically for IoTS development.

The remainder of this document is organised as follows: Section 2 presents the related work. Section 3 describes the proposed system, the development methodology followed, and the results obtained by applying each of the phases of this methodology. Section 4 analyses the results of the assessment carried out to validate the proof of concept developed for IdeAir. Section 5 discusses the main outcomes obtained with the proposal presented in this paper. Finally, Section 6 outlines the conclusions and future work.

2. Related Work

The world is concerned about air pollution and its fatal consequences. One of the measures to raise public awareness about this problem is the construction of data repositories such as the "World’s Air Pollution: Real-time Air Quality Index" website, where the pollution of some of the major cities of the world can be observed [32]. In addition, the global concern is reflected in the fact that the WHO has issued new guidelines for controlling air pollution, considering particulate matter (PM) from a size of 2.5 µm [19,21]. PM is the direct cause of respiratory diseases in humans [19,25].

Moreover, the scientific community has made some proposals to help alleviate the consequences of air pollution and improve air quality. In this section, we are going to present the most relevant and related ones to our proposal.

Some vulnerable people often spend much time indoors, where pollution is higher than in outdoor environments [33]. Solutions for these spaces have been presented [10,33], with the objective of reducing pollution-related risks within homes and workplaces [34]. In that sense, Bommi et al. [29] aim to control air pollution by reducing the toxicity of gases produced by combustion through a physic-chemical process that generates oxygen.

With regards to pollution monitoring, we found a study by Liu et al. [35], whose work is concerned with CO₂ and PM_2.5, among other parameters. Kotsev et al. [36] present AirSensEUR for pollutant monitoring, consisting of a plug-and-play interoperable sensor node designed as an open multi-sensor platform, with an investment of about 1000 euros. Another work on indoor air pollution monitoring concerns iAir, proposed by Marques and Pintarma [10] for buildings. Although iAir allows building managers to query ambient unhealthiness levels and send notifications via a smartphone app, its authors do not mention other means of alerting people inside the building about dangerous pollution levels.

Taştan and Gökozan [37] present a mobile real-time air quality monitoring system called e-nose. It fulfils the functions of measuring various air parameters (CO₂, CO, NO₂, PM₁₀, temperature, and humidity) and alerts users about dangerous levels of pollutants. However, the only form of alerting allowed by the system is through notifications sent to the mobile application. Another related work is that of Zakaria et al. [38], which provides air quality readings using low-cost sensors and shows data visualization through a web application that they have implemented. Its authors use a Raspberry Pi, which is connected to the internet via Wi-Fi for sending data to feed the web application. The use of single-board computers, such as Raspberry Pi, enables enhancing the functionalities of the system, but makes it more expensive.

The works reviewed provide solutions to help prevent people from environmental conditions detrimental to their health. However, each one has some characteristics that lead to an impractical implementation in low-income households. In the case of the systems respectively presented by Bommi et al. [29] and Liu et al. [35], their main disadvantage is the high investment required. In addition, the laser used to obtain oxygen in the former has to be activated manually when the CO value exceeds a threshold value, while the latter system is intended for smart buildings, just like iAir [10].

Moreover, the systems analysed, except for the one by Bommi et al. [29], do not have adequate mechanisms to improve air quality. Another drawback of all the reviewed works [29,35,36,37,38] is the limitation of the medium in which the notifications are provided to end users, since they are only displayed to them through the mobile application. The system proposed by Zararia et al. [38] sends notifications by email, which is ineffective in emergencies. In addition, this is also a solution with a considerable cost.

To solve the drawbacks of the existing systems reviewed, we designed and developed a proof-of-concept for IdeAir, which is a low-cost IoTS with scarce energy consumption that has goals in common with some other works analysed in the review carried out by Zhao et al. [13]. IdeAir consists of: (1) a device that is deployed inside a house or workplace to detect and monitor indoor pollution and issue alerts when needed, (2) a mobile application to configure the device, view real-time data, and receive alerts on pollution levels, and (3) a web application that, in addition to having the same functions as the mobile application, is used to view reports of the data captured by the system and additional information from IdeAir. As new and modern buildings are equipped with wireless communication technologies [2], and many older buildings have been adapted to equip them with such technologies, IdeAir aims to take advantage of this and uses the internet connection via Wi-Fi to send data between its different components.

3. Proposed System

The proposed IdeAir system continuously senses the concentration of certain gases and provides real-time information on indoor air quality levels, showing reports with the current values of the gases considered and allowing queries on historical data. In addition, when needed, it alerts users in many ways, and attempts to reduce indoor pollution levels. Alerts depend on the levels of air pollution detected. Four levels of CO have been considered for this work to determine air quality, as proposed by the Ministry of Labour and Social Affairs of Spain [39], and shown in

Table 1. Air quality levels [39].

Level	Quality	Concentration (ppm)	Notifications (Light)	Actions
1	Good	≤350	Green	No sound and no other action.
2	Moderate	(350, 500]	Blue	Intermittent beep.
3	Low	(500, 800]	Orange	Medium and constant sound, and window opened.
4	Poor	>800	Red	Loud and constant sound, window opened, fan switched on, and notification sent to the mobile app.

. In addition, for each CO concentration level, the system displays the corresponding message on its LCD screen.

As shown in Table 1, a concentration above 800 ppm (parts per million) has been considered the most hazardous [25]. Table 1 also shows the alerts (light and sound) and actions implemented in IdeAir for the four air quality levels considered.

IdeAir is an IoTS developed to support low-income families who may be at risk from the indoor use of water heaters or other similar equipment fuelled by fossil fuels and other materials that can generate polluting gases. In addition, IdeAir is a low energy consumption system.

3.1. Development Methodology

IdeAir was developed as a proof of concept, in order to verify its functionality and effectiveness. The development methodology used was TDDM4IoTS, which specifies four roles to be played by the project team members [31]. Figure 1 shows the IoTS development lifecycle stages defined in TDDM4IoTS, with the execution sequence suggested by the authors.

In our case, the role of project facilitator was played by an IoTS development expert. The development team consisted of two developers with experience in IoTS and traditional information systems (IS) development. The role of advisor was played alternatively by the two developers, depending on each one’s mastery of the subject (hardware, graphical user interfaces, web applications, mobile applications, web services, database, etc.) to be applied in each activity. The advantage of this role-play is to try to balance the mastery of the topics needed in IoTS development. For the development of IdeAir, the functional requirements and some non-functional requirements were pointed out by people (users/customers) living in the city of Quito. Therefore, the requirements considered were provided by people with real needs.

Communication between project members was 90% telematic, as they were geographically dispersed. Meetings were held weekly by videoconference. Therefore, consultations and pieces of advice, as well as the delivery of software material, were carried out remotely. GitHub was used for software version control and teamwork. Hardware was provided through periodic face-to-face meetings with the project facilitator or ordered directly from suppliers via their respective online purchasing platforms.

To develop IdeAir, we tried to carry out the activities of the 11 development phases of the methodology, in their order, as specified in TDDM4IoTS [31]. The execution of such activities and the results obtained with each of them are shown in the following subsection.

3.2. Results of the Application of TDDM4IoTS to This Case Study

The following details the work carried out in each development phase specified by TDDM4IoTS [31] to successfully obtain the final product.

3.2.1. Preliminary Analysis

IdeAir is a system that can be considered relatively small. However, a preliminary analysis phase is necessary to have a solid starting point. This phase, which allows knowledge of the initial conditions of the environment in which the system will be deployed, as well as determining whether it is feasible to meet the requirements demanded by the user, involves the following activities:

Requirements analysis. A safe indoor environment is necessary. Poor installation, daily use, or sudden breakdowns of water heaters and/or space heaters can produce varying amounts of toxic gases due to poor combustion. When it comes to the home environment, these problems can cause damage to the health of its inhabitants and even death. The user must stay at home resting, doing household chores, or working (in times of pandemics, for example) [5]. To reassure users, the concentration of harmful gases and the concentration of PM_2.5 and PM₁₀ should be determined, and users should be informed as soon as possible of the danger to which they are exposed when this is the case so that they can take appropriate measures, if necessary.

Through formal and informal interviews with a group of people in the city of Quito as clients/end users, the existing problems in the homes of those involved were determined. Thus, the requirements of IdeAir were established, including the following:

• Detection of harmful gases, particularly CO, O₃, CO₂, NO₂, NH₃, and C₆H₆.
• Alert the user who is inside the dwelling.
• Alert the user who is away from home.
• Causing the detected gases to dissipate into the environment or vented to the outside.

Once the system requirements had been collected and roughly analysed, it was possible to determine how to satisfy them by employing a suitable solution. From the requirements established, we derived the possible tasks to be performed in the different phases of TDDM4IoTS. The activities, their priority, and the estimated time for their development were determined by the development team and the project facilitator. The priority was related to the importance of the activity to be able to achieve the final product, and its dependencies with other activities. For example, requirements analysis needs to be addressed before designing the technology layer. Additionally, the design of the mobile application was necessary before its implementation could be started and having an implementation of the mobile application is vital to get the final system. Non-functional requirements, such as widespread availability of hardware/software components, low cost, and energy efficiency, were considered at all phases. The planning of all the tasks to be carried out to develop the IdeAir IoTS, as well as their priority and the estimated hours to perform each of them, are shown in

Table 2. Tasks to be carried out in the development of IdeAir.

Task	Priority	Estimated Hours
Preliminary analysis	20
Requirements analysis (elicitation and analysis)	High	7
Analysis of the environment in which it will be deployed	Low	1
Technology analysis	Medium	8
Feasibility analysis	Low	4
Design of the technology layer	33
IdeAir Architecture	Medium	8
IdeAir deployment diagram	Low	5
Logical/physical design of the IoT device	Medium	20
Detailed analysis of requirements	18
Use case diagrams	Medium	2
Description of use cases	Medium	16
Model generation and adaptation	51.05
Front-end design of the web application	High	24
Front-end design of the mobile application	High	24
Automatic generation of models	High	0.05
Adaptation of models	High	3
Test generation	2.05
Automatic generation of unit tests	High	0.05
Creating unit tests	High	2
Software generation	82
Database implementation	High	2
Creation of API for sending and receiving data	High	8
Implementation of the sending of data collected by sensors	High	8
Implementation of the web application	High	32
Implementation of the mobile application	High	32
Software and hardware implementation	12
Component testing and calibration	Medium	5
Integration tests for the system and its components	High	6
Deployment of the web application on the server provided for this purpose (and for downloading the mobile app)	Medium	1
Check the correct communication of the system *	High	24
Total hours	218.10

^* Follow-up time is not counted as development time.

.

Technology analysis. All the points raised by the methodology in this activity were answered positively. In other words, all the necessary hardware resources were widely available, low cost, and efficient in fulfilling their functions. In addition, the device’s energy consumption could be minimised by using components with favourable characteristics or by reducing the device’s functionalities when they are not necessary; for example, reducing the frequency of sending data when these are constant and non-hazardous.

The software tools for IoTS hardware configuration that must be used, such as the Arduino IDE and the TDDT4IoTS (Test-Driven Development Tool for IoTS) web application [40], are available to everyone and free of charge.

In this methodology activity, we had to compare the different options for both hardware and software components. Indicators that determined which ones to select and use for this project included functionalities, learning curve, mastery by the development team, cost, size, power consumption, popularity of use, integration between hardware and software, among others.

Table 3. Hardware components selected to be used in the project.

Requirement	Selected Components	Alternative Components (Among Others)	Selection Criteria Applied
Sound notification	Active Buzzer	Piezoelectric Buzzer	Fulfilment of the required functionalities.
Text notification	LCD 16x2 iC2	LCD 10x4, LCD In-Plane Switching, LCD Led, OLED Display, LCD TFF	Fulfilment of the functionalities, lower cost, ease of use, proficiency of the development team in its use, and abundant supporting documentation.
CO detection	MQ7	MQ2, MQ135	Increased sensitivity to carbon monoxide [41].
CO2 detection	MQ135	MOX [12]	More suitable for NH3, CO2, NOx, alcohol, benzene, and smoke, including CO [41,42]; more economic.
Open and close the window	Tower Pro SG90 Servomotor	16-Channel I2c Servo Motor I2c Pca9685 Robot, Servo Motor Mg996r High Torque Servo Motor	Fulfilment of the functionalities, inexpensive, better compatibility, sufficient documentation, mastery by the development team, and smaller size [43].
Pre-processing data acquisition	Arduino UNO R3	Arduino Mega, Raspberry Pi, and other Arduino-like development boards	Fulfilment of the functionalities, proficiency in its use by developers, smaller size, lower cost, and more documentation.
Data communication via Wi-Fi	ESP8266 NodeMCU	ESP32 Wi-Fi Module, HC-05 Bluetooth Module, Regular ESP8266	Fulfilment of the functionalities [42], data communication via Wi-Fi, and development board to complement the control of the sensors to be used.
Light notifications	One RGB LED	Green, blue, orange, and red LEDs	Fulfilment of the functionality, less space and less pins used on the board, smaller circuit size, and more economical.

shows the hardware components chosen for our project as well as the selection criteria applied to choose each of them among the different alternatives available.

The tools selected for the development of this case study were: TDDT4IoTS, for the design and generation of models and code for both (web and mobile) applications, as well as for the design of the hardware connections and generation of the code for its configuration (to be burned on the Arduino board); Arduino IDE, for compiling and editing the programming code for the hardware configuration; Apache NetBeans IDE with Java, for completing and refactoring the web application code; Android Studio, for completing and compiling the mobile application software and generating the application (apk file) for the Android operating system; MySQL, as the database; and WebHost, as the web and database server.

Analysis of the environment. The device will be installed in low-income households and strategically placed near a source of electricity. In these pandemic times, families are forced to contract internet services so that students can perform their homework and adults can telework, so they have this service through Wi-Fi (standard IEEE 802.11) connection. It can be implemented with Zigbee (standard IEEE 802.15.4-2003) technology [12]. Although energy consumption is not a concern for IdeAir, economic savings are sought [17]. IdeAir will use this resource to send data to the cloud in real time via web services. The user will be notified the moment the gas concentration changes. As the environment is silent, one way of alerting users at home will be through sounds, lights, and notifications sent to their smartphones, provided they have installed the mobile app.

The variety of ways in which notifications are presented allows for the safety of vulnerable people, who are the ones who stay at home the longest.

Feasibility analysis. The study that was carried out determined the feasibility of the development of IdeAir considering the following three aspects:

• Technical: Regarding this aspect, the following questions were formulated and answered. (a) Do the necessary technologies exist to develop the project? The technologies necessary for the development of the system exist in the market and are easy to acquire. (b) Are there trained personnel to develop the system? The development team’s skills are considered sufficient, given their previous experience. (c) Can the system be developed? Yes, and the existing technologies to do so and the estimated development time are considered adequate by both the developers and the users.
• Economic: This aspect is related to the budget allocated to the system development. Any project is feasible to develop with an unlimited budget [44]. However, this is not our case. Therefore, to determine the success of the development concerning the economic aspect, we had to answer the following question: is there an adequate budget to develop the project? The answer was yes, since the components to be used, which were identified after a preliminary design was carried out, were low in cost and available on the local market (see the final part of Section 3.2.2 for more details regarding the cost analysis of the hardware components of the proposed IoTS).
• Operational: Similar to what was done in the previous aspects of the feasibility study, TDDM4IoTS suggests answering the following questions to determine the operational feasibility of the project. (a) Will it be possible to install the system once completed? IdeAir should be designed to be installed in a home with standard features at this time, i.e., internet service through a Wi-Fi connection and electrical power service with a free outlet to power the device. However, IdeAir will be built as a prototype to be tested in a mock-up with all the necessary features to guarantee its functionality in real environments. (b) Will the system be able to work with the available resources? Wi-Fi internet service has proliferated for some years in cities where electric power service is guaranteed. The house taken as a possible model of a real environment to deploy IdeAir has both services. In addition, a private application server is available for data persistence, cloud computing, and information exchange between both (web and mobile) applications [45]. Consequently, once the system is deployed, the user does not need any technical knowledge to keep it running. (c) Are safeguards in place to ensure the system continues to function once installed? Although the device is going to be designed to be powered from a mains socket, it will also have a built-in battery in case of power failure. In terms of communications, in the event of internet service failure, the user could easily configure the device to work with another Wi-Fi network at any time (e.g., the mobile phone could act as a gateway). (d) Will the IoTS have properly scheduled maintenance? IdeAir does not require daily maintenance. However, several types of maintenance can be carried out when needed. Preventive maintenance, which consists of keeping the device dust free, keeping the battery charged so that it is ready to power the device in case of power outages, and checking the Wi-Fi connection so that data is sent in real-time. Detective maintenance [46], which may require some knowledge or the use of similar equipment that performs the same functions in the detection of gaseous and particulate air pollutants to check the correct operation of IdeAir. Finally, as corrective maintenance is more specialised, it will have to be carried out by personnel able to calibrate and/or replace components in case of failure of their functions. It is foreseen that components will be replaced at the end of their useful life.

3.2.2. Design of the Technological Layer

In this stage, all the members of the project participated in the design of the technological layer since that design would determine how to produce all the deliverables in the next stages of the development. The outcomes of this design work produced an architecture for IdeAir, a device design, and a more detailed understanding about how data capture and alert notifications would be approached. Furthermore, once a preliminary design of the IoTS to be developed has been made, a cost analysis of the hardware components that said system should integrate can be carried out. All these aspects will be explained in more detail in the rest of this subsection.

IdeAir architecture. The architecture of the IdeAir system, consisting of 3 layers, was first designed (see Figure 2). The top layer is the User interaction layer, consisting of two (web and mobile) applications through which users will be able to interact with the system. The lower layer is called the Physical and preprocessing layer because it is where sensors and actuators are, and where preprocessing of the information sensed by the sensors is carried out. This layer performs the functions of monitoring and controlling the environment. The middle layer, called the Cloud computing layer, is the one in which connectivity as well as processing and storage of the information is carried out. In this layer, the WebHost service is located, which is used to send data in real time to be stored in the MySQL database and displayed in both (web and mobile) applications.

IdeAir device design. Figure 3 shows the design of the device (corresponding to the physical layer) to detect the level of air quality and act appropriately (according to its configuration) to alert the inhabitants of the house and watch over their health when the air quality is not adequate. This scheme has been designed using TDDT4IoTS [40]. Its components are (see Figure 3): (a) Arduino UNO board, configured to capture the data sent by the MQ135 and MQ7 sensors, as well as to give the commands to the actuators; (b) an active buzzer, for sound notifications; (c) LEDs, for light notifications; (d) ESP3286 NodeMCU, a development board to control the DHT11 sensor and for internet connectivity; (e) DHT11 sensor, to measure ambient temperature and humidity; (f) MQ135 sensor, to detect CO₂, C₆H₆, NH₃, and NO₂; (g) MQ7 sensor, to detect CO; (h) servo motors, to open and close the window; (i) LCD screen, to report on the ambient air quality; and (j) fans, to exhaust polluted air. Regarding the power supply (VCC), it can be any 5V source as indicated in the represented scheme.

TDDM4IoTS [31] is presented as an interactive methodology. In it, some stages, such as the preliminary analysis and the design of the technological layer, will not have to be repeated for each deliverable, but only once (in the first iteration). This was the case for the development of IdeAir, where the preliminary analysis and technology layer design stages were executed only in the first iteration. This system’s requirements were clear and concrete from the early stages. In addition, the involvement of users at this stage was instrumental in ensuring that the system’s design met their needs.

Each of the components used has been accurately detailed so that the reader can quickly determine the final value (i.e., money to be paid in their local market) they would have to invest in constructing a device such as the one described here.

IdeAir device cost analysis. Commercially branded air-quality-control devices that interact with mobile applications are expensive for a low-income family. To try to solve this problem, the device design proposed herein has an implementation cost of less than 10% of the total cost of other similar commercially available devices. To demonstrate this, we compared the total cost of the proposed IoTS hardware components (shown in

Table 4. Cost of the hardware components required to implement the IdeAir device.

Device	Quantity	Unit Cost	Total Cost
Active Buzzer	1	$0.70	$0.70
20cm breadboard cable—Type: Female-Male	20	$0.075	$1.50
20cm breadboard cable—Type: Male-Male	40	$0.075	$3.00
RGB Led	1	$0.09	$0.09
LCD 16x2—Colour: Green	1	$3.75	$3.75
Protoboard 830 Points 1T2D	1	$3.33	$3.33
1/4W carbon electrical resistor	6	$0.02	$0.12
Gas sensor for Arduino®—Type: MQ7	1	$1.77	$1.77
Gas sensor for Arduino®—Type: MQ135	1	$1.77	$1.77
Tower Pro SG90 Servomotor 1.8kg-cm *	2	$1.60	$3.20
UNO R3 for Arduino®	1	$28.50	$28.50
Fan 12VDC *	2	$6.50	$13.00
ESP8266 NodeMCU Wi-Fi Module	1	$4.00	$4.00
TOTAL COSTS			$48.53

* Value not considered in the proof of concept.

; all of these prices have been consulted on Amazon, https://www.amazon.com/, accessed on 12 January 2022) with that of one of the currently marketed air-quality-control devices (e.g., see [47]). In addition, commercially available devices cannot control the opening and closing of windows to dissipate the hazardous gases inside the dwelling and expel them outside, and typically only detect one or very few of those hazardous gases.

Data capture and alerting method.Figure 4 depicts how IdeAir works from an operational perspective. Gases are detected by the MQ135, MQ7, and DTH-11 sensors, and sent to the cloud via ESP8266 using RESTful Web Services. In case there is no internet connection, the system works locally, issuing alerts and making the necessary decisions to try to ensure adequate air quality. System decision making is based on conditional clauses to determine if significant changes in contamination levels occur, and especially if contamination levels exceed permitted thresholds. The results of this decision making are reflected in the issuance of alerts in the user environment and through the web and mobile applications. Both (web and mobile) applications display real-time data received via WebSocket, as well as displaying historical data by dates via SQL (Structured Query Language) statements and stored procedures executed in the MySQL database via JDBC (Java EE Database Connectivity). Data captured by the sensors integrated into the IdeAir device are preprocessed to detect the aforementioned changes and issue the corresponding notifications regardless of whether there is an internet connection or not. These data are sent for storage when the connection is re-established.

3.2.3. Detailed Requirements Analysis

This and subsequent stages were executed for each deliverable. The main deliverables of interest to the client are the device, the mobile application, and the web application. We used the extended use cases [48] for the detailed requirements analysis, as recommended by TDDM4IoTS [31]. Use cases have proven to be a prominent tool for collecting the functional requirements of the system expressed by the users [49]. By performing a detailed analysis of each use case and using TDDT4IoTS [40] correctly, developing an IoTS is easier. With TDDT4IoTS, developers (and more specifically, analysts) must focus on writing accurate and well-detailed use cases. This tool uses a language based on punctuation marks to denote the different elements of object-oriented analysis to generate platform-independent models (i.e., class diagrams), the tests to be passed by the software (whose manual generation is considered by many developers as a waste of time [50]), and code snippets of the final software. All of this is based on use cases. The generated software corresponds to a Maven and Spring Boot project containing the entity classes specified in the use cases and the driver classes and web services. As an example,

Table 5. Specification of the use case for issuing notifications.

Use Case:	Issue Notification
Actors:	User
Objective:	Report on the current level of ambient air quality.
Summary:	The user is informed about the air quality level.
Type:	Primary
Prerequisites:	The user must be authenticated in the system.
Postconditions:	Recorded notification data
Normal course of events
Actions	System Responses
1. The user starts the system.	2. Detect the presence of CO in the environment. 3. Calculate CO concentration levels. 4. If the concentration level is above 800 ppm: 4.1. Turn on a red light. 4.2. Reproduce a loud and constant sound. 4.3. Open the window. 4.4. Turn on the fan. 4.5. Send the notification to the user (away from home). 4.3. Display ’Poor air quality’ on the screen. 5. If the concentration level is in the interval [800, 500): 5.1. Turn on an orange light. 5.2. Reproduce a medium and constant sound. 5.3. Open the window. 5.4. Send the notification to the user (away from home). 5.3. Display ’Low air quality’ on the screen. 6. If the concentration level is in the range [500, 350): 6.1. Turn on a blue light, 6.2. Send the notification to the user (away from home). 6.3. Display ’Moderate air quality’ on the screen. 7. If the concentration level is 350 ppm at most: 7.1. Turn on a green light. 7.2. Turn off the sound. 7.3. Display ‘Good air quality’ on the screen. 8. The system registers the data in the database.
Alternative flow
Actions	System Responses
None
Established requirements:	Issue a notification on the detected air quality level.
Points of inclusion:	Data storage
Notes:	Notify the environment and the user about the CO concentration and the air quality.

shows one of the use cases which specifies one of the requirements that IdeAir must meet.

3.2.4. Generation of Models, Tests, and Software

In these three phases of TDDM4IoTS, the TDDT4IoTS development tool was used [40]. We are currently testing the first version of this tool, which can generate the web application software, including its preliminary graphical user interfaces, from the use cases. It also allows the design of IoT devices and automatically generates most of the software required for their configuration and operation (with support for Arduino). Currently, TDDT4IoTS does not generate the interfaces for the mobile application. Therefore, the software for the user interfaces of the IdeAir mobile application (front-end) was created by the developers in its entirety.

As for the web application, TDDTIoTS uses the model-view-controller pattern to generate the source code from the class diagram. In addition, part of the business logic is transformed into classes to generate and publish the RESTful web services, which are used to execute the basic CRUD (create, read, update, delete) operations with the database.

The interested reader can consult the code automatically generated by our tool for both the system software and the tests that said software must pass in the GitHub repository that we created for this project. More specifically, the files containing this code can be found at: https://github.com/gleiston-guerrero/ideair/tree/main/Generated%20code%20for%20TDDT4IoTS/IdeAir%20v1.0/ProjectMvnSpr/src (accessed on 20 December 2022).

3.2.5. Refinement and Adaptation of Models, Tests, and Software

During model refinement, some methods were added, such as constructors and other methods not specified in the use cases, as well as a class for specifying air quality reference levels. Therefore, the accuracy of the platform-independent model depends on the degree of detail with which the use cases are specified using the TDDT4IoTS-specific mark language. Figure 5 shows part of the software architecture (i.e., the class diagram) after being generated by TDDT4IoTS and refined for IdeAir software generation and testing. The automatically generated tests were refined and adapted to the needs of the end users. The developers wrote integration tests in the detailed requirements analysis phase and executed them during deployment to verify compliance. To test the correct functioning of the device before deployment, the environment was polluted by generating the appropriate gases, basically to test real-time data capture and delivery.

In addition, some methods specified in the class diagram had to be implemented by the developers, as their business logic could not be automatically generated in its entirety from the use cases.

3.2.6. Hardware and Software Deployment

The IdeAir device was deployed in a mock-up of a room simulating an actual room to prototype how the system would work. Low-power servo motors were used, which are not sufficient to drive an actual window. With this proof of concept, the authors think there is sufficient evidence to determine that this system meets the requirements set by the client.

The web application is deployed on an affiliation institution server of some of the authors. Moreover, as described above, the mobile application allows registering the IdeAir device(s) for monitoring data captured in real time and receiving notifications when gas levels are harmful to health, as well as performing everyday operations, such as registering as a user, logging in, reporting captured data, and viewing system information. Figure 6 shows some screenshots of the mobile application.

When the user is authenticated in the mobile application, s/he can access her/his information and the options to view the devices and captured data, as shown in Figure 6a. If we do not have registered devices, we can do so from the Device option (third option in the menu shown in Figure 6a), and the screen shown in Figure 6b will appear. Let us now assume that we have at least one IdeAir device registered. In that case, we will be able to monitor the environment in which the device/s is/are installed and see the real-time data that the device is capturing and sending to the server, as shown in Figure 6c.

3.2.7. Assessment of IdeAir

To evaluate the functionality and usability of IdeAir, a survey was carried out among the (28) people who used both (web and mobile) applications to observe/test how the system worked. The participants who collaborated live in various cities across Ecuador, are Spanish-speaking, and have different proficiency levels in mobile and web applications. We provide the results of this survey (in Spanish) in the GitHub repository that we have created for this project. More specifically, the file containing this information can be found at: https://github.com/gleiston-guerrero/ideair/blob/main/Evaluation%20Data/IdeAir%20System%20Evaluation.xlsx (accessed on 20 December 2022).

The respondents were mainly people between 18 and 25 years old (see Figure 7), although there were also a considerable number of people (7) who were between 26 and 30 years old, while there was only one person over 30 years of age.

Although the requirements to be met by the system were initially pointed out by people living in the city of Quito, we can guarantee that IdeAir is able to fulfil such requirements for all its potential users, regardless of where they live. In fact, the largest number of participants were from the cities of Quevedo and Valencia (a neighbouring city to Quevedo), representing more than 50% of those surveyed, while 35.7% of responders were from the city of Quito, and 10.7% lived in other cities (not specified in the survey), with only one person from the city of Quinindé. The specific numbers related to this aspect are shown in Figure 8.

Figure 9 shows the conformance degree of the respondents regarding the functionalities that the hardware fulfils, where 1 is strongly disagree and 5 is strongly agree. In other words, after observing the functioning of the hardware with respect to its main functionalities (gas detection, opening the window, and alerting the inhabitants, if necessary), 82% of the participants agreed the system hardware provides a suitable solution for the problem addressed. Adding all the people who expressed impartiality to this group, it can be affirmed that 96% are positive towards the functionalities of the system. The refusal of one person and the impartiality of four people could be because they do not have the problem of pollution in their cities as is recognised in Quito, the city taken as the focus of this work. Another possible reason could be that it is not a real system.

Figure 10 shows the results regarding the functions implemented in both (mobile and web) applications and their integration. Except for the two people who were unbiased, it can be stated that 100% of participants were positive towards their functionalities. Likewise, 100% of respondents had a positive opinion about the importance of the information displayed by both (mobile and web) applications. More specifically, Figure 10a graphically represents the count of answers given by respondents to the question: "I found that the different functions of the mobile and web applications were well integrated (i.e., they constitute a whole)", while Figure 10b does the same for their answers to the question: "The information (queries and reports) displayed by the mobile and web applications are very important and are in line with the functionalities of the IdeAir device".

Finally, regarding the question: "In general, the IdeAir system (device, and mobile and web applications) is a good solution to prevent problems that can be caused by pollution”, 100% of respondents had a positive perception about the system, with 28.6% of them in the agreed category and 71.4% in the strongly agreed category.

3.2.8. Maintenance of IdeAir

This stage has not been carried out because IdeAir has been developed as a proof of concept, represented in a mock-up of a house. However, for the maintenance of IdeAir as a real system, maintenance has been foreseen in the operational feasibility study.

4. Assessment of TDDM4IoTS

To obtain first-hand information on the effectiveness of the TDDM4IoTS methodology, some IoTSs have been developed with different groups of developers, who contributed with their opinions to obtain an independent evaluation.

To gather developer feedback about TDDM4IoTS, a survey was conducted using the Sphinx software [51], which was filled out anonymously and online by the IoTS development teams that have used TDDM4IoTS. Among the developers who filled out this survey were IdeAir developers. We also provide, the results of this other survey (carried out in Spanish) in the GitHub repository that we have created for this project. More specifically, the file containing this information can be found at: https://github.com/gleiston-guerrero/ideair/blob/main/Evaluation%20Data/TDDM4IoTS%20Evaluation.xlsx (accessed on 20 December 2022).

A total of 39 developers participated in the survey, which was conducted along an academic year. Developer experience varies in the number of IoTSs in which they have participated, ranging from 1 to more than 5 IoTSs, as shown in Figure 11. All the developers have knowledge in systems engineering and software engineering, and they began to develop IoTSs in module 6 (of 10) of their respective academic program.

Figure 12 shows the high degree of developer satisfaction with the TDDM4IoTS methodology, according to the answers given by the respondents. In the opinion of these developers, the two most relevant aspects of TDDM4IoTS are that it covers all software and hardware development activities, and that it appropriately organises the phases and activities that must be carried out.

5. Discussion

From a technical perspective, IdeAir poses certain characteristics that other air quality control systems do not have, such as being low in cost, having the ability to detect multiple hazardous gases, and being energy efficient. The results of the IdeAir assessment show that it could be well-received by potential users. During the testing of IdeAir, users found it more useful and effective to hear the alarm and see the light notifications in the room to alert them about air toxicity levels than the notifications sent to the mobile application. Alarms are notified through redundant actions, including sound, light, and textual, in order to meet the requirements of different types of users because some of them may have special needs. However, to get a final product from the current prototype, further involvement of more customers/end-users is needed. Additionally, the device design should be adapted to be produced in a mass production assembly line. Potentially, such a re-design could further decrease the final cost.

From a theoretical perspective, TDDM4IoTS is one of the few methodologies that covers all the stages that need to be accomplished when developing an IoTS. TDDM4IoTS details certain activities that other methodologies do not consider or leave to the discretion of the developers, such as the analysis of the environment. Being based on TDD (Test-Driven Development) makes it feasible that the final product fulfils the requirements of the end users and that the code can be checked in a systematic manner. Furthermore, the methodology eliminates much of the time spent writing tests (an activity associated to TDD methodologies), which most developers consider ‘wasted time’. Moreover, it is a methodology for IoTS development that especially targets novice developers, since it guides them step by step through all the activities or tasks included in the different development stages considered. In fact, most of the surveyed developers expressed their satisfaction with TDDM4IoTS as a methodology to develop IoTSs, except for 7.69% of them, who were indifferent regarding the use of this methodology, as can be seen in Figure 12.

Finally, we must express our opinion that TDDM4IoTS ought to be applied to the development of more case studies by other developers in order to get additional feedback and comments from more developers and try to detect if the methodology could be improved to more adequately cover some very specific development scenarios.

6. Conclusions and Future Work

In this article, we presented the development of the IdeAir system, which is a low-cost, energy efficient solution to measure indoor air quality, as well as to act and alert people when the level of toxicity is dangerous. Those objectives are within the scope of the UN’s SDG3, and the system particularly targets low-income families using water heaters or other similar equipment fuelled by fossil fuels indoors, which may lead to a high risk to their health due to air pollution. In fact, compared with other air quality monitoring systems, the cost of the proposed solution is around 10% of the total cost of systems with some similar features, although they do not include all the functionality that our IoTS provides.

The system consists of a device to measure air quality and to produce notifications; a set of web services and a WebHost server to be able to retrieve captured data at real time; and a mobile application displaying notifications and real-time data to end users.

The development of IdeAir followed the TDDM4IoTS methodology, which made the developers more orderly in carrying out IoTS development activities. In addition, using the TDDT4IoTS tool helped them to be more productive, and the code generated by the tool was fully utilised.

Regarding future work related to the developed system, after evaluating its functions as a proof of concept, a prototype of the IdeAir system will be developed and deployed in an actual dwelling to evaluate its performance. In addition, IdeAir will be designed as a wireless sensor network to detect possible gases that may be present in a house depending on the environment or room to be monitored. Thus, for example, leaks of liquefied petroleum gas (LPG), used mainly for food cooking, should be detected in the kitchen, and both CO and CO₂ levels should be monitored in the bathroom and living room, due to the use of heaters in both rooms. Consequently, a new device will be designed with all the features of the one presented in this article. Furthermore, end users should be more involved in the design of IdeAir’s web and mobile applications to achieve full acceptance of both applications by all their users. This would eliminate or minimize discrepancies regarding the functionalities and usability provided by both applications.

Moreover, we have plans to improve the TDDT4IoTS tool so that it can generate more code snippets as well as interfaces for mobile applications (both for Android and iOS).