Remote Monitoring and Diagnosis for Building Maintenance Units Based on Internet of Things System

Abstract

With the development of urbanization, building maintenance units (BMUs) have been widely used in super high-rise buildings. As aerial work machinery, condition monitoring plays a vital role in the safety maintenance and management of BMUs. However, BMUs have multi-source heterogeneous data relationships that are difficult for systems to understand. Moreover, at this stage, there is a lack of sufficient samples to support fault diagnosis data. Therefore, this paper proposes a real-time monitoring and fault diagnosis system for BMU operating conditions. This system, based on the Internet of Things (IoT) architecture, acquires and stores data from distributed BMU systems, improving the data collection and sharing rate throughout the entire process. A collaborative fault reasoning chain diagnosis model was established based on heterogeneous knowledge sources and real-time process signals, which increased the accuracy of fault identification to 97%. Finally, through simulation testing and evaluations, the system can stably transmit data within 6–7 days and accurately analyze the operational and fault status of BMU, with an error rate within 5%. It effectively improves the efficiency and accuracy of BMU condition monitoring and fault diagnosis and also provides a new method for the practical application of intelligent BMU operation and maintenance.

1. Introduction

BMUs are typically installed atop skyscrapers to transport maintenance personnel for exterior wall servicing [1]. As an aerial work platform, any safety mechanism failure, operational anomaly, or unexpected shutdown could endanger workers’ lives and incur catastrophic consequences [2,3]. Therefore, real-time monitoring and fault diagnosis are critical to minimize downtime and ensure operational reliability [4,5]. However, evolving architectural designs of commercial high-rises and diversified maintenance requirements have led to increasingly complex BMU configurations and structures. This complexity generates intricate multi-source data relationships, including the relationship between equipment structure and operating data, the relationship between operating data and fault status, and the relationship between fault status and fault causes [6]. Accurately modeling these multidimensional relationships and enabling rapid diagnostic outputs have become pivotal research challenges in fault diagnosis.

In recent years, with the maturation of multi-source information sensing and AI-assisted data mining technologies, knowledge-driven (KD) and data-driven (DD) approaches have been widely adopted in equipment condition monitoring (CM) and fault detection and diagnosis (FDD) [7,8,9]. DD fault diagnosis methods employ machine learning or deep learning algorithms to extract and identify fault patterns from operational datasets, though they often suffer from poor interpretability. In contrast, KD approaches primarily rely on textual rules, enabling networked and structured representation of domain knowledge. These methods equip machines with the capability to comprehend textual information and expert knowledge, thereby enhancing data interpretability, particularly for addressing the fundamental challenge of enabling computers to acquire domain expertise and understand the physical significance of data [10]. Beyond mere knowledge representation, KD techniques can also perform querying and reasoning based on established facts through semantic rules, thereby deriving new conclusions. Consequently, current research focuses on hybridizing DD and KD methodologies to strengthen a system’s ability to accurately diagnose faults [11,12]. For example, Li et al. [13] proposed a hybrid knowledge-based DD method for the distributed fault diagnosis of heterogeneous multi-agent systems, improving the decision-making ability of heterogeneous MAS. Hesam Hassanpour et al. [14] combined first principle knowledge with data for fault detection in HVAC systems to improve the performance of different clustering algorithms, outperforming purely DD methods. Li et al. [15] combined a data-driven symbol correction network with a model-driven orthogonal approximate message-passing network (OAMP Net) to correct detection errors in each iteration of the model-driven approach. However, this hybrid driving method requires the input of rich domain knowledge, accurate theoretical models, and massive system operation datasets, which are often very difficult to obtain. This relies on the long-term operation of the equipment and data accumulation [16,17,18]. In the case of insufficient public data samples, IoT technology is an effective method for obtaining big data samples [19,20]. For example, Jacome et al. [21] used IoT technology to obtain real-time data of photovoltaic systems to monitor their operating status and evaluate potential faults. IoT technology integrates physical information sensing, ultra-long-distance data transmission, and powerful cloud computing capabilities, effectively overcoming the coverage and real-time limitations of traditional data acquisition methods. Particularly suitable for remotely distributed systems like BMUs, it enables comprehensive data collection from all networked devices. The collected data are stored and processed through servers for model training and knowledge base updates. Real-time data acquisition further enhances diagnostic efficiency while significantly reducing equipment downtime.

Based on the above analysis, this study introduces a KD fused fault diagnosis approach within an IoT architecture for BMU operational data collection and fault state analysis. The proposed method integrates online equipment operational data with existing expert knowledge bases, enabling the mining of massive networked operational data to establish a global data relationship network and fault diagnosis inference links. This framework effectively achieves the intelligent management of BMU industry knowledge, facilitates smart fault analysis, and promotes information interconnectivity across the BMU industry. The main contributions of this paper are as follows:

• Establishment of an IoT architecture to acquire and store operational data from distributed BMU systems, forming a comprehensive dataset that serves as the foundation for system status analysis and fault detection.
• Development of a KD fusion framework that integrates expert-system prior knowledge with real-time operational data, which constructs multi-source relational association rules based on operational parameters and fault samples, ensuring the reliability of the proposed fault diagnosis model.
• Implementation of a multi-BMU integrated test system to validate the approach’s effectiveness. Experimental results demonstrate that the method simultaneously satisfies both accuracy and timeliness requirements for equipment fault diagnosis while providing comprehensive and innovative fault maintenance strategies.

The rest of this article is arranged as follows: Section 2 presents the comprehensive IoT system framework and the KD integrated fault diagnosis methodology. In Section 3, an experimental system was built to test the performance of this method. Section 4 concludes this paper.

2. System Design and Application

2.1. Overall System Architecture Design

This article proposes a remote real-time status monitoring and fault diagnosis system for BMUs based on the IoT. The system architecture and data transmission process are illustrated in Figure 1a,b.

As shown in Figure 1a, the system consists of 4 layers.

Perception Layer (L_p): This layer collects raw data through sensors and actuators on the BMU, which is processed by a gateway device (G) using Modbus RTU or similar protocols. Raw data $D_p(t)$ are converted to a network-compatible format $D_p^{\prime }(t)$, as shown in Formula (1):

$$L_P:D_p(t)\stackrel{{\Pi }_{ModbusRTU}}{\to }{D}_p^{\prime }(t)$$

(1)

Network Layer (L_n): This layer ensures reliable data transmission from the perception layer to the data processing layer using communication technologies such as 5G or Wi-Fi, following the TCP/IP protocol stack. The data $D_p^{\prime }(t)$ are transmitted as $D_{dp}(t)$, as shown in Formula (2):

$$L_n:D_p^{\prime }(t)\stackrel{{\Pi }_{TCP/IP},{\Pi }_{5G/WIFI}}{\to }{D}_{dp}(t)$$

(2)

Data Processing Layer (L_dp): At this core layer, data from the network layer is analyzed using real-time fault diagnosis models (M_fd), generating diagnostic results R(t). This process is represented using Formula (3):

$$L_{dp}:D_{dp}(t)\stackrel{M_{fd}}{\to }R(t)$$

(3)

The results R(t) are published using MQTT and API for application access, as shown in Formula (4):

$$Pub:R(t)\stackrel{{\Pi }_{MQTT},API}{\to }{R}^{\prime }(t)$$

(4)

Application Layer (L_a): users interact with the system through a client interface, retrieving the diagnostic results $R^{\prime }(t)$ and visualizing device status and fault information, as shown in Formula (5):

$$L_a:R^{\prime }(t)\to U(t)$$

(5)

The system’s modular design, incorporating edge computing, cloud computing, and standard communication protocols, ensures seamless data flow across layers, achieving real-time monitoring and fault diagnosis for BMUs.

As shown in Figure 1b, the cloud server hosts both a TCP/IP server and an MQTT server. When remote devices come online, they establish connections with designated server ports. The TCP server then initiates Modbus requests for data acquisition using the format specified in Equation (6). The gateway returns data in the format shown in Equation (7). The received command formats are parsed into actual datasets, which are subsequently packaged into JSON format via the MQTT protocol and published under the topic ‘$BMUMS/DevTx/id’. The application layer can access all device data by subscribing to this topic.

$$Req=\left[Slave\_Addr\right]+\left[FC\right]+\left[Start\_Addr\right]+\left[Quantity\right]+[CRC]$$

(6)

$$Resp=\left[Slave\_Addr\right]+\left[FC\right]+\left[Byte\_Count\right]+\left[Data\_Byes\right]+[CRC]$$

(7)

This entire process is implemented in the server as detailed in Algorithm 1:

Algorithm 1: System data transmission and processing process

