## 4 Method
### Test Campaign Methodology for Data Quality Evaluation  
The preliminary analyses allow for an efficient planning and installation of sensors, selecting critical areas to be monitored, and optimizing spatial distribution, orientations, and fields-of-view of sensors. Nonetheless, after the first phases of data collection, some errors and faults, described in the following paragraph, may occur, and the system needs to be calibrated to ensure data quality. An incorrect calibration would lead to incorrect data collection and to an erroneous modelling of the occupancy patterns of the spaces, with repercussions on the whole BMS. The iterative process to perform the \"test campaigns\" (Figure 1) is presented in detail in Figure 3 and described in the following paragraphs. Once the system is installed as planned with the support of preliminary analyses, data are collected for a representative period of time that should be identified for each case study. Then collected data are downloaded in CSV format from the online platform DB. Collected data are analyzed in order to identify the possible data errors and related system faults, as described in Table 2. If no faults that could compromise the following analyses are detected, the system is properly functioning and calibrated. Otherwise, test campaigns are performed to verify the errors detected in the collected data. The real time test campaign involves two operators. One operator (operator A) monitors through the online platform the position and movements of the other operator (operator B) inside the building. The two operators are constantly connected via earphones to communicate and coordinate with each other. In particular, operator A guides operator B towards the areas where errors were previously detected in the collected data. Moving inside the building and entering/exiting the rooms, operator B tests the detection of user movements and the room occupancy count (O) by the system. At the same time, operator A monitors the response of the system by checking the real-time displayed user movements and instantaneous values of O of the rooms through the online platform. Consequently, the operators search for detection errors and system faults in order to identify the causes, as described in Table 2. System faults can be classified as missing data, outliers, stuck values, and noise. Each fault can be identified in collected data or during test campaigns according to specific values of O. In addition, noise can be detected only during real-time test campaigns, by comparing the movements of operator B and his anonymous digital counterpart displayed on the online platform. Some examples of the causes of the errors and faults are camera malfunctioning in the case of missing data and extreme lighting contrast in the monitored area, which impedes a correct detection and causes noisy data. Figure 3: Data collection, test campaign, and adjustments application iterative process. Once the causes of data errors and faults are identified, some adjustments are proposed and applied to the system. Then the system must be verified again, in an iterative process, until no errors are detected and consequently the required data quality level is reached. This iterative process is also useful to check overtime the effectiveness of improvement solutions or to check the system after geometry changes in the building, e.g., in the case of refurbishments. Regarding the possible adjustments to solve the errors and the related causes, some general rules were identified to define a hierarchy of possible solutions. Generally, the most preferable solution would be not acting on the hardware of the system: in the case of a recently added physical obstacle that prevents the camera-based sensor from detecting, the most preferable solution would be moving the object before moving the sensor. In addition, before acting on the hardware part of the system (e.g., adding or replacing cameras), the camera settings could be checked, and the software system would be improved.