## 2 System Architecture
### Data Acquisition Process  
A key aspect to consider when developing an IEQ monitoring system as that shown in Figure 1, is the data acquisition process. Data collected from each monitoring device typically undergo processing and aggregation operations to provide representative and immediate feedback on the actual IEQ to the end-user. The timing and locations of these computations, whether at the multi-sensor or cloud platform level, should be addressed during the initial design stages. Trade-offs often arise, such as limited memory and computational capability at the multi-sensor level, the data rate, i.e., the amount of transferred data per unit of time, between multi-sensors and the server, and data compression at the database side. A possible approach involves the periodic acquisition of the sensors deployed in the monitoring device, and the sending of all raw data to the cloud for processing operations. Under such a scenario, and by assuming that each multi-sensors acquires \(M_{\text{sens}}\) different physical quantities, the incoming data rate for cloud server, i.e., the number of incoming data from all multi-sensors per unit of time, can be evaluated as:  
\[DR_{\text{periodic}}=N_{\text{ms}}\sum_{i=0}^{M_{\text{sens}}}f_{\text{ sampl}}(i), \tag{1}\]  
where \(f_{\text{sampl}}(i)\) is the \(i\)-th sampling frequency, i.e., the inverse of the sampling period, associated with the \(i\)-th acquired sensor. Although such an acquisition scheme allows the cloud server to have at its disposal the entire set of data related to the physical parameters, it may result in a non-optimal trade-off between the require data rate, which directly affects also the required bandwidth, the database dimension, and the power dissipation of each multi-sensor, and the real-time capability of IEQ monitoring. The acquisition process exploited in the developed system is shown in Figure 2. At the IoT level, each physical quantity is associated with a given sampling and report time, which are denoted as \(t_{\text{sampl}}\) and \(t_{\text{report}}\) in Figure 2. Each multi-sensor is therefore responsible for acquiring data from its \(M_{\text{sens}}\) sensors according to the specified \(t_{\text{sampl}}\), and to temporarily store those value in its memory. Then, as \(t_{\text{report}}\) for the i-th sensor elapsed, each multi-sensor  
Figure 1: Architecture of the PROMET&O system. The multi-sensor devices measure physical quantities related to the four IEQ domains, performing also preliminary data processing. Data are sent to the MQTT broker through WiFi and 3G/4G wireless networks, and are stored into a database through an MQTT client. Data aggregation and enrichment is performed periodically by a scheduler. End users can access a web application, which reports the data in the database through a dedicated dashboard. aggregates the raw data in a set of \(K_{\text{param}}\) statistical parameters, and sends them to the cloud server. Under such a scenario, the required data rate for the cloud server can be evaluated as:  
\[DR_{\text{report}}=N_{\text{ms}}\sum_{i=0}^{M_{\text{sens}}}K_{\text{param}}f_{ \text{report}}(i), \tag{2}\]  
where \(f_{\text{report}}\) is the inverse of the report time. Indeed, by adopting the acquisition scheme shown in Figure 2, the incoming data rate of the server can be reduced without losing information. In the implementation of the system, \(K_{\text{param}}=8\), i.e., the average, minimum, maximum, standard deviation, mode, median, and 10 th and 90 th percentile. In such a way, rapid variations of physical parameters, e.g., the opening/closing of doors and/or windows, can be detected from the maximum, minimum, and standard deviation parameters. Conversely, the remaining statistical parameters are more suited to be compared with the survey responses of the occupants. It is worth noting that existing works, such as [23; 27], exploit \(K=1\), as they only sent the average values to the server.