The preprocessing of raw sensor data is an essential step in building reliable and effective PdM models. In this study, a comprehensive real-world dataset was collected from an operational AHU at the I4 Helse building over 6 months.

The dataset consisted of 51,713 rows of time-series data, captured at 5-min intervals, and covered 21 distinct features. These features included critical operational variables such as outside air temperature, supply air temperature, mixed air temperature, exhaust air temperature, actuator signals, valve control levels, fan status, and general system states. However, like most sensor-based building datasets, the raw format was incomplete and noisy. Without proper preprocessing, these issues can severely impair model training, introduce bias, and distort both APAR rule evaluations and ML predictions. Therefore, a structured and multi-step data preparation approach was applied and illustrated in Figure 4.

The initial phase of data preprocessing involved a thorough investigation of missing values, which are common in long-term building monitoring systems due to sensor faults, communication errors, or scheduled maintenance. The analysis revealed that 113 rows in the dataset contained one or more missing entries. Crucially, no single feature exhibited more than 112 missing values, as presented in Table 4, indicating that the data loss was sparse and distributed. These missing entries were localized in three-time windows: at midnight on 1 March 2021; between 08:35 and 14:05 on 22 May 2021; and between 07:20 and 11:00 on 22 July 2021. These gaps may be associated with either system resets or temporary sensor dropouts. Because the missing data represented only 0.22% of the total dataset, and because machine learning algorithms such as Random Forest and Neural Networks typically require complete input vectors (Trojanova et al., 2009; Schein et al., 2006), the most pragmatic solution was to remove these 113 rows. This brought the final dataset to 51,600 complete entries.

To further address the implications of this decision, an additional evaluation was conducted to ensure that the removal of the 113 incomplete rows did not adversely affect the temporal structure of the dataset, the APAR fault-detection process, or the performance of the machine learning models used in this study. The missing entries occurred in three isolated windows, each short in duration and occurring during otherwise steady operational periods. Such patterns are consistent with Missing Completely At Random (MCAR), where the probability of missingness is unrelated to the sensor values themselves (Maya and Chafic, 2022). Under MCAR conditions and with a missing rate as low as 0.22%, listwise deletion is widely accepted as the preferred method because it avoids introducing artificial trends or smoothing effects that can arise from statistical interpolation (Mallapragada et al., 2020).

Moreover, imputing HVAC sensor values can distort transient thermodynamic behaviour, particularly for variables such as supply air temperature, mixed air temperature, and return air temperature, all of which play central roles in APAR rule evaluation. APAR diagnostics rely on strict thermodynamic relationships, such as the magnitude and direction of temperature differences, and imputing synthetic values within missing intervals may unintentionally mask true anomalies or create non-physical consistency among sensor readings (Duan et al., 2021). For these reasons, deletion was considered the safer choice for preserving the physical validity of the time-series dataset prior to APAR analysis.

With respect to ML, the remaining dataset of 51,600 complete rows provides a sufficiently large training corpus for both RF and ANN models. Prior studies have shown that these models are robust to minor, non-systematic data reductions when the dataset remains large and diverse (Macieira et al., 2021). Furthermore, HVAC fault detection literature consistently recommends prioritizing physical fidelity over artificial completeness, particularly when the impact of deletion is negligible, as in this case (Lestinen et al., 2018). Thus, based on statistical justification, domain considerations, and alignment with established preprocessing practices, the removal of the 113 incomplete rows is both methodologically sound and appropriate for the objectives of this study.

Following the removal of incomplete data, a duplicate row check was conducted. Duplicate records can arise during logging restarts or file mergers, and if left unaddressed, they can bias the frequency distribution of operational modes or inflate feature importance in models. A full dataset scan using hash-based row comparison confirmed that there were no duplicate entries, ensuring consistency in the time-series progression. The cleaned dataset was then analyzed for the presence of outliers, particularly in the temperature features. Significant spikes were detected in variables such as supply air temperature and mixed air temperature, as shown in Figure 5. These outliers could result from momentary sensor calibration issues, rapid mode transitions, or even control failures (Schein et al., 2006). However, given that the purpose of this study includes fault detection, these extreme values were preserved rather than removed. They were marked for potential influence on APAR rule triggering and ML training, as they could represent authentic system anomalies.