Input: client_socket Output: continuously monitor and process client requests 1. import socket 2. import MQTT 3. socket.socket() // Create a server-side socket object 4. bind((“ip”,port)) // Bind the host’s IP address and port number 5. Listen() 6. while True: 7. accept() // Wait for the client’s connection request 8. recv() // Receive gateway MAC ID 9. send() // Send MODBUS command to the client 10. recv() // Receive gateway return message 11. analy() // Data parsing function 12. mqtt_client.publish() // MQTT server publishes messages 12. if the device goes offline 13. close() // Close the connection 14. break

2.2. Establishment of the Real-Time Fault Diagnosis Model Based on Multi-Correlation Data

Diagnosing faults in BMUs effectively necessitates integrating diverse, multi-source data, including both real-time operational parameters and prior knowledge derived from equipment documentation and expert systems. To address this challenge, this paper proposes a collaborative fault inference chain model. This model organizes the required knowledge and diagnostic processes into two distinct but interconnected layers:

Data Layer: This foundational layer establishes a structured and formalized knowledge base. Its purpose is to represent the complex relationships between BMU components, operational states, potential faults, and associated data points, integrating prior knowledge in a machine-interpretable format.

Inference Layer: this layer operates on top of the data layer. It implements the diagnostic logic, utilizing the structured knowledge base and real-time operational data feeds to infer the current system state and identify potential faults.

2.2.1. Construction of Data Layer Structure

The construction of the data layer, introduced above, focuses on creating a comprehensive and structured representation of BMU-related knowledge. This involves capturing both concrete semantic descriptions of facts and abstract conceptual attributes [22,23]. The primary goal is to abstract key concepts (like equipment components, actions, and faults), their attributes, and the relationships between them from the available domain knowledge. This process defines the description scope, hierarchical architecture, and association rules of the global data structure needed for the diagnosis.

This study employs a top-down construction methodology. Concepts are identified and then linked via directed edges that represent the logical or physical relationships between them. This methodology results in the BMU data layer structure framework diagram shown in Figure 2.

Figure 2 illustrates the correlation between device structure, action form, fault information, and operational data. Among them, the structure of the device determines the actions and functions that the device can perform, and each action has data points related to it. The data points have attributes such as the type, address, and value, and the action or fault state of the device can be inferred through the value attributes of the data points. The type and address attributes can be used to determine the fault type and locate the fault. Therefore, the core concept of describing the fault diagnosis problem of BMU operations can be divided into basic equipment data, which mainly include the equipment model, the user unit, factory installation information, project information, etc.; operating data, which mainly include the equipment operating status, operating time, abnormal alarms, operating data values, etc.; and fault data, which mainly include the fault type, fault description, fault analysis, fault location, and handling suggestions. Finally, the integration of BMU equipment structure, installation location, action form, fault description, fault location, fault analysis and other information was achieved, and the correlation between all concepts was expressed.

2.2.2. Design of the Diagnostic Model Based on a Fault Constitutive Relationship

The relationship between general fault phenomena and root causes is based on binary data, which cannot be used to handle more complex multi-source data relationships [24,25]. Therefore, based on the established data layer structure model and the application of multivariate relationship knowledge expression methods, this article introduces operational data variables into the fault phenomenon–fault cause correlation matrix and establishes a multi-source relationship correlation matrix based on operational data, fault phenomena, and fault causes. Firstly, establish the correlation between operational data and fault phenomena, as shown in Figure 3.

From Figure 3, it can be observed that the real-time operational dataset D_t plays a crucial role in this process, representing different real-time data states or feature sets. By introducing a predefined diagnostic rule set $R_{diag}=\left\{r_1,r_2,\cdots ,r_m\right\}$, each rule r_j is associated with a specific fault phenomenon $S_j\in \left\{s_1,s_2,\cdots ,s_m\right\}$ and defines a mapping from the real-time data space to a Boolean output. A rule r_j is activated, and the corresponding fault phenomenon s_j is triggered if and only if the data vector D_t satisfies the logical conditions defined by r_j. These rules reflect domain expert knowledge, device operating safety thresholds, or anomaly patterns learned from historical data. Specifically, under a particular real-time data state D_t, the rule r_j can identify and activate the corresponding fault phenomenon s_j by satisfying its logical conditions, i.e., r_j (D_t) = 1, as shown in Figure 3. The result of this process is the formation of a set of active fault phenomena S_active (t), which contains all the fault phenomena corresponding to the triggered rules. This set can be expressed using Formula (8).

$$S_{active}(t)=\left\{s_j\in S|r_j(D_t)=1\right\}$$

(8)

The schematic in Figure 3 provides a visual representation of the decision result matrix of rule set R_diag under different real-time data inputs, reflecting the process of identifying system-level fault symptoms from real-time data. This process not only achieves the recognition of fault phenomena but also provides a foundation for subsequent fault cause analysis.

Upon identifying an active fault phenomenon $S_j\in S_{active}(t)$, the next step is to infer the most likely cause from the predefined set of potential root causes $F=\left\{f_1,\cdots ,f_z\right\}$, as outlined in

Table 1. The causes of each fault phenomenon.

Fault Type	Phenomenon	Cause
Abnormal self-check	Host communication abnormality	Communication line disconnected; the communication module is damp.
	Inverter fault	Voltage too high; excessive temperature; excessive humidity leads to internal short circuit.
	Rope slack fault	Wear and tear of the rope-loosening mechanism.
	Overspeed protection failure	Brake disk wear; overspeed detection failure.
	Chain breakage	Wear and tear; overload; improper installation leads to unstable splicing.
No input signal	Knob contact malfunction	Poor contact of contacts caused by moisture, arcing, and dust.
	The wiring is disconnected	Loose joints; broken due to external force.
No output signal	The device has no action	Equipment action output conditions not met.
	Action limit switch failure	Internal short circuit or open circuit caused by water ingress and aging.
Contactor failure	Contactor failure	Excessive loads lead to arc breakdown; high humidity causes internal moisture.
Motor protector failure	Motor protector failure	Long-term high temperatures lead to aging; excessive humidity on the rooftop leads to a decrease in insulation performance.
Motor failure	Motor failure	Unstable voltage, high temperature, and moisture.
Hydraulic system failure	Hydraulic valve malfunction	Poor assembly quality and clogged valve core.
	Hydraulic pipeline damage	External damage and corrosion.
	Hydraulic joint leakage	Damaged seals; improper installation; corrosion; high-voltage impact.

.

Due to the often ambiguous nature of the relationship between phenomena and causes, which may exhibit “one-to-many” or “many-to-many” characteristics, probabilistic methods are introduced to quantify the inference process. The methodology employs Bayesian inference, integrating statistical correlations extracted from historical data or expert knowledge. The strength of the relationship between phenomena and causes is modeled as conditional probabilities.

Formally, a phenomenon–cause probability matrix I is constructed, where its dimensions are Z × M, corresponding to Z causes and M phenomena. This matrix is explicitly defined in Formula (9):

$$I=\left[\begin{array}{l}{I}_{11},I_{12},\cdots ,I_{1M}\\ I_{21},I_{22},\cdots ,I_{2M}\\ \cdots \\ I_{Z1},I_{Z2},\cdots ,I_{ZM}\end{array}\right]$$

(9)

The elements of the matrix I_kj are rigorously defined as the posterior probability $P(f_k|s_j)$, representing the likelihood that the root cause f_k is responsible for the fault phenomenon s_j, as shown in Formula (10):

$$I_{kj}=P(f_k|s_j)$$

(10)

This matrix serves as the core of the diagnostic knowledge base, quantifying the inference strength from the symptom s_j to the root cause f_k. Parameter estimation for the matrix I typically involves statistical analysis of a large dataset of historical fault cases. A common approach is to use frequency-based maximum likelihood estimation, as shown in Equation (11):

$$\widehat{P}(f_k|s_j)={\eta }_{kj}={\displaystyle \frac{N(f_k,s_j)}{N(s_j)}}$$

(11)

where $N(f_k,s_j)$ represents the number of instances in which phenomenon s_j occurs and is associated with root cause f_k, and $N(s_j)$ denotes the total number of occurrences of phenomenon s_j in the historical dataset. The validity of this estimation relies on the adequacy and representativeness of the historical data, assuming that the statistical patterns observed remain applicable in the current diagnostic context.

During the inference process, for any identified active fault phenomenon $S_j\in S_{active}(t)$, the diagnostic system extracts the corresponding column vector from the probability matrix I as Formula (12):

$$P_j={\left[I_{1j},I_{2j},\dots ,I_{zj}\right]}^{\mathrm{T}}={\left[P(f_1|s_j),P(f_2|s_j),\dots ,P(f_Z|s_j)\right]}^{\mathrm{T}}$$

(12)

Vector P_j provides the posterior probability distribution of all potential root causes $f_k\in F$, given the observed phenomenon s_j. Based on the maximum a posteriori (MAP) criterion, the most probable root cause $f_{inferred}^{*}$ is determined by Formula (13):

$$f_{inferred}^{*}(s_j)=\arg \underset{f_k\in F}{\max }P(f_k|s_j)=\arg \underset{k\in \left\{1,\cdots ,Z\right\}}{\max }{I}_{kj}$$

(13)

In practical applications, the system typically outputs a ranked list of candidate root causes, which are ordered by the probability I_kj, to assist maintenance personnel in decision-making. This process completes the transition from raw data to the identification of system-level symptoms, enabling effective diagnostic reasoning.

2.2.3. Construction of a Data Processing Layer Framework with a Real-Time Fault Diagnosis Model

Based on the established global data relationship network for BMU operation and the correlation matrix of multi-source relationships for operationa data-fault phenomenon-fault root cause, a data processing layer framework incorporating a real-time fault diagnosis model was constructed. The basic structure and diagnostic process of the framework are shown in Figure 4a,b.

From Figure 4a, it can be seen that the data relationships are stored in the database and embedded in the data processing layer in a system-recognizable manner. Among them, the storage methods of data in the data processing layer include process data classification and fault information storage, which can classify signals and analyze possible causes of faults based on fault diagnosis rules, provide diagnostic recommendations, and then interact with the application layer to ensure the independence of the fault diagnosis knowledge base, facilitating the update and maintenance of diagnostic rules and solutions. Based on the real-time fault diagnosis model established above, the specific calculation process for state analysis and fault diagnosis is shown in Figure 4b.

3. The Simulation Test of the System

3.1. Establishment of the Testing System

In order to verify the practical application of the system, we have built a test system for simulation testing. Building the test system includes developing the simulation control system of the BMU, connecting the remote communication module, building the cloud server, etc. [26,27]. The key elements of the test system are shown in

Table 2. Key elements of the test system.

Item	Quantity	Description
Simulation control system of the BMU	1	The control system simulating the working state of the BMU.
Communication module	1	The gateway to transfer data to the cloud server.
Cloud server	1	The platform for providing cloud services.
Laptop	1	The device to log in to the client for monitoring.

.

The BMU control system controls the input and output signals of the PLC to simulate the working state of the BMU. This system includes PLC, HMI, a power supply, a switch, the contactor, an indicator light, and other components, and the communication module is connected to the system via the RS485 interface, as shown in Figure 5. The module configuration involves both serial port and network protocol settings. The serial port parameters (baud rate, data bits, etc.) must match those of the BMU controller. The network protocol adopts TCP/IP, with the communication module configured as a TCP client. The cloud server’s public IP address and receiving port are added to establish the connection. Each communication module features a factory-programmed MAC address that serves as its unique identifier. During each power-on sequence, the module uploads this MAC address to the server upon establishing a connection, which serves as the primary device authentication criterion.

In the cloud server environment, a TCP server was implemented using Python 3.9, while EMQX 4.0 was deployed as the MQTT broker to receive and process data streams [28,29]. The client adopts a B/S architecture, utilizing Apache as the web server to process client requests. The Apache server is configured by setting the website’s homepage and domain name. After completing the configuration, the Apache server is started, enabling browser access to the client through the domain name. The database uses MySQL 8.0, and the client operates the database by calling API interfaces.

3.2. Application Simulation Analysis

To verify the effectiveness of the IoT-based BMU remote monitoring and fault diagnosis system proposed in this paper (see Section 2 for details), especially the performance of its fault diagnosis model, in this study, a simulation control system is established for the BMU and cloud server, and we conducted a series of simulation experiments. Considering the various operating conditions and fault modes that may occur during actual BMU operation (refer to Table 1), the experiment used a simulated dataset containing normal operating conditions and multiple typical fault types to obtain real-time data of the BMU simulation control system at a frequency of 2 s. Figure 6a demonstrates the monitoring interface during normal BMU operation (executing the boom left-rotation maneuver). After inputting the fault samples of the left-rotation contactor into the system, the client displays the interface shown in Figure 6b.

3.3. Result Analysis

The simulation dataset is generated by the BMU testing system, which contains six categories of states, covering normal operation, and five typical BMU faults that are selected according to Table 1:

• Category 0: Normal Operation
• Category 1: Host Communication Abnormality
• Category 2: Inverter Fault—Excessive Temperature
• Category 3: Rope Slack Fault
• Category 4: No Input Signal—Knob Contact Malfunction
• Category 5: Contactor Failure—Left Rotate as an Example

For these categories, key features capable of reflecting their state differences were selected for simulation, including normal operation signals, communication connection signals, inverter signals, rope slack switch signals, knob input signals, and contactor feedback signals. The dataset contains a total of 1200 samples (200 samples per category), with each sample representing a data snapshot at a specific time point. During data generation, appropriate noise was added to simulate data fluctuations under real operating conditions.

3.3.1. Diagnostic Performance Evaluation

The fault recognition capability of the diagnostic model proposed in Section 2.2 was evaluated using a simulated dataset, as shown in Figure 7.

Figure 7 shows the confusion matrix between the predicted category of the model and the true category of the sample in the simulated diagnosis. From Figure 7, it can be seen that the values of the main diagonal elements of the matrix are much higher than those of the non-diagonal elements, indicating that the model has very high recognition accuracy for all six categories. For example, for categories such as “normal operation” and “contactor failure”, the vast majority of samples are correctly classified. A small number of values on non-diagonal lines reveal confusion in the model. A small number of samples in category 4 were incorrectly identified as category 1, revealing a certain similarity in the selected features between these two types of faults. Overall, the diagnostic accuracy reached 97%, verifying both the feasibility and effectiveness of this diagnostic framework.

3.3.2. Feature Effectiveness Analysis

To comprehensively evaluate the capability of the selected feature set in distinguishing different fault categories, t-distributed Stochastic Neighbor Embedding (t-SNE) was employed to reduce the dimensionality of the high-dimensional feature data, and the visualization results in the 2D space are presented in Figure 8.

In Figure 8, each point represents a data sample, and the color corresponds to its true category label. It can be observed that the sample points of different categories tend to form relatively independent clusters in the two-dimensional space. The cluster of “normal operation” (blue dots) has good discrimination from the clusters of other fault categories. Most fault categories, such as “contactor failure” and “rope slack”, have also formed unique clustering areas. Overall, the t-SNE visualization results indicate that based on the selected features in this paper, different fault categories and normal states have good separability in the feature space, which further supports the conclusion that the proposed diagnostic model can achieve high accuracy.

3.3.3. Stability Analysis

To evaluate the long-term operational reliability of the system, a 7-day continuous simulation test was conducted. The stability of its connection is shown in Figure 9a, and based on this, the performance stability of the diagnostic model during long-term operation was further evaluated. In the test, the 7-day simulation process was divided into seven time windows, and the comprehensive recognition accuracy of the diagnostic model for all states (normal and various types of faults) within each window was independently calculated. The result is shown in Figure 9b.

The system connection status shown in Figure 9a indicates that the system maintained a high degree of connection stability during the testing period, proving its reliability as the foundation of the remote monitoring platform. From Figure 9b, it can be seen that although there was performance degradation throughout the entire 7-day testing cycle, the diagnostic accuracy of each time window remained stable at over 95%, indicating that the diagnostic model proposed in this paper not only has high overall accuracy but also exhibits good performance stability under simulated continuous operating conditions. Combining the results of Figure 9a,b, it has been verified that the system can stably transmit data and continuously provide high-precision state analysis and fault diagnosis.

4. Conclusions

In summary, based on the IoT architecture, this article has achieved the acquisition and storage of complex multi-source data for BMUs. On this basis, the system integrates expert-system prior knowledge with real-time operational data, establishing multi-source relational association rules based on operational data and fault samples, thereby enhancing its real-time CM and fault diagnosis capabilities. An integrated test system with multiple BMUs was constructed, and the test dataset extracted from it was used to evaluate the system’s real-time fault recognition rate, achieving 97% accuracy as measured by a confusion matrix. Furthermore, simulated continuous operation tests were conducted to assess the system’s stability in analyzing BMU operational and fault states.

The development of this system not only enhances the efficiency and accuracy of real-time CM and fault diagnosis for BMUs but also lays a solid foundation for the practical implementation of intelligent maintenance in BMU applications. The real-time fault diagnosis method, which preprocesses complex multi-source data relationships of BMUs through an IoT architecture and integrates expert-system prior knowledge with real-time operational data, provides novel technical approaches and solutions for this field.

While the system has achieved its initial objectives, certain limitations remain. The system could be enhanced through two key aspects:

(1)

Although this study proposes IoT-based data collection to address insufficient samples, the process remains time-consuming. Future improvements could incorporate evolutionary learning mechanisms and data augmentation techniques to expand the sample size, thereby obtaining more accurate real-time data and refining the fault diagnosis correlation model.

(2)

The current fault diagnosis method focuses on outputting real-time status results and root cause analysis for BMU but lacks preventive recommendations. The system could integrate multi-axis force sensors and machine learning algorithms to analyze structural wear, enabling predictive maintenance strategies and establishing a comprehensive intelligent maintenance framework for BMUs.