Air quality monitoring is crucial within cities since air pollution is one of the main causes of premature death in Europe. However, performing trustworthy monitoring of urban air quality is not a simple process. Especially, if you want to try to create extensive and timely monitoring of the entire urban area using low-cost sensors. In order to collect reliable measurements from low-cost sensors, a lot of work is required from environmental experts who deploy and maintain the air quality network, and daily calibrate, control, and clean up the data generated by these sensors. In this paper, we describe SenseBoard, an interactive dashboard created to support environmental experts in the sensor network control, management of sensor data calibration, and anomaly detection.
Air pollution is a global threat leading to large impacts on human health and ecosystems, particularly in urban areas. In Europe, air quality remains poor in many cities that experience exceedances of the regulated limits for air pollutants [1]. The urgency of limit air pollution is also stated by the sustainable development goals (SDGs) defined in the 2030 Agenda for Sustainable Development [2].
Efective action to reduce air pollution and its impact on the quality of life requires good understanding and extensive monitoring of urban air quality. In recent years, the development of Internet of Things technologies has increased and cities around the world have exploited this enabling technology to be able to control multiple aspects of citizens’ lives. IoT allows monitoring trafic congestion [ 3, 10], detecting and classifying road accidents [7], managing car parking [9], supporting decision in agriculture [4], evaluating energy consumption [12], and, also, monitoring air quality [13]. Data generated by IoT are used to improve city services and the living experience of citizens.
In this context, data coming from a group of low-cost sensors spread around a city might generate widespread hyperlocal insights into air pollution. However, a network of low-cost air quality sensors is not enough to monitor urban air quality. Since those sensors are complex and sensitive, they require specific environmental skills. Data generated by the air quality sensors need to be converted into relevant and crucial insights to allow the monitoring of air quality by politicians and to enable the achievement of the sustainability goals. In this context, environmental experts hunger for a control platform to perform sensor data calibration and anomaly detection.
The maintenance and control of a urban air quality network is relevant, and crucial to provide good information that enables the extensive monitoring of air quality. Moreover, the availability of efective visualizations to process and interpret collected data is essential.
In this paper, we present SenseBoard, an interactive tool addressed to environmental experts that brings together heterogeneous and dynamic data for real time analysis and management of air quality network. This tool has been conceived within the TRAFAIR project1 that allowed the creation of an urban network of low cost air quality sensors. The low-cost sensors employed are cheaper and less reliable than the Air Quality Monitoring (AQM) legal stations managed by the Environmental Agencies. It is possible to improve the reliability of the measurements of these devices if they are previously calibrated by placing the device near air quality stations for some weeks. Low-cost sensors provide "raw" measures, i.e. a datum in millivolts; to convert this datum into a reliable concentration of pollutant it is necessary to carry out a calibration period during which some Machine Learning algorithms are trained in order to generate, from the raw measurements, pollutant concentrations in line with those estimated by the AQM stations. SenseBoard is devoted to support environmental experts in the monitoring and control of the air quality sensor network, in the supervision of the calibration process and in the detection of anomalous values. SenseBoard acts as an enabling tool to detect anomalies, update sensor status, monitor the proper functioning of the sensors, manage the change of location of the devices and, above all, to provide feedback to perform the calibration process. The calibration results obtained using the Machine Learning algorithm are shown and compared to the raw data, and the data of the AQM station, thus, it is possible to understand if the algorithm works appropriately or if it is necessary to extend the co-location period of the device.
SenseBoard is a general and flexible dashboard that can be adapted for the monitoring of any air quality sensor network. The scalability of the dashboard allows replicability in cities of diferent size with a variable number of sensors. The dashboard is not afected by the type of employed sensors and it can be easily modified to visualize other parameters measured by the sensors. In this paper, we take advantage of the use case in the city of Modena.
The rest of the paper is organised as follows. Section 2 is devoted to the presentation of the background. Then, Section 3 introduces the dashboard and describes some views (data visualization) in the city of Modena. In the end, Section 5 provides conclusions. 2
TRAFAIR ("Understanding Trafic Flows to Improve Air Quality") [11] is a project co-financed by European Commission that brings together 10 partners from two European countries (Italy and Spain) to develop innovative and sustainable services combining air quality, weather conditions, and trafic flows data. The scope is to increase the awareness on urban air quality for the benefit of citizens and government decision-makers. The project aims to supervise the level of pollution on urban scale in 6 European cities (Modena, Florence, Pisa and Livorno in Italy, and Santiago de Compostela and Zaragoza in Spain) by producing real-time estimates of air pollution through a network of air quality devices and by developing a service for forecasting urban air quality based on weather forecasts and trafic flows [5].
The sensors employed are low-cost, cheaper and less reliable than the AQM stations managed by the Environmental Agencies. However, these devices can provide reliable measurements if they are co-located for a certain period of time close to the stations where they "learn" how to measure air quality.
A device is a box where diferent sensors are placed. Each sensor, also called cell, is devoted to the measurement of a specific pollutant. Figure 1 shows an exemplar device.
The approach used in TRAFAIR is to install the devices for a certain period close to the AQM stations. During this period (calibration period) a Machine Learning algorithm is trained on the measurments provided in millivolts by our devices (raw observations) and the AQM station measurements. Then, when environmental experts evaluate the device is "ready" (usually after 3 weeks of co-location), it can be moved to diferent location and start providing air quality measurements. When the device is "ready", thanks to the Machine Learning algorithm previously trained, calibrated data (concentrations) are generated from the raw observations. Usually, periodically every 6 months, the devices are once again co-located near the AQM stations for re-calibrating, thus maintaining a good quality of measurements.
In this scenario, it is easy to understand the importance of having a tool for managing the change of location or status of the devices. Besides, it is important to compare anytime the calibrated data with the measurements of the AQM stations (no matter in which location the sensor is), to determine when the device needs to be re-calibrated (usually when the calibrated data and AQM measurements difer a lot).
Since devices are constantly moved, it is possible that, when they are switched of and then switched on in a new location, they experienced a "warm-up" for some minutes or even hours. The warm-up is a specific period when the device tries to achieve a thermo-mechanical balance in the measuring system as well as an optimal operating temperature of the electronic components. Since the warm-up period is of variable duration, a time line evolution of the raw observations enables the user to detect when the warm-up period is over.
Figure 2 shows the raw measurements collected from one device. As it can be seen, at 9 a.m. approximately the device has been switched of. One hour later, the device has been switched on in a new location. The zoomed area of the graph shows the ifrst two measurements for each gas made in the new location.
The values drop of sharply due to the warm-up. Consequently, these values have to be discarded from the reliable observations and flagged by the environmental experts as "not reliable". This operation can be made through SenseBoard (this will be described in Section 3). Accordingly, the environmental experts need to constantly visualize the data produced by the device and monitor the behavior of each device.
The need for a monitoring tool comes from the environmental experts. For this reason, they have been directly involved in the definition of the requirements to be satisfied through the dashboard. After some discussions, 6 requirements have been outlined:
R1 providing an overview of the current position and status of each sensor, R2 recording the location or status change for a certain sensor without hand-writing the SQL query to store the modification on the database, R3 visualizing sensor observations without data aggregation to detect anomalous values and compare them each other, and with data aggregation to better understand the trend, R4 comparing observations of co-located sensors in the same place, R5 showing the concentrations produced by the calibration algorithm and comparing them with the certified values of the AQM legal stations, R6 displaying the anomalies identified by the anomaly detection algorithm to control the eficiency of the automated algorithm.
After the development of SenseBoard, during the usage, additional feedback from environmental experts has been continuously collected to improve the functionalities of the dashboard. 2.1
In Modena, an Italian city of 186,000 inhabitants and 183 2, 13 air quality devices (52 low-cost sensors) have been installed in diferent locations. There have been identified 2 locations for calibration (the red dots in Figure 3), close to the AQM stations, and 10 locations of interest (the blue dots in Figure 3), that are placed in areas of diferent kinds, such as residential, industrial, or green areas.
Two types of low-cost devices have been exploited: 12 Decentlab Air Cubes and 1 Libelium Smart Environment PRO. All the devices are equipped with 4 cells (sensors), one for each gas ( , 2, and ). Each cell measures the gas concentration through 2 channels (the auxiliary and the working channels). In addition, the Libelium device measures the level of 2.5 and 10. For each channel, the raw observations are provided in , moreover, a basic concentration based on the original factory calibration2 is provided in /3. Besides, these devices are able to measure the air temperature and humidity, and provide the battery voltage. Therefore, the total number of measurements provided by one sensor is 19 for Decentlab cubes and 21 for Libellium sensor.
The sensor data acquisition is managed by the Long Range Wide Area Network (LoRaWAN) implemented in the city of Modena. LoRaWAN [6] is a media access control (MAC) protocol widely used in smart city applications thanks to its easy installation and cost-efectiveness. It employs some gateways i.e. antennas that receive broadcast messages from the enabled devices (the air quality devices, in our use case) and forward them to the server. The message from one device can be received by more gateways at the same time, the server will deal with duplicates. The LoRaWAN network exploits low radio frequencies and provides for long-range communications (up to five kilometers in urban areas, and up to 15 kilometers or more in rural areas). The network coverage depends a lot on the geographic landscape.
Our air quality devices have been registered to the LoRaWAN network of Modena through their identifier (DevEUI) and following the Over-the-Air Activation (OTAA) process. The data rate has been set up to 125 kHz, and the spreading factor to 7, to allow devices transmitting data every 2 minutes. 2This is obtained by applying to the raw observations a formula provided by the manufacturing company with the calibration parameters that are diferent for each device.
Figure 4 shows the data acquisition process. The devices encapsulate the acquired measurements into LoRa packets and send them to the LoRaWAN server through the gateways. Every LoRa packet contains 19 (or 21) measurements (both mVs and basic concentrations for each gas and channel, including air temperature, humidity and battery voltage) and in one day each device produces 13,680 (19 * 720) measurements. 4 gateways have been installed in Modena, mainly on the roofs of the highest buildings, to cover the whole urban area of the city and ensure the coverage of the LoRaWAN network in our points of interest. Moreover, the gateways have been registered on the LoRa server. When the gateways receive a message, they send it to the LoRa server where the MQTT (Message Queue Telemetry Transport) Broker Mosquitto [8] is running. This is a publish/subscribe messaging transport protocol. Data are published as an MQTT topic. We have used the paho-mqtt Python library3 to implement the open source message broker in a Python script. The script is always running and exploits the client class to enable the connection to the MQTT broker, publish messages, subscribe to topics and receive messages. Then, messages are decoded and measurements stored into a PostgreSQL database, the TRAFAIR database (in the following sub-section, more details are provided). Also, through this script an anomaly detection algorithm is applied to the time series of the air quality measurements to detect if each measurement is anomalous or not. This algorithm employs a majority voting system of three diferent Machine Learning algorithms. The anomalous data are flagged into the TRAFAIR database. When a device is moved from one location to another, it automatically connects to the nearest gateway and restart sending messages. Since the messages received in the LoRa Server are described by the identifier of the device, the change of gateway to which the device connects is completely transparent. The LoRa server keeps storing the measurements of each device no matter how they are moving in the urban context. 2.2
Data from the air quality low-cost sensors are stored, in real time, into the TRAFAIR database. This database exploits the PostGIS extension to handle with geospatial data and the Timescale extension to make SQL scalable for time-series data.
The database contains more than 60 tables and 190 GB of data collected from the beginning of the TRAFAIR project (November 2018) till now (February 2021). Air quality measurements and device-related information are store in 11 tables and take 3 GB. These tables stores the technical characteristics of each device, its position, its status (running, calibration, ofline, broken, warmup), the raw observations, the concentrations obtained by both the original factory calibration and our calibration algorithm, and the anomalies identified by some anomaly detection algorithms applied to both raw and calibrated observations. 3https://pypi.org/project/paho-mqtt/
In each moment, every device is described by a status and is located in a point of interest (see Figure 3). Its measurements are stored continuously, as soon as they are parsed by the LoRa server. Each raw measurement can be calibrated by multiple calibration algorithms. Thus, calibrated data are identified, not only by the date of the measurement and the sensor that has provided it, but also by the algorithm that was used. In the end, several anomaly detection algorithms are applied to both raw and calibrated data. The results are stored in the TRAFAIR database in appropriate tables using boolean values to indicate if they are anomalous or not.
Only considering the measurements coming from our devices, from the installation, we have collected 3.3 million records of measurements (1.8 GB). Each record includes 19/21 measurements: air temperature, humidity, battery voltage, 8 raw measurements (2 channels per 4 gases), 8/10 concentrations of the original factory calibration (2 channels per 4 gases and one measure for 2.5 and 10). 3
SenseBoard4 is a Python web application which exploits Tornado5 as web framework. It runs on a Debian 9 machine with 32 Intel(R) Xeon(R) Silver 4108 CPU at 1.80GHz processors and 256 GB RAM. Figure 5 shows the architecture of the dashboard. Firstly, users need to login to access the dashboard. The authentication phase is performed through the Lightweight Directory Access Protocol (LDAP). The list of people allowed to access is currently limited to the environmental experts working in TRAFAIR.
After the authentication, the user is able to visualize the current status of each device and send other requests through the navigation bar at the top: he/she can ask for observations (raw measurements), anomalies, calibration (calibrated measurements), and AQM station (measurements from the AQM stations). For each request, the dashboard queries the TRAFAIR database to obtain the appropriate data and creates plots of the time series data by using the matplotlib Python library6. More complex plots are periodically generated by ad-hoc Python scripts7 which query the database and save plots in the file system as html files through the save_html function of the mpld3 library8. This library is also exploited for the InteractiveLegendPlugin9, which allows to connect the plot to an interactive legend. This legend is very useful in our plots since it allows customizing the visualization by adding or removing some lines in the plot. The user can click on the rectangle generated in the legend near the labels. If the rectangle is colored, the corresponding data is shown on the plot; if the rectangle is white, these data are removed from the plot. The html files are, then, included in the html page of the corresponding request. What we mean with “more complex plots” are the ones which require an elaboration of the data stored in the database and manage a big amount of data (i.e. the raw observations of each sensor related to one month). This choice was made to save time in the visualization of the plots. Indeed, this solution decreases the server response time of 35 seconds for the most time-consuming request. 4https://trafair-srv.ing.unimo.it/aqsensors 5https://www.tornadoweb.org/ 6https://matplotlib.org/ 7The scripts run every 2 minutes and generate the plots in 4-27 seconds. 8https://mpld3.github.io/ 9https://mpld3.github.io/examples/interactive_legend.html
Some examples of visualizations (views) are described in Section 3.2. The views are static to allow users to navigate and explore all the plots in the view without any interference. However, the user can click on the “update” button to see the updated views. 3.1
The scope of SenseBoard is the monitoring and control of the air quality sensor network and the supervise of the calibration and anomaly detection processes.
Regarding the monitoring of the network, SenseBoard allows to identify and update the status of the sensors, change their location when they are moved in diferent position and perform any maintenance, if necessary.
Considering the supervise of the calibration process, SenseBoard lets to compare raw measurements of co-located sensors, raw and calibrated measurements of the sensors, and, in particular, the calibrated observations generated during the calibration period with the legal observations from the AQM stations. This last operation is the crucial one in the calibration process because it allows experts to understand if the training period of the Machine Learning algorithm is suficient, i.e. if the concentrations, elaborated by the Machine Learning algorithm, are in line with those of the AQM station.
Other tasks are the detection of issues in the network communication, the discovery of disruptions or failures in the sensor’s behaviour, the identification of anomalous gas concentrations, the comparison of co-located sensors measurements, the correlation study of the pollution level in the area of sensor installation.
The primary users of our visual analytic dashboard are the environmental experts in charge of installation, maintenance and calibration of air quality sensors. 3.2
In SenseBoard, we have developed 6 views to allow environmental experts to have complete control of the air quality sensor network status and the operations that are performed on the sensor data. Each view is described in detail in the following sub-sections.
3.2.1
The first view, i.e. the homepage of the dashboard after the login, aims at satisfying requirements R1 and R2. Here, users are able to visualize a table with a summary of the main information related to the air quality devices. For each device, in the table, there are listed its identifier, the name of the location where the device is currently installed, the timestamp of the installation, the name of the person in charge of the installation, the sensor status and any possible notes.
Besides, as shown in Figure 6, for each device, two buttons are available: the “edit” button allows to update the location and/or the status of the corresponding device. After clicking on the button, the user has to specify the timestamp representing the instant of the update (of the location or status), the location (one of the points of interest in Figure 3), the status, and, optionally, its name and notes. The “save” button stores the information in the TRAFAIR database. The status update is exploited in diferent situations. For example, if the device is moved from a point of interest to the AQM station, its status changes from “running” to “calibration”. In addition, if the environmental experts notices an abnormal behavior of the device, he/she can modify the status in “broken” indicating as timestamp the date of the first abnormal measurement. Then, he/she needs to add the “running” status from the first regular measurement.
In addition to the “edit” button, the “check data” button connects to the “sensor observations” view.
Besides, in this view, the user can interact with a map (Figure 7), where the current position of each device is visualized with an icon of diferent colors according to the status of the device. If more devices are in the same location, a bigger icon is displayed on the map with the number of devices in that position. By clicking on this icon, an icon for each device is visualized. If you click on the icon of a device, you can see its name, its status, the name of the location, and the link to the “sensor observations” view of that specific sensor. Folium 10 is the Python library used to create the map.
The “sensor observations” view satisfies requirement R3 and includes 6 plots with the observations of one device. At the top of the page, the name of the device, its status and location, and the timestamp of the last observation with the level of battery voltage are reported. This allows the managers of the sensor network to check immediately if the sensor is not sending data or if the batteries need to be changed.
The 6 plots show the measurements of:
(
Only for the Libelium device another plot is provided, which shows the level of 2.5 and 10.
Each plot can visualize data for diferent time interval (last 24 hours, week, or month) and data aggregation (2 minutes - which means no aggregation, 5 minutes, and 15 minutes), generating 9 diferent combinations for each plot. The visualization changes according to the option selected by the user.
There are altogether 711 plots (13 devices * 6 plots * 3 time interval * 3 data aggregation + 1 PM plot * 3 time interval * 3 data aggregation). Since the creation of a plot took on average 12 seconds, we decided to generate these plots asynchronously through one Python scripts. This means that the plots are generated independently by the user choice, and when the user selects an option (for time interval and data aggregation), he/she enables the visualization of a ready-made plot. This time-saving design choice is also motivated by the user behavior. After three months from the first release of SenseBoard, we noticed that it was very likely that the user is interested in visualizing several plots, exploring diferent gases with diferent aggregations or for a diferent time interval. If the plots are created synchronously with the user’s choice, jumping from one plot to another requires waiting for the generation of the relative plot each time. In agreement with environmental experts, we have therefore decided to switch to an asynchronous generation of the plots that reload the 711 plots every 2 minutes.
Figures 8 and 9 are two examples of visualization available in the “sensor observations” view. In Figure 8 the measurements of the 4 gases for the auxiliary and working channels related to one device are plotted in a lines chart. An anomalous behavior of the device has been highlighted in red: the values of the measurements in that time interval are very diferent from the previous ones. SenseBoard allows the detection of the wrong data. After the maintenance work by the environmental experts, the device reaches the stability and the measurements proceed with the expected values. Through the “edit” button of the “sensor status and position” view, the time period related to the red area is flagged with the “broken” status. Figure 9 highlights an abnormal behavior of another device. In this case, the anomalous measurements are due to a drastic reduction in the battery level. At 2 a.m., approximately, the battery died and the device stopped sending data. After changing the battery, at 10 a.m., the device restarts providing reliable measurements.
In the “gas observations” view, a plot for each gas and channel is generated, as shown in Figure 10 for NO. This view meets requirements R3 and R4. The user can choose to visualize the data of the last 24 hours, week or month. The visualization could seem confused, however the user is able to hide one or more lines in the plot thanks to the interactive legend, and zoom in a specific area of the plot. In the web page, the plots related to the two channels of the same gas are placed next to each other (as in Figure 10) to facilitate the comparison of these measurements and detect the correlation between the two channels. Thanks to this view, the behavior of the cells can be regularly checked and the maintenance planned.
The accuracy of the raw measurements can be influenced by multiple factors, i.e. the low level of battery voltage, the weather conditions, the air humidity. Distinguishing not correct data allows for providing more reliable data and could improve the results of the calibration task.
We have implemented a majority voting system which
combines 3 classifiers: (
The research for anomalous data is performed on both channels of each pollutant and device independently, since each device is individual and performs diferently from the other devices even if they are in the same location.
The “sensor anomalies” view consists of one plot for each sensor with the raw observations and the anomalies identified by the majority voting system (requirement R6). Also in this case, the user can choose for the observations of the last 24 hours, week, or month.
Figure 11 is an example of anomalies visualization for sensor 4006. Anomalies are identified by a point. As can be seen in the ifgure, in most cases anomalies are detected in the upper peaks of the time series.
The results of the calibration process consists of the concentrations of the 4 measured gases. Starting from 2 values for each gas (one value for each of the two channels) in millivolts, the calibration provides one value in /3. Currently, we are using Random Forest to calibrate our data. However, this algorithm can be improved over the time since more and more data are collected and they are used to re-train the calibration algorithm.
The “calibrated observation” view shows the result of the last calibration algorithm, that is the most recent and accurate algorithm available for the visualized data. This view meets requirement R5. The calibrated observations are organized in 4 plots, one for each gas, and the user can distinguish the measurements of each device through the integration of the interactive legend.
The calibrated values can be directly compared with the measurements of the AQM stations since they are in the same unit of measure. To validate our calibrated data we have defined one local warning threshold for each gas based on the measurements of the AQM stations. Each threshold has been calculated as 1.25 ∗ , where is the maximum value measured by the AQM stations for the specific gas in the year preceding the date of the observation to be compared. If the concentration of the gas is higher than the corresponding threshold, it is automatically flagged as “anomalous” in the TRAFAIR database by a Python process running in real time. The warning threshold is valid only in the area of Modena since it is provided by the certified values of the AQM stations of Modena and it changes every year. This threshold allows to exclude very high values that are most likely due to malfunction of the sensor. It is not to be confused with the alert thresholds of the European Commission11 or the reference levels of the European Environment Agency12, which defines the values to assess the level of pollution in the area. 11https://ec.europa.eu/environment/legal/law/5/e_learning/module_2_18.htm 12https://www.eea.europa.eu/themes/air/air-quality/resources/ air-quality-map-thresholds
In the plots of the “calibrated observations” view, a line in correspondence of the threshold value is plotted only if at least one measurement exceeds the threshold. The plots in Figure 12 show the measurements of made by 5 diferent devices installed in the same location named “Parco Ferrari” (this is also the location of an AQM station). We have selected only the devices in the same location through the interactive legend. The concentrations measured by the devices are very similar, as we expected. In the “last month” plot the blue line indicates the above mentioned local warning threshold and only one value is higher than this threshold.
The sixth view of SenseBoard is devoted to the visualization of AQM station observations. They are hourly certified data related to the concentrations of , 2, , and 3 measured by the two AQM stations installed in Modena (red points in Figure 3). 4
SenseBoard has been regularly used by 4 environmental experts
from January 2020 till now and it is still active. It has allowed:
(
The efectiveness of SenseBoard was widely appreciated by environmental engineers who would not have had the opportunity to compare sensor measurements and calibrations and to carry out such sudden checks and maintenance. 5
SenseBoard is a data visualization and management platform for air quality sensors. It is a flexible tool that can be integrated into specific IoT environments. In this paper, architecture, users, scope, and exemplar views have been presented. Moreover, details on the sensor data acquisition and storage processes have been given.
SenseBoard is a multi-purpose tool: to manage and maintain the air quality sensor network control and to supervise the calibration process and the identification of anomalies. The management of the network requires the deploy and frequent re-allocation of devices close to the AQM stations or in specific points of interests. Data coming in real-time from the sensors need to be constantly monitored by experts in order to control the normal functioning of sensors.
The dashboard integrates a big amount of heterogeneous data, both geo-spatial and time series data. The position of each sensor is visualized in an interactive map. The measurements of the sensors have been plotted in diferent line charts with mainly two types of visualization: the same air pollutant measured by all the sensors in the same plot, and all the air pollutants measured by the same sensor in the same plot. Besides, anomalous data are highlighted in other plots. The visualization of such an amount of plots is speed up by the use of Python scripts which generate the plots asynchronously and independently by SenseBoard.
The dashboard is accessible anywhere and anytime to allow a constant monitoring of the network. Besides, it can be generalized to visualize other kinds of geo-spatial and time series data. Indeed, the dashboard is not afected by the type of sensors employed in the network (also in our case we integrate two diferent types of sensors) and can be easily adapted to monitor other pollutants beyond the ones described in our use case. The flexibility and scalability of SenseBoard allow to monitor networks of a variable number of sensors in cities of diferent sizes. In addition, in our use case we manage a dynamic sensor network since the sensors are moved frequently. However, this is an additional issue, and the dashboard works also with static sensor networks. SenseBoard can be adapted to query a diferent data platform which can be a PostgreSQL database or a data model of diferent type. Queries and plots can be easily modified to visualize data in another way or to show additional data that are not included in our use case.
SenseBoard has been developed according to the technical requirements provided by the environmental experts. Thus, it is not comparable with the dashboards developed for citizens and public administrations. Indeed, the scope of these dashboards is not the monitoring of the sensor network, but the provision of pollution levels to raise awareness among people about the situation in their city. As future work, we will compare SenseBoard with the technical tools provided by the air quality sensor suppliers. In addition, we will integrate an additional view to allow the creation of custom plots, starting from the selection of one or more sensors, pollutants, and AQM stations, and the time interval. This will allow for further data comparison.
Research reported in this paper was partially supported by the TRAFAIR project 2017-EU-IA-0167, co-financed by the Connecting Europe Facility of the European Union. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the oficial policies, either expressed or implied, of EU Commission. The authors would like to thank the City of Modena that contributes to the deployment of the LoRa network, and the LARMA research group for providing requirements and feedback on SenseBoard. Moreover, a special thank goes to ARPAE that shared real-time air quality observations used for the calibration of the low-cost air quality