Once the data was cleaned, a multicollinearity analysis was performed to identify and mitigate redundancy among highly correlated features. Multicollinearity can negatively affect both interpretability and model stability, especially in models relying on feature importance rankings or linear separability. To evaluate this, pairwise Pearson correlation coefficients were computed for all combinations of continuous features.

The Pearson correlation coefficient r x y is defined by Equation 1. r x y = ∑ i = 1 n x ¯ i − x ¯ y ¯ i − y ¯ ∑ i = 1 n x ¯ i − x ¯ 2   ∑ i = 1 n y ¯ i − y ¯ 2 (1)

Where xi and yi are defined as two features, i.e.,   x ¯ , and y ¯ represent the mean values of these features. The value of Pearson’s correlation coefficient ( r x y ) varies from −1 to 1, where values closer to ±1 indicate stronger correlation. Features with ∣r∣ > 0.9 were flagged for review. Although strong correlations were observed between temperature variables, such as between supply and mixed air temperatures, these features were retained due to their functional significance in HVAC logic and their specific use in APAR rules. Redundancy in this case was tolerated to preserve interpretability and allow physical behavior to remain visible in the dataset. Final selection of features for training was left to the feature importance analysis conducted later during machine learning model development.

The final preprocessing step involved standardization of all continuous variables using Z-score normalization. This is a necessary transformation to bring all feature values to a common scale, especially when using gradient-based models such as neural networks. Standardization also accelerates convergence and prevents numerical instability during optimization. The Z-score transformation is defined as shown in Equation 2. X ′ = X − μ σ (2)

Where X ′ the normalized feature value X is the original feature value, μ is the feature mean, and σ is the standard deviation. After transformation, each feature has zero meaning and unit variance. This normalization was applied uniformly to all numeric variables, including temperatures, control signals, and valve openings.

The objective is to identify and categorize faults in the AHU system using both expert-defined logic and data-driven modelling. While APAR provides interpretable diagnostics without the need for historical labels, machine learning models enhance scalability and fault generalization under complex, nonlinear conditions.

The APAR engine was implemented in Python and applied to the cleaned and standardized dataset described in Section 3.2.1. To enable effective rule evaluation, it was essential to first determine the system’s operating modes based on control signal logic and component behavior. These modes (also referred to as operating states in this study) define the conditions under which each APAR rule should be active. In line with common terminology in AHU diagnostics, the terms free cooling and zero energy mode are also used interchangeably to describe the condition where outdoor air is leveraged for cooling without engaging mechanical cooling. Due to the absence of direct damper position data, modes that depend on damper signals or require high outdoor air fractions were evaluated carefully. An outdoor air fraction (OAF) metric was derived from return, mixed, and outdoor air temperatures and used as a proxy to assess economizer behavior and support mode classification. In line with established practices in AHU diagnostics (Schein and Schein, 2006; Katipamula and Brambley, 2005a; Schein et al., 2006; Katipamula and Brambley, 2005b). The OAF was estimated using the following mixing equation, as presented in Equation 3. O A F = T m a − T r a T o a − T r a (3)

Where, T m a , T r a , and T o a denote mixed, return, and outdoor air temperatures, respectively.

Mechanical cooling conditions were instead attributed solely to Mode 4 (mechanical cooling with minimum outdoor air), and rules were selected accordingly. An unoccupied mode (Off Mode) was inferred from inactivity across all control signals. The custom mode name, detection logic employed for each mode, the mapped APAR operating mode, and the list of rules that were implemented are presented in Table 5. For example, Heating Mode was triggered when the supply and exhaust fans were active, the heating valve was open, and the cooling valve was closed.

While the full APAR framework includes 28 rules, a total of 18 APAR rules were implemented based on the available sensor inputs, including supply air temperature (SAT), return air temperature (RAT), mixed air temperature (MAT), and exhaust air temperature (EAT), along with fan statuses and actuator signals. Ten rules were excluded due to the unavailability of key inputs such as damper position and changeover temperature. The full list of omitted rules and the rationale for their exclusion are detailed in Table 6.

To visualize the flow from raw sensor input to rule activation and fault output, a diagnostic architecture diagram is presented in Figure 6. This illustrates how operational modes are detected and used to conditionally apply rule checks across multiple system components.

To improve methodological transparency and reproducibility, additional preprocessing and modeling details are summarized in this section. All logical and categorical variables were label-encoded, and all continuous variables were standardized using Z-score normalization to ensure consistent scaling across temperature and control-signal features, in line with established preprocessing practices for HVAC machine learning workflows. The dataset was partitioned using a stratified split into 70% training, 15% validation, and 15% testing subsets to preserve class distribution and enable reliable early stopping during model tuning. Hyperparameters were explicitly defined for both models: the Random Forest classifier employed 100 estimators, Gini impurity, bootstrap sampling, and class weighting, while the ANN consisted of three hidden layers (128-64-32 neurons), ReLU activations, dropout rates of 0.30, 0.20, and 0.20, the Adam optimizer, a batch size of 32, and 50 training epochs. These configurations align with best-practice guidance in recent HVAC analytics literature, emphasizing transparent reporting of preprocessing, normalization, and model hyperparameters to ensure robustness and reproducibility (Ulpiani et al., 2021; Lestinen et al., 2018).

Model development was performed in Google Colab using Python 3.1. Libraries used included Pandas and NumPy for data handling, Scikit-learn for ML pipeline development, Matplotlib and Plotly for visualization, and Imbalanced-learn for data augmentation. While additional algorithms such as XGBoost and LightGBM were explored, RF and ANN were chosen as primary models due to their balance between performance, interpretability, and robustness.

The dataset used for model training consisted of the preprocessed and standardized data described in Section 3.2.1. Logical variables were label-encoded, and continuous variables were scaled using Z-score normalization. To address the imbalance between the majority class (“No Fault”) and minority fault types, Synthetic Minority Oversampling Technique (SMOTE) was applied to the training subset. The data was then partitioned into 70% training, 15% validation, and 15% testing sets. Feature selection was guided using ANOVA F-test scores and RF feature importance rankings.

The RF model was trained using 100 trees, Gini impurity as the split criterion, bootstrap sampling, and a fixed random seed (42) to ensure reproducibility. Class weighting was enabled to ensure sensitivity to rare fault classes. The full architecture and logic of the model are depicted in Figure 7. Evaluation metrics included accuracy, precision, recall, F1-score per class, and ROC-AUC analysis. The model demonstrated strong performance in detecting both frequent and rare fault types under imbalanced conditions.

The ANN was constructed as a multi-layer feedforward model. The input layer matched the number of selected features. Three hidden layers, each with 128, 64, and 32 neurons, respectively, utilized ReLU activation functions, while the output layer employed SoftMax to produce class probabilities. Dropout regularization was applied with rates of 30%, 20%, and 20% across the layers to prevent overfitting. The network was trained using the Adam optimizer and the sparse categorical cross-entropy loss function, as defined in Equation 4. L = ∑ i = 0 N y i   log ⁡ y i ^ (4)

Where L is the loss, y i is the true class label, and y i ^ ) is the predicted probability for the correct class. Training was run for 50 epochs with a batch size of 32, and early stopping was used to halt training once validation loss plateaued. The model’s structure and training logic are shown in Figure 8.

Both ML models were evaluated using confusion matrices, precision-recall tables, and ROC curves for each fault class. While the RF model offered high interpretability and rapid inference, the ANN demonstrated higher fault detection accuracy for complex cases involving subtle multi-variable interactions.

The trained ML models RF and ANN were evaluated through a rigorous and multi-dimensional performance assessment strategy to verify their reliability and diagnostic accuracy. Since these models were built to detect a wide range of fault classes based on APAR-labeled training data, including several rare but operationally critical conditions, the evaluation focused not only on overall accuracy but also on the models’ sensitivity and specificity across individual fault categories.

A fundamental diagnostic tool used in this assessment was the confusion matrix, which provides a compact summary of model predictions versus actual class labels. For each model, a confusion matrix was computed for both the training and testing sets, with entries reflecting true positives, false positives, true negatives, and false negatives. The accuracy metric was computed as the ratio of correctly predicted samples to total predictions, while recall, or true positive rate (TPR), was calculated as the ratio of true positives to the total actual positives in each class. These matrices were visualized as heatmaps, where high diagonal values indicate strong classification performance and off-diagonal values reveal confusion between specific fault types. Such visual diagnostics allowed identification of patterns such as systematic confusion between heating and cooling faults or difficulty distinguishing low-frequency classes from the dominant “No Fault” category.

In addition to confusion matrices, detailed classification reports were generated for each model, capturing precision, recall, and F1-score for all fault categories. Precision, defined as the proportion of true positives among all predicted positives for a class, reflects how many of the faults flagged by the model were correct. Recall quantifies the model’s ability to detect all instances of a given fault type, and the F1-score, as the harmonic mean of precision and recall, balances the trade-off between false alarms and missed detections. These metrics were calculated on the unseen test dataset and compiled into comparative tables to highlight model strengths. The RF model typically achieved higher precision, particularly in the dominant operational mode where no faults were present, whereas the ANN model displayed superior recall for minority classes, especially those with low representation in the training data.

To further analyze the models’ discriminative power across varying thresholds, ROC curves were plotted for each fault class using a one-vs-all approach. These curves chart the relationship between the TPR and the False Positive Rate (FPR) across all decision boundaries, providing a holistic view of model sensitivity. The Area Under the Curve (AUC) was computed for each ROC curve, serving as a threshold-independent performance metric. AUC values closer to 1.0 indicate excellent model performance, whereas values near 0.5 suggest no better than random classification. These curves were overlaid for the two models, solid lines for the RF and dashed lines for the ANN, to allow direct visual comparison of performance consistency across all classes, particularly for rare and high-risk faults.

Despite strong baseline performance, initial training results revealed a noticeable bias in both models toward the majority class. This imbalance compromised their ability to detect less frequent but operationally significant faults. To address this, a series of model optimization techniques were introduced to enhance the sensitivity, robustness, and generalization capabilities of the classifiers.

The first strategy involved refining the feature set to include only the most informative variables, as determined by statistical and model-based importance rankings. Specifically, features such as Heater Valve Signal, Outside Temperature, Mixed and Supply Air Temperatures, and AHU operational status consistently ranked highest and were retained to improve focus and reduce noise. This dimensionality reduction helped both models generalize better, particularly under oversampling conditions.

Second, the conventional 80-20 train-test split was replaced by a stratified three-part division: 70% for training, 15% for validation, and 15% for testing. The validation set enabled continuous hyperparameter tuning without contaminating the test set, providing a buffer against overfitting. This revision allowed early stopping and dropout monitoring to be tied to actual generalization performance rather than internal variance.

To mitigate the imbalance in fault class frequency, the SMOTE was applied to the training data. SMOTE works by synthetically generating new samples of rare classes by interpolating between existing instances. This effectively enriched the training data with realistic but previously unseen examples of rare faults, enhancing the models' exposure to operational edge cases and improving their ability to detect failures that occur infrequently but carry high operational risk.

Complementary to SMOTE, class weighting was integrated into the training procedure to prioritize rare classes further, with the weights calculated as shown in Equation 5. w i = N k   x   N i (5)

Where wi is the weight for class i, N is the total number of samples, k is the number of classes, and N i is the number of instances belonging to class i. This strategy penalized the misclassification of rare faults more heavily than common operational states, encouraging the model to allocate greater learning capacity to underrepresented events.

For the ANN model specifically, regularization and training control were essential. Dropout layers with rates of 30%, 20%, and 20% were introduced after each hidden layer to prevent co-adaptation of neurons and reduce overfitting. In addition, the training process was monitored using validation loss, and early stopping was employed to halt training once performance on the validation set no longer improved over a defined number of epochs. These methods helped avoid overtraining and ensured model robustness even when trained on augmented and imbalanced data.

To complement the classification models in Section 3.2.3, a separate feedforward ANN regression model was developed to forecast short term AHU fault incidence. The aim was to estimate how the total number of APAR detected faults evolves across the 6 months monitoring period, providing a time profile of expected maintenance needs that corresponds to the sequence shown in Figure 20. The forecasting problem was formulated at daily resolution, using the cleaned 5 minutes dataset described in Sections 3.1 and 3.2.1 as a starting point.

The original 5-min time series was first aggregated to calendar days. For each day, the number of time steps where the variable “Fault Detected” differed from “no fault” was counted. This daily count, which combines all APAR rule activations into a single measure, defined the scalar regression target y t that is referred to as daily fault incidence. In parallel, daily predictors x t were constructed as summaries of the same operational variables used in the classification task. For each day, the mean values of all continuous sensor and control variables were computed, including Outside Temperature, Exhaust Air Temp (Actual), Return Air Temp (Actual), Mixed Air Temp (Actual), Supply Air Temp (Actual), Exhaust Valve Signal, Heater Pump Signal, Outdoor Air Filter (Actual), Heater Valve Signal, Supply Air Temp (Min), AHU Status (Actual), Supply Air Temp (Max), Chiller Pump Signal, Outdoor Air Valve Signal, Chiller Signal, Fresh Air Fan (Actual), Exhaust Air Fan Signal, Exhaust Air Filter (Actual), Chiller Valve Signal, and Heat Recovery Bypass Signal. The categorical “State” variable was encoded as daily operating mode fractions by calculating the proportion of 5-min intervals spent in each mode (StateOff, StateHeating, StateZeroEnergy, StateCooling, and Unclassified), so that these fractions sum to one for each day. To capture temporal dependence, two simple autoregressive features were added: the fault incidence on the previous day y t − 1 and a 7 days rolling mean of fault incidence over the preceding week. Since these lagged features require at least 7 days of history, the first 7 days of the monitoring period were discarded, which resulted in samples with paired feature vectors x t and targets y t . All continuous predictors were standardized using Z score normalization based on the training subset, and the same scaling parameters were applied to the validation and test subsets.

The ANN regression model reused the general feedforward architecture introduced for the classifier, with modifications to the output layer and loss function to accommodate continuous targets. The network consisted of an input layer matching the dimensionality of the daily feature vector, followed by three fully connected hidden layers with 128, 64, and 32 neurons, respectively, each using rectified linear unit activation. Dropout regularization with rates of 0.30, 0.20, and 0.20 was applied after the first, second, and third hidden layer in order to reduce overfitting. The output layer was a single linear neuron that produced the predicted daily fault incidence y ^ t . The model was implemented in Keras with the Adam optimizer and a mean squared error loss function. Training used mini batches of size 32 for a maximum of 50 epochs, with early stopping based on the validation loss so that training was terminated when generalization performance no longer improved.

To preserve the temporal structure of the series, the samples were split chronologically into 70 percent for training, 15 percent for validation, and 15 percent for testing. The training subset was used to fit the network weights, the validation subset was used for early stopping and selection of hyperparameters such as learning rate and dropout configuration, and the final model was evaluated on the held-out test subset. Forecast performance was examined using standard regression metrics, including root mean squared error and mean absolute error between observed and predicted daily fault counts on the test period, together with the Pearson correlation coefficient to assess how well the model captured day to day variability in fault incidence.

After this evaluation, the selected configuration was retrained on the full monitoring period, again using early stopping, and then used to generate one step ahead predictions across the 6 months of data. For each day t , the model estimated the fault incidence on day t + 1 based on the aggregated operational variables and lagged fault incidence up to day t . The resulting sequence of daily predictions, plotted together with the observed daily fault counts, defines the 6 month prediction horizon referred to in Section 4.8.

To enable real-time monitoring and operational awareness directly within the BIM model, a custom data integration was developed using pyRevit platform. The objective was to link actual AHU sensor data, including temperature values and control signals, with Autodesk Revit, allowing real-time system behavior to be visualized and analyzed directly in the 3D environment. This approach embeds the dynamic operational state of the AHU inside the digital building model, supporting both maintenance planning and system diagnostics in a spatially contextualized interface.

To establish the data connection between real-time data and the Revit model, a pyRevit extension was developed. This custom script reads sensor values from a CSV file generated by a local monitoring system at 1-s intervals. This continuous data loop ensures that the digital twin reflects real-world system dynamics in near real time. The digital twin operates in a near real-time configuration, not a fully live streaming mode. Data synchronization is achieved through manual CSV uploads and periodic updates, yielding latency within seconds. This distinguishes it from continuous API-based real-time DT architectures as seen in other studies (Ilambirai and Padmini, 2019). While this semi-real-time workflow validates feasibility within constrained sensor environments, future work will transition to direct BMS-based streaming for full automation. Additionally, three APAR rules (R1, R7, and R16) described in Section 3.2.2 were implemented in simplified form within the pyRevit environment. If one or more rules are triggered based on the current sensor readings, the system provides immediate feedback through pop-up alerts using Revit’s TaskDialog interface and highlights the event on a live temperature chart with colored markers. While no direct visual change occurs in the Revit model itself, the external visualization panel serves as a real-time diagnostic.

The overall architecture of this data workflow, including data acquisition, rule processing via pyRevit, and potential integration with Revit parameters, is illustrated in Figure 9.

This implementation establishes a foundational workflow for future enhancements that could embed operational feedback directly into Revit elements through parameter bindings and model-based visual cues.

To complement the Revit-based integration and extend system accessibility beyond the BIM environment, a lightweight web platform was developed for real-time monitoring of AHU operation. The goal of this platform is to provide a device-agnostic, browser-based interface that can be accessed by engineers, technicians, or facility managers without requiring access to Revit or the BMS. This ensures operational transparency and continuous oversight of critical indoor environmental parameters regardless of the user’s technical environment.

Generally, the web platform’s architecture is modular and scalable. A Python Flask server functions as the backend, continuously polling live AHU data from the same source used in the pyRevit integration, either a shared CSV file updated by the local data logger or a direct API from the I4 Helse building’s monitoring system. The frontend is implemented in JavaScript and uses libraries such as Chart.js or Plotly to render dynamic and responsive graphs. Depending on the polling configuration, sensor values are refreshed every 2–5 s, enabling the visualization of near-real-time conditions across the system, while in this research, the interface is initialized through manual CSV upload, allowing users to simulate real-time data streaming. Upon file selection, JavaScript parses the dataset and begins a timed playback loop, refreshing data at 2-s intervals to emulate live monitoring.

The web dashboard displays a curated set of critical performance parameters, including Supply Air Temperature, Return Air Temperature, Mixed Air Temperature, Exhaust Air Temperature, and Outside Temperature, which are plotted using the Chart.js library in dynamic, real-time line graphs. Each chart is color-coded and synchronized to the same time axis to allow for comprehensive trend analysis. In addition to showing current values, the dashboard also presents a rolling time window typically covering the last 30 min to help identify trends and transient anomalies. When fault conditions are detected based on rule evaluations or model predictions, the interface highlights them using visual indicators such as color-coded warnings or fault badges.

Crucially, the web platform is not a passive viewer but an intelligent monitoring layer. It actively integrates a subset of the APAR rule engine described in Section 3.2.2, such as (R1, R7, and R16), applying these rules to the incoming data stream in real-time for fault conditions. Detected violations are recorded in a fault log panel with timestamped descriptions and are simultaneously reflected in a 3D visualization of the AHU system. This visualization, rendered using Three.js, dynamically changes the color of the AHU model to indicate fault type: red for heating faults (R1), green for zero-energy violations (R7), and blue for cooling faults (R16). In the absence of detected issues, the system defaults to neutral yellow. An auditory alert is also triggered alongside fault conditions to enhance user awareness. These dual detection systems, rule-based and data-driven, work together to ensure high diagnostic coverage and timely response to emerging system issues. This web-based solution effectively externalizes the intelligence of the predictive maintenance framework, making it available to stakeholders in a flexible, platform-independent format.

To visualize the correlation structure among input features, a Pearson correlation heatmap was generated. The heatmap Figure 10 illustrates the degree of linear relationship between feature pairs, with values closer to ±1 indicating stronger correlations.

Although the dataset was cleaned before correlation analysis, several features appear without correlation values. This does not indicate missing data but rather the absence of meaningful correlations for features that remained constant throughout the dataset. In this case, four features, as shown in Figure 10, include Outdoor Air Filter (Actual), Exhaust Air Filter (Actual), Supply Air Temp (Min), and Supply Air Temp (Max), did not vary over time. This likely occurred because the values of these four features did not change over time. For example, the two air filters are always operating, and the minimum and maximum supply air temperatures were fixed at 15 °C and 32 °C, respectively. In addition to the heatmap, Table 8 summarizes the feature pairs with correlation values exceeding 0.9, which were considered highly correlated for redundancy screening.

While several strongly correlated feature pairs were observed, such as Exhaust Air Fan Signal and Exhaust Valve Signal the decision was made to retain all features for the initial iteration. This was based on the relatively small dataset size and the potential importance of each variable to system behavior. Redundant features may still be considered for removal in future iterations or feature importance analysis.

Temperature-related features emerged as the most critical factors influencing fault prediction. As shown in Figure 11, the “Heater Valve Signal” had the highest importance in the Random Forest model, with a score of (0.358), followed by “Outside Temperature” (0.156), “Supply Air Temp (Actual)” (0.106), and “Mixed Air Temp (Actual)” (0.103). These findings suggest that external and internal temperature variations significantly affect AHU stability, potentially influencing heating, cooling, and ventilation performance. “Return Air Temp (Actual)” (0.091) and “Exhaust Air Temp (Actual)” (0.068) also contributed meaningfully, and reinforcing the role of air temperature regulation in maintaining system reliability. High ANOVA scores for these features, which are presented in Table 9, further validate their statistical relevance, confirming that temperature fluctuations are closely associated with fault occurrences. The “State” variable, representing the operational mode of the AHU, displayed an important score of (0.027), indicating that system state transitions play a significant role in predicting malfunctions.

Several operational control features also demonstrated a strong influence on fault detection. “Chiller Valve Signal” (0.022), “Heat Recovery Bypass Signal” (0.017), and “chiller Signal” (0.014) emerged as key indicators of AHU performance, emphasizing the importance of monitoring mechanical components and airflow regulation. The ANOVA analysis further highlighted the significance of control-related parameters, with highest value achieved by “Heater Valve Signal” (2,233.842), followed by “Chiller Valve Signal” (1,403.744), and “Chiller Signal” (1,400.980), demonstrating particularly high variance in relation to fault occurrences. These findings indicate that heating and cooling system components contribute substantially to fault prediction and require closer monitoring for effective fault diagnosis.

Specific parameters exhibited negligible or no importance in both methods. Features such as “Supply Air Temp (Max),” “Supply Air Temp (Min),” “Outdoor Air Filter (Actual),” and “Exhaust Air Filter (Actual)” had no measurable impact on the fault detection model, suggesting that they do not significantly contribute to predicting system failures. Retaining irrelevant features could introduce noise into the model, reducing its accuracy and increasing computational complexity. To prevent unnecessary redundancy and maintain predictive efficiency, these non-influential features were eliminated from further analysis.

Following this refinement, the final set of features retained for predictive modeling included “Heater valve signal,” “Outdoor Temp,” “Supply Air Temp (Actual),” “Mixed Air Temp (Actual),” “Return Air Temp (Actual),” “Exhaust Air Temp (Actual),” “State,” “Chiller Valve Signal,” “Heat Recovery Bypass Signal,” “Chiller Signal,” and “Fresh Air Fan (Actual).” These features collectively capture the most relevant aspects of AHU operation, ensuring that the fault prediction model is built on data-driven, high-impact variables. The identification and selection of these parameters enhance model accuracy, optimize predictive performance, and contribute to a more effective fault detection strategy.

Figure 14 illustrates the violation of Rule 3, which states that a fault is detected when the heating valve is fully open U h c _ 1 ≤ ɛ hc but the supply air temperature remains significantly below the setpoint T s a , s − T s a ≥ ɛ t . On 8 March 2021, between 09:35 and 11:35, the AHU operated in StateHeating, during which the heating valve command remained at 100%, indicating full activation of the heating coil. However, as shown in the middle plot, the supply air temperature (Tsa) stagnated at approximately 14.35 °C, failing to approach the setpoint of 23.5 °C. This prolonged deviation, despite maximum valve effort, suggests a heating performance deficiency. Possible root causes may include insufficient hot water supply, coil fouling, or a sensor calibration issue. The bottom plot confirms that no cooling coil activity occurred during this time (ucc = 0), affirming that heating was the primary conditioning mode.

Figure 15 presents a time-series visualization of the AHU operating state, temperature measurements, and control signals during a Rule 7 fault detection event. This rule applies during free cooling (Mode 2) and expects the supply air temperature (Tsa) and mixed air temperature (Tma) to be nearly equal. On 2 May 2021, a Rule 7 violation was recorded from 14:55 to 18:15. As seen in the second plot, the temperature difference between Tsa and Tma consistently exceeded the adjusted threshold of 4.2 °C, triggering the Rule 7 fault. The discrepancy could be caused by either inaccurate sensor reading or performance degradation in the air mixing process. The control signal plot further illustrates that both the heating and cooling coil valve signals remained at 0%, indicating that mechanical conditioning was disabled and cooling was expected to occur via outdoor air ventilation, which confirms that neither heating nor mechanical cooling influenced this behavior, affirming the presence of a free cooling anomaly.

Rule 16 identifies anomalies in mechanical cooling mode when the supply air temperature (T_sa) exceeds the expected cooling performance threshold, calculated as T m a + Δ T sf + ε t . On 7 June 2021, between 14:20 and 15:40, this rule was activated while the AHU was operating in mechanical cooling. As presented in Figure 16, throughout this period, the cooling coil (u𝒸𝒸) was fully open (100%), yet the supply air temperature persisted at a level of higher than the mixed air temperature. At 14:50, for example, T_ma = 26.41 °C and T_sa = 32.14 °C, violating the rule’s threshold. This persistent deviation suggests ineffective cooling performance despite maximum valve actuation, potentially due to chiller inefficiency, or other mechanical faults within the cooling subsystem.

Rule 28 is designed to detect excessive transitions between operating modes that may indicate unstable control behavior or sensor anomalies. It is applied across all occupied modes. On 23 April 2021, between 09:00 and 10:00, the AHU underwent multiple rapid transitions among StateCooling, StateHeating, and Unclassified. The number of mode changes during this 1-h period exceeded the predefined threshold (MT_max = 4), thereby triggering Rule 28. This behavior is illustrated in Figure 17, where the red line denotes the fault signal and the blue line reflects the fluctuating operating states. Such frequent switching can result in inefficient system operation, occupant discomfort, and accelerated wear of mechanical components.

Upon executing the pyRevit-based fault detection system, the real-time monitoring script processed AHU sensor data and effectively identified several fault events in accordance with the APAR rules. The system’s real-time capabilities ensure prompt identification and resolution of faults.

An external live plot visualized temperature data with dynamic color-coded markers corresponding to each fault rule, as illustrated in Figure 21. Green markers indicated violations of Rule 7, aligning with observed temperature deviations, while red and blue markers represented violations of Rules 1 and 16, respectively. Throughout the execution, the user interface remained responsive, continuously updating the visualization panel and triggering alerts without any noticeable delay.

Although the system did not implement parameter updates within the Revit model, it successfully integrated a live visualization panel with Revit’s 3D view, providing users with a comprehensive understanding of the system’s behavior. These results underscore the system’s practicality in swiftly detecting and communicating AHU operational anomalies using a lightweight rule-based approach.

The developed DT predictive maintenance platform was successfully deployed to simulate real-time monitoring and rule-based fault detection for an AHU using historical operational data. As illustrated in Figure 22, the web dashboard rendered synchronized time-series plots of five key environmental and system parameters: Supply Air Temperature, Mixed Air Temperature, Return Air Temperature, Exhaust Air Temperature, and Outside Air Temperature. These data were streamed from the CSV dataset at a time every 2 s, effectively replicating the behavior of a live sensor feed. The platform incorporated three APAR rules to detect operational anomalies: Rule 1 for detecting underperforming heating coils in StateHeating, Rule 7 for abnormal thermal deviation in ZeroEnergyState, and Rule 16 for excessive supply temperature during StateCooling.

Each time an APAR condition was violated, the system generated a real-time alert that was logged in the “Detected Faults” panel, alongside a timestamp and contextual explanation. Over the duration of the simulation, the fault detection engine responded consistently and accurately, correctly identifying dozens of rule violations. This confirmed the effectiveness of the rule-based monitoring logic. Additionally, a 3D visualization of the AHU was rendered using Three.js, providing a rotating fan model as a visual indicator of system activity. The dashboard operated entirely in the browser, requiring no backend server beyond the lightweight Flask API. This result demonstrates the practicality of using a browser-based digital twin solution for real-time HVAC system diagnostics, particularly in settings where platform independence and rapid feedback are essential.