A method and system for rapid inspection and remote monitoring of power supply boxes

Abstract

This invention belongs to the technical field of monitoring and control and data acquisition systems, specifically relating to a method and system for remote monitoring of power supply boxes for rapid maintenance. The method includes: generating a baseline fingerprint of equipment performance based on comprehensive overhead and benchmark average response time for different monitoring terminals; constructing a three-tiered object pool and assigning initial health status; prioritizing instance allocation based on health status upon receiving instructions, and calculating a decision score based on comprehensive overhead, load factor, and degradation degree to determine whether to create a new instance when insufficient; updating the health status after communication by combining status code, error weight matrix, and time deviation, and returning instances to the corresponding queue according to dynamic dual thresholds. This invention improves instance scheduling and reuse efficiency through baseline fingerprints and a three-tiered health status assessment mechanism, and dynamically adjusts the return threshold to smooth out peaks and valleys, thereby improving system response efficiency and communication reliability.

Description

Technical Field

[0001] This invention relates to the field of monitoring, control, and data acquisition systems. More specifically, this invention relates to a method and system for remote monitoring of power supply boxes for rapid maintenance. Background Technology

[0002] Power supply box monitoring systems typically require the connection of various types of monitoring terminals, which differ in communication protocols, hardware performance, and network environments. During actual monitoring, the system frequently needs to establish communication connections with each terminal. Traditional methods, when faced with high-concurrency monitoring commands, often require repeatedly creating and destroying communication instances, resulting in additional overhead such as network handshakes, protocol authentication, and memory allocation. This can easily lead to increased system response latency, increased resource consumption, and even system overload when terminal status is unstable or requests surge. Existing remote monitoring systems typically combine the Abstract Factory pattern and object pooling technology for optimization. The Abstract Factory pattern decouples the instance creation process for different terminal protocols, enabling unified management of multiple communication instances. Object pooling technology reduces the performance overhead caused by frequent instantiation by caching and reusing already created communication instances, thereby improving resource utilization and reducing response latency.

[0003] However, existing mechanisms typically lack a globally relevant assessment of the operational status when determining whether to create a new instance. They fail to adequately consider the actual overhead differences between different terminals during the handshake, authentication, and initialization phases, and also fail to comprehensively consider the current load level and degradation degree of the object pool. In high-load scenarios, using only fixed queuing or direct creation strategies can easily lead to increased request waiting times or rapid expansion of resource consumption. Furthermore, existing object pools often employ a single-level queue management approach, lacking continuous assessment and tiered processing of the health status of reused instances. When an instance is affected by network jitter, terminal anomalies, or protocol errors during communication, directly returning the sub-healthy or abnormal instance to the object pool and reassigning it to subsequent tasks can easily result in invalid retries, error accumulation, and degraded communication quality, thereby affecting the reliability and real-time performance of the power supply box remote monitoring system. Summary of the Invention

[0004] To address the technical problems of unreasonable instance allocation and system overload caused by repeated reuse of abnormal instances under high concurrency, this invention provides solutions in the following aspects.

[0005] In a first aspect, the present invention provides a method for rapid maintenance of a power supply box via remote monitoring, comprising: S1, setting an abstract factory to generate and store a device performance baseline fingerprint containing a comprehensive overhead including handshake overhead, authentication overhead, and initialization overhead, as well as a baseline average response time for different monitoring terminals; constructing a three-tiered object pool divided into an active object queue, a standby object queue, and an isolation diagnostic queue, and assigning an initial health assessment value to new instances; S2, when receiving an instruction, prioritizing the allocation of instances in the active object queue according to the health assessment value from high to low, and allocating in the standby object queue if empty; if both are empty and there are no allocated instances, then the abstract factory creates a new instance within the capacity constraint; if there are already allocated instances, then... Obtain the system load factor and pool degradation degree. Calculate a creation decision score based on the overall overhead, system load factor, and pool degradation degree. If the score is lower than a preset creation threshold, the abstract factory creates a new instance; otherwise, wait. S3: After communication is completed, generate a session summary containing the actual total time, error type, number of occurrences, and status code. Referring to the weight matrix that maps status codes and error types to penalty factors, and combining the deviation between the actual total time and the baseline average response time, update the instance's health assessment value. Based on the comparison between the health assessment value and the first and second return thresholds adjusted based on the system load factor, place the instance in the active object queue, standby object queue, or isolation diagnostic queue.

[0006] This invention achieves differentiated evaluation of communication performance for multiple types of terminals through device performance baseline fingerprinting. It improves the rationality and reuse efficiency of communication instance scheduling through a three-level object pool and a health-priority allocation mechanism. By calculating decision scores based on comprehensive overhead, system load factor, and pool degradation degree, it reduces resource risks caused by blind creation or long-term waiting in high-concurrency scenarios. By combining deviation degree and weight matrix to update health degree and dynamically adjust return threshold, it promptly isolates abnormal instances and maintains the flow of healthy instances, effectively improving the system's response efficiency and communication reliability.

[0007] Preferably, the step of setting an abstract factory to generate and store a device performance baseline fingerprint for different monitoring terminals, including a comprehensive overhead of handshake overhead, authentication overhead, and initialization overhead, as well as a benchmark average response time, includes: initiating multiple concurrent communication connection requests to the target monitoring terminal under a preset test environment; collecting the network socket establishment time as handshake overhead, the time for the security module to parse the digital signature credential as authentication overhead, the time for the operating system to allocate memory and port resources to the communication process as initialization overhead, and collecting the actual total time consumption of each communication connection; summing the three overheads to obtain the comprehensive overhead, and taking the average value after removing extreme values ​​from the actual total time consumption as the benchmark average response time.

[0008] This invention obtains the handshake, authentication, and initialization overhead by precisely calculating the network socket establishment time, the time for parsing digital signature credentials, and the time for allocating memory and port resources. This ensures the accuracy of the baseline fingerprint data and provides a reliable performance evaluation basis for subsequent instance scheduling.

[0009] Preferably, the construction of a three-tiered object pool, comprising an active object queue, a standby object queue, and an isolation diagnostic queue, includes: pre-allocating a contiguous address space in system memory as the storage boundary of the object pool, and setting a maximum capacity limit; establishing three pointer arrays pointing to the active object queue, the standby object queue, and the isolation diagnostic queue, respectively; the active object queue is used to store instances that have recently successfully communicated and whose health assessment value is higher than a first return threshold; the standby object queue is used to store instances that have completed initialization but are currently idle and whose health assessment value is between the first return threshold and a second return threshold; and the isolation diagnostic queue is used to store abnormal instances that have experienced continuous communication failures or whose health assessment value is lower than the second return threshold.

[0010] This invention effectively reduces memory fragmentation caused by the creation and destruction of scattered objects by pre-allocating contiguous address space in system memory as storage boundaries and using pointer arrays to map queues at different levels, thereby reducing the probability of frequent garbage collection.

[0011] Preferably, the step of calculating the creation decision score based on the overall overhead, the system load factor, and the pool degradation degree includes: normalizing the overall overhead by dividing it by a preset maximum tolerable overhead threshold to obtain an overhead factor; calculating the ratio of allocated instances to the maximum capacity limit to obtain the system load factor; calculating the ratio of instances in the isolation diagnostic queue to the maximum capacity limit to obtain the pool degradation degree; and multiplying the overhead factor, system load factor, and pool degradation degree by preset weighting coefficients and then performing a weighted sum to obtain the creation decision score.

[0012] This invention calculates the decision score by weighting and summing the comprehensive overhead factor, system load factor, and pool degradation degree, thereby achieving a multi-dimensional global operational status assessment. This avoids decision bias caused by a single indicator and improves the rationality of instance expansion under high concurrency.

[0013] Preferably, the error types include: data frame verification failure, message length mismatch, communication timeout loss, and unauthorized instruction; for each error type, an initial penalty factor is assigned in the weight matrix, and the penalty factor increases exponentially with the cumulative number of occurrences of the same type of error in multiple consecutive communications.

[0014] Preferably, updating the instance's health assessment value by combining the deviation between the actual total time consumption and the benchmark average response time includes: calculating the difference between the actual total time consumption and the benchmark average response time; if the difference is positive, dividing the difference by the benchmark average response time to obtain the time deviation; if the difference is not positive, recording the time deviation as 0; retrieving the penalty factors corresponding to the status code and error type from the weight matrix and summing them to obtain the total penalty value; generating a positive health recovery amount based on a preset recovery coefficient when both the total penalty value and the time deviation are 0; otherwise, recording the health recovery amount as 0; generating a time decay amount based on the time deviation and a preset time decay coefficient; adding the health recovery amount to the health assessment value before return and subtracting the total penalty value and the time decay amount to obtain the updated health assessment value, and limiting it to between 0 and a preset health upper limit value through clamping logic.

[0015] This invention calculates the time deviation and obtains the penalty factor by looking up a table, and combines the recovery coefficient and the decay coefficient to calculate the updated health assessment value. Finally, it uses clamping logic to ensure that the health value is within the standard range, thereby achieving accurate and dynamic tracking of the health status of the instance.

[0016] Preferably, adjusting the first return threshold and the second return threshold based on the system load factor includes: real-time monitoring of the system load factor of the three-level object pool; when the system load factor is greater than a set high load threshold, reducing the first return threshold and the second return threshold; when the system load factor is less than a set low load threshold, increasing the first return threshold and the second return threshold; during the adjustment process, a preset anti-inversion constraint mechanism is used to ensure that the first return threshold is always greater than the second return threshold.

[0017] Preferably, the setting of the abstract factory includes: defining an abstract factory interface for the power supply box monitoring device, and deriving specific factory classes that are adapted to different communication protocols; wherein, the different communication protocols include at least one of Modbus protocol, MQTT protocol and SNMP protocol.

[0018] Preferably, the step of prioritizing the allocation of instances in the active object queue according to the health assessment value from high to low includes: maintaining the active object queue using a priority blocking queue, and sorting the instances according to the health assessment value from high to low; when allocating instances, taking out the instance at the head of the active object queue and assigning it to the business thread corresponding to the current instruction to execute the communication task.

[0019] Secondly, the present invention provides a remote monitoring system for rapid maintenance of power supply boxes, including a processor and a memory, wherein the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the aforementioned method for rapid maintenance of power supply boxes is implemented.

[0020] By adopting the above technical solution, a computer program is generated from the above-mentioned method for rapid maintenance of power supply boxes and stored in the memory so that it can be loaded and executed by the processor. In this way, a terminal device can be made based on the memory and the processor for convenient use.

[0021] The beneficial effects of this invention are as follows:

[0022] This invention achieves differentiated evaluation of communication performance for multiple types of terminals by setting abstract factories for different monitoring terminals and generating device performance baseline fingerprints that include handshake overhead, authentication overhead, initialization overhead, and baseline average response time. By constructing a three-tiered object pool of active, standby, and isolated diagnostics, and prioritizing the allocation of available instances based on health assessment values ​​when receiving instructions, the rationality and reuse efficiency of communication instance scheduling are improved. When the active and standby object queues are empty, a creation decision score is calculated based on comprehensive overhead, system load factor, and pool degradation degree to determine whether to generate a new instance, reducing resource risks caused by blind creation or long waiting times in high-concurrency scenarios.

[0023] Furthermore, after communication is completed, the instance health is updated based on the session summary, error penalty factor, and time deviation, and the return threshold is dynamically adjusted in conjunction with the system load factor. The instances are then assigned to their respective queues, thereby isolating abnormal instances in a timely manner, maintaining the flow of healthy instances, and improving the response efficiency and communication reliability of the power supply box remote monitoring system. Attached Figure Description

[0024] Figure 1 This is a flowchart of a method for rapid inspection and remote monitoring of a power supply box according to the present invention; Figure 2 This is a schematic diagram of the baseline performance overhead of the terminal device in this invention; Figure 3 This is a schematic diagram of threshold adjustment based on system load factor in this invention; Figure 4 This is a schematic diagram comparing the performance of different object pooling mechanisms in this invention. Detailed Implementation

[0025] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0026] This invention discloses a method for rapid troubleshooting and remote monitoring of power supply boxes, referring to... Figure 1 This includes steps S1-S3: S1. Generate device performance baseline fingerprints and build an object pool.

[0027] In an optional embodiment, an abstract factory is set up for different monitoring terminals to generate and store a device performance baseline fingerprint that includes handshake overhead, authentication overhead, initialization overhead, and benchmark average response time for each monitoring terminal through protocol testing; a three-level object pool is constructed that divides instances into an active object queue, a standby object queue, and an isolation diagnostic queue, and an initial health assessment value is assigned to new instances.

[0028] An abstract factory interface for the power supply monitoring device is defined using an object-oriented programming language. Based on polymorphism, concrete factory classes are derived to adapt to Modbus, MQTT, and SNMP protocols respectively. For monitoring terminals using different protocols, a communication connection is established, and a timing function is called to record the time required for the three-way handshake of the Transmission Control Protocol (TCP), which is considered handshake overhead. Handshake overhead refers to the time consumed in confirming the connection between the monitoring system and the target monitoring terminal. For communication protocols with secure authentication mechanisms, the OpenSSL encryption library or corresponding security module is called to record the time required for certificate verification, token verification, or key exchange, which is considered authentication overhead. Simultaneously, the time required for the system to allocate memory, port resources, and protocol session context for the communication instance is recorded, which is considered initialization overhead. The handshake overhead, authentication overhead, and initialization overhead are added together to obtain the comprehensive overhead for the corresponding monitoring terminal.

[0029] By sending standard probe messages to the device and listening for the returned results, the average time of 10 consecutive communications is calculated using an exponentially smoothed moving average algorithm as the baseline average response time. A hash data structure is used to store the device performance baseline fingerprint, which contains the overall overhead and the baseline average response time, with the device's media access control address as the key. Three concurrent safety queue structures, constrained by the maximum capacity of the object pool, are instantiated in system memory. These queues are mapped to an active object queue, a standby object queue, and an isolation diagnostic queue, forming a three-tiered object pool. A constant maximum capacity is set for the object pool. When the abstract factory instantiates a new connection instance object using the factory method pattern, a floating-point value of 100 is assigned to the memory attribute field of the new connection instance object as the initial health assessment value.

[0030] In an optional embodiment, a device performance baseline fingerprint is generated and stored for each monitoring terminal during protocol testing. This fingerprint includes a comprehensive overhead of handshake overhead, authentication overhead, and initialization overhead, along with a baseline average response time. Specifically, under a preset test environment, multiple concurrent communication connection requests are initiated to the target monitoring terminal. The network socket establishment time is collected as the handshake overhead, the time for the security module to parse the digital signature credential is collected as the authentication overhead, and the time for the operating system to allocate memory and port resources to the communication process is collected as the initialization overhead. The actual total time of each communication connection is also collected. The three overheads are summed to obtain the comprehensive overhead, and the average value after removing extreme values ​​from the actual total time is taken as the baseline average response time.

[0031] In a pre-set test environment on an isolated gigabit LAN, a multi-threaded load testing component is used to initiate, for example, 200 to 500 concurrent communication connection requests to the target monitoring terminal.

[0032] During communication, the millisecond-level time consumed by the TCP three-way handshake is extracted and recorded as handshake overhead using network packet capture tools and system kernel-level timestamp probes. The time required for the security module to perform RSA-2048 verification, ECDSA digital signature verification, HMAC token verification, AES session key processing, or transport layer security protocol handshake is extracted as authentication overhead. The time spent by monitoring the system kernel to allocate communication resources such as socket file descriptors and 16KB socket read / write buffers to the communication process is recorded as initialization overhead.

[0033] Based on this, the arithmetic sum of the three indicators is calculated as the comprehensive overhead, which is configured to be 60ms in this invention. The actual total time of 200 to 500 complete communication round trips is collected, and the top 5% of extremely large outliers and the bottom 5% of extremely small outliers are removed to filter out errors caused by occasional network jitter. The arithmetic mean of the remaining valid samples is calculated to obtain a baseline average response time of 120ms.

[0034] Reference Figure 2 This data displays the time distribution of handshake overhead, authentication overhead, initialization overhead, overall overhead, and average response time for terminal devices. Higher values ​​indicate longer operation times, while lower values ​​indicate shorter operation times. By visually comparing the distribution differences of these overheads, the performance of different terminal devices at various communication stages can be reflected, thus verifying the validity of the performance baseline overhead data.

[0035] The overall overhead, baseline average response time, along with the terminal's MAC address and protocol version number, are hashed and serialized to generate the corresponding device's performance baseline fingerprint, which is then stored in a Redis database or a local time-series database.

[0036] In an optional embodiment, a three-tiered object pool is constructed, dividing instances into an active object queue, a standby object queue, and an isolation diagnostic queue. Specifically, a contiguous address space is pre-allocated in system memory as the storage boundary of the object pool, with a maximum capacity limit set; three pointer arrays are created, pointing to the active object queue, the standby object queue, and the isolation diagnostic queue, respectively; the active object queue stores instances that have recently successfully communicated and whose health assessment value is higher than a first return threshold; the standby object queue stores instances that have completed initialization but are currently idle and whose health assessment value is between the first and second return thresholds; the isolation diagnostic queue stores abnormal instances that have experienced consecutive communication failures or whose health assessment value is lower than the second return threshold.

[0037] During the initialization phase, a logically contiguous controlled storage area is pre-allocated in the process address space or off-heap memory as the storage boundary of the object pool, and the maximum capacity limit for concurrent connections is set, for example, configured as 1024 instances.

[0038] Within the protected memory pool, three reference arrays, index arrays, or pointer arrays are created using concurrency-safe arrays, index tables, or lock-free linked list structures. These arrays point to different levels of active object queues, spare object queues, and isolation diagnostic queues, respectively. This reduces memory fragmentation caused by the creation and destruction of scattered objects and lowers the probability of frequent garbage collection.

[0039] Assuming each instance has an initial health score of 100, a first return threshold of 85, and a second return threshold of 60, if an instance has not experienced any anomalies and its time consumption meets the standard in its most recent communication, its health score after settlement will be 92, which is greater than 85. The memory address pointer of the corresponding instance will then be pushed onto the head of the active object queue for rapid reuse.

[0040] If an instance experiences occasional packet loss leading to a minor timeout and its health score drops to 75 (between 60 and 85), it will be allocated to the standby object queue as a buffer resource during high concurrency. If an instance experiences privilege escalation or three consecutive communication connection drops, causing its health score to fall below 45 (below 60), the abnormal instance will be immediately transferred to the isolation diagnostic queue. A background daemon thread will periodically send heartbeat Ping probe commands (e.g., at 5-second intervals) to the abnormal instance to perform resource resets and link repairs.

[0041] S2, Calculate the decision score and assign it to an object instance.

[0042] In an optional embodiment, when receiving an instruction, an instance is requested from the three-tier object pool. Priority is given to allocating instances in the active object queue according to their health assessment values ​​from high to low. If the queue is empty, instances are allocated in the standby object queue. If both queues are empty, it is determined whether an instance has already been allocated. If not, a new instance is created by the abstract factory within the object pool capacity constraint. If an instance exists, a creation decision score is calculated based on the overall overhead, system load factor, and pool degradation degree. If the creation decision score is lower than a preset creation threshold, a new instance is created by the abstract factory within the object pool capacity constraint; otherwise, it waits.

[0043] After receiving control commands from the front end through the event loop group, the controller calls the instance request method of the object pool management class. A priority blocking queue is used to maintain the active object queue, and a custom comparator sorts the instances according to their health assessment values ​​from highest to lowest. When allocating instances, the highest-healthy instance at the head of the queue is retrieved first, and then assigned to the business thread corresponding to the current command to execute the communication task.

[0044] If the pop method of the active object queue returns null, the same pop allocation operation is performed on the standby object queue based on the same data structure. If both queues are empty, the counter of the number of currently borrowed allocated instances recorded by the atomic integer class is read. If the counter value is 0, the object creation method of the abstract factory is called to instantiate a new network connection object within the object pool capacity constraint. The abstract factory is a unified interface used to encapsulate the creation process of communication instances for different monitoring terminals. The abstract factory generates connection instances adapted to different communication protocols through corresponding concrete factories. If the counter value is greater than 0, the system load factor is obtained by calculating the ratio of the counter value to the maximum capacity constant, and the pool degradation degree is obtained by calculating the ratio of the current number of elements in the isolation diagnostic queue to the maximum capacity constant.

[0045] A weighted summation algorithm is used to divide the total overhead read from the in-memory database by a preset maximum tolerable overhead threshold to obtain the overhead factor. The overhead factor, system load factor, and pool degradation degree are then multiplied by pre-determined normalized weight coefficients using empirical tuning, and summed to obtain the creation decision score. The creation decision score is compared to the system's preset creation threshold. If the creation decision score is lower than the preset threshold, new connection instance objects are created, provided that the maximum capacity of the object pool is not exceeded. If the creation decision score is greater than or equal to the preset creation threshold, a blocking queue, semaphore, or condition variable is invoked to put the current worker thread into a waiting state until it receives a wake-up signal from another thread returning the instance.

[0046] In an optional embodiment, a creation decision score is calculated based on overall overhead, system load factor, and pool degradation degree. Specifically, the overall overhead is normalized by dividing it by a preset maximum tolerable overhead threshold to obtain the overhead factor; the ratio of allocated instances to the maximum capacity is calculated to obtain the system load factor; the ratio of instances in the isolation diagnostic queue to the maximum capacity limit is calculated to obtain the pool degradation degree; the overhead factor, system load factor, and pool degradation degree are multiplied by preset weighting coefficients and then weighted and summed to obtain the creation decision score.

[0047] Based on the device performance baseline fingerprint, the collected comprehensive overhead is divided by a preset maximum tolerable overhead threshold for normalization mapping. For example, if the comprehensive overhead of a certain protocol handshake and authentication on the current device is 150ms, and the maximum tolerable overhead threshold is set to 500ms, the calculated overhead factor is 0.3, indicating that the basic connection establishment cost is at a low to medium level.

[0048] The system load factor and pool degradation degree are obtained by reading the current object pool running status data. Assuming the maximum configuration capacity is 1000 connection instances, and 750 instances are currently executing business logic in various monitoring threads, the calculated system load factor is 0.75. Simultaneously, 50 instances that have failed due to anomalies are found in the isolation diagnostic queue, resulting in a pool degradation degree of 0.05, indicating that the current connection pool is experiencing resource degradation.

[0049] A set of weighted coefficients determined through empirical tuning is preset, for example, the overhead factor weight is configured as 0.2, the system load factor weight is configured as 0.6, and the pool degradation weight is configured as 0.2. The creation decision score is obtained using a weighted summation method. The calculated creation decision score is compared with a system preset creation threshold of, for example, 0.6. Since the calculated score of 0.52 is lower than 0.6, it is determined that the performance consumption and capacity expansion caused by creating new instances are still within a controllable range. The instruction abstract factory executes the creation within the maximum capacity constraint of the object pool and allocates resources to the new connection instance. Conversely, if the decision score reaches or exceeds the preset threshold, such as 0.8, it is determined to be in an overload risk zone, causing the current request to enter a spin or blocking queue to wait.

[0050] S3. Generate a session summary to update health and return the instance.

[0051] In an optional embodiment, the instance communicates with the monitoring terminal and generates a session summary containing the actual total time, error type, number of occurrences, and status code. Based on the session summary, referring to the weight matrix that maps status codes and error types to penalty factors, and combining the deviation of the actual total time from the baseline average response time, the instance's health assessment value is updated. When returning the instance, based on the comparison between the health assessment value and the first and second return thresholds adjusted based on the system load factor, the instance is placed in the active object queue, the standby object queue, or the isolation diagnostic queue, respectively.

[0052] The business thread uses the allocated instance object to call the socket's output stream to write the instruction byte stream and reads telemetry data from the power supply box sensor through the input stream. An exception detection code block is nested outside the communication execution method, using a timer component to record the absolute time difference from sending the instruction to receiving it as the actual total timeout. In the exception handling branch, an accumulator variable is used to count the number of network timeout exceptions or connection refusal exceptions, and Java reflection is used to obtain the fully qualified name string of the thrown exception class as the error type. Bitwise operations are used to extract the hexadecimal return code from the application layer protocol response header as the status code, and the status code, error type, and actual total timeout parameter are encapsulated and initialized into a session digest entity class object.

[0053] A weight matrix implemented using a two-dimensional hash table data structure is pre-loaded in memory, with status codes as row keys and error types as column keys. Each cell stores a floating-point penalty factor determined by the analytic hierarchy process (AHP). A hash table key-value matching query algorithm is used to extract the penalty factor for the current session from the weight matrix. A one-sided deviation calculation method is then used to calculate the time deviation of the actual total response time relative to the baseline average response time. When the actual total response time is greater than the baseline average response time, a positive deviation ratio is calculated; when the actual total response time is less than or equal to the baseline average response time, the time deviation is recorded as 0.

[0054] The assignment operation is performed, calculating the total penalty value based on the session digest, and calculating the time decay amount based on the time deviation and the preset time decay coefficient. When there are no errors and the time deviation is 0, a health recovery amount is generated based on the preset recovery coefficient. When there are errors or the time deviation is greater than 0, the health recovery amount is recorded as 0. Finally, the original health assessment value of the instance is added to the health recovery amount, and the total penalty value and the time decay amount are subtracted to obtain the updated health assessment value. The real-time system load factor is calculated statistically on a second-level time slice using a sliding window algorithm. A piecewise linear adjustment function is used to calculate the first and second return thresholds, so that the threshold is reduced when the system is under high load and increased or restored to the basic threshold range when the system is under low load.

[0055] When the updated health assessment value is greater than or equal to the first return threshold, the enqueue method of the active object queue is invoked to return the allocated instance. When the updated health assessment value is less than the first return threshold but greater than or equal to the second return threshold, the enqueue method of the standby object queue is invoked to return the allocated instance. When the updated health assessment value is less than the second return threshold, a warning log is triggered, and the enqueue method of the isolation diagnostic queue is invoked to isolate the abnormal instance, waiting for the background daemon thread to perform heartbeat detection and connection reset repair actions based on a finite state machine model.

[0056] In an optional embodiment, the error types include data frame verification failure, message length mismatch, communication timeout loss, and unauthorized instruction; for each error type, an initial penalty factor is assigned in the weight matrix, and the penalty factor increases exponentially with the cumulative number of occurrences of the same type of error in multiple consecutive communications.

[0057] The underlying protocol parser maintains a two-dimensional weight matrix for various anomalies, explicitly enumerating and covering four core error types: data frame verification failure, message length mismatch, communication timeout loss, and unauthorized instruction. Data frame verification failure includes, for example, an incorrect CRC16 checksum; message length mismatch includes, for example, the received byte stream length being shorter than the Length field specified in the protocol header; communication timeout loss includes, for example, waiting for TCP-ACK exceeding 1000ms; and unauthorized instruction includes, for example, an illegal attempt to write to a read-only register address.

[0058] The weight matrix assigns an initial penalty factor base to the core error types. For example, a verification failure initially deducts 5 points, a length mismatch deducts 8 points, and a timeout loss deducts 3 points. Unauthorized instructions involving security breaches deduct 20 points, measuring the impact of different faults. Simultaneously, for persistent communication quality degradation caused by network instability or hardware aging, a penalty calculation mechanism is used where the cumulative occurrence of the same type of error in multiple consecutive communications increases exponentially. An increment base is set, for example, configured as 1.5 or 2. The total penalty for a specific type of error is calculated as the initial penalty factor multiplied by the exponent of the increment base, where the exponent is the cumulative occurrence count minus 1. For example, with a base of 2, if an instance throws a low-level exception of message length mismatch three times consecutively within a communication cycle, the first time the cumulative occurrence count is 1, and the penalty is 8 points; the second time the cumulative occurrence count is 2, triggering the penalty mechanism, and the penalty is 16 points; the third time the cumulative occurrence count is 3, and the penalty reaches 32 points. The health of instances with loose lines or hardware failures causing continuous communication degradation is rapidly reduced in a short period of time through an exponentially increasing mechanism, causing them to fall below the safe return threshold and be removed from the main business flow.

[0059] In an optional embodiment, the instance's health assessment value is updated based on the deviation between the actual total response time and the baseline average response time. Specifically, the difference between the actual total time of this communication and the baseline average response time is calculated. If the difference is positive, it is divided by the baseline average response time to obtain the time deviation. If the difference is not positive, the time deviation is recorded as 0. The penalty factor corresponding to the status code and error type in the session summary is retrieved from the weight matrix, and the penalty factors are summed to obtain the total penalty value. The health recovery amount is determined based on the total penalty value and the time deviation. When the total penalty value is 0 and the time deviation is 0, a positive health recovery amount is generated based on the preset recovery coefficient. When the total penalty value is greater than 0 or the time deviation is greater than 0, the health recovery amount is recorded as 0. The time decay amount is generated based on the time deviation and the preset time decay coefficient. The health assessment value before instance return is added to the health recovery amount, and the total penalty value and the time decay amount are subtracted to obtain the updated health assessment value. If the updated health assessment value is less than 0, it is corrected to 0. If the updated health assessment value is greater than the preset health upper limit, it is corrected to the health upper limit.

[0060] Obtain the actual total latency of this communication, for example, 300ms. Retrieve the previously measured baseline average response time for the corresponding type of terminal device, for example, 200ms. Calculate the difference between the actual total latency and the baseline average response time as +100ms. Divide 100ms by the baseline value of 200ms to obtain a time deviation coefficient of 0.5. If the actual total latency is 150ms, less than 200ms, it indicates smooth network operation, the difference is negative, and the time deviation is recorded as 0.

[0061] Meanwhile, the underlying protocol parser extracts specific error types and status codes from the archived session digests. If it encounters a service unavailable status code, protocol exception code, or abnormal message length returned by the device, it retrieves the penalty factors corresponding to all errors that occurred in this communication based on the weight matrix and sums them up. If a specific protocol parsing exception and a minor privilege escalation are found, the total penalty value for both is 25 points, which is the total penalty value.

[0062] Set a time decay constant to adjust the time consumption weight, for example, configure the scaling factor K to be 10. Multiply the previously calculated time deviation of 0.5 by the scaling factor K to obtain a decay amount of 5 points. If the historical health assessment value of the instance being evaluated before the last repayment was 95 points, and the total penalty value this time is 25 points, then the score of the new calculation process will be... Points. Since multiple penalties under continuous failure conditions may result in negative values, clamping logic is set up. If the health score of an abnormal instance is calculated to be -15 points after cumulative penalties, the health score will be corrected to 0. Conversely, if a specific instance communicates normally without any errors and the time taken is lower than or equal to the baseline, a health score recovery amount can be generated according to a preset recovery coefficient, for example, the health score can be restored from 98 points to 102 points. At this time, the clamping logic is used to limit the health score to the preset upper limit of 100 points to ensure that the health score is within the standardized closed interval of 0 to 100.

[0063] In an optional embodiment, the first and second return thresholds are adjusted based on the system load factor. Specifically, the system load factor of the three-tier object pool is monitored in real time. When the system load factor is greater than a set high load threshold, the first and second return thresholds are lowered; when the system load factor is less than a set low load threshold, the first and second return thresholds are raised. During the adjustment process, a preset anti-inversion constraint mechanism is used to ensure that the first return threshold is always greater than the second return threshold.

[0064] Set a high-load threshold, for example, 0.85, and a low-load threshold, for example, 0.30. Initially, set the first return threshold to 80 points and the second return threshold to 60 points. When a sudden surge in business activity or a batch of device alarms are reported, if the system load factor is detected to rise to 0.92, which is greater than 0.85, the controller triggers a reduction logic, lowering the first return threshold to 70 points and simultaneously reducing the second return threshold to 50 points. This lenient threshold reduction allows slightly unhealthy instances that experience minor timeouts or occasional packet loss but still maintain basic communication capabilities to continue participating in scheduling as optional resources during high-load phases, reducing the risk of frequent connection rebuilds.

[0065] Conversely, during the low-frequency off-peak hours at night, the system load factor drops to 0.25, which is less than the low-load threshold of 0.30, indicating that system resources are relatively sufficient. At this time, the controller initiates tightening logic, raising the first return threshold to 90 points and the second return threshold to 75 points. The high thresholds of the first and second return thresholds make it easier for instances with poor health to be transferred to the isolation diagnostic queue, where they are reset, destroyed, or reclaimed to optimize the quality of the object pool.

[0066] Furthermore, all adjustment operations are bound to anti-inversion constraint mathematical mechanisms at the code level. For example, the first and second return thresholds must maintain a buffer of at least 15 points. If, under a specific adjustment formula, the first return threshold is reduced to 55 points, while the second return threshold should remain at 50 points, the constraint mechanism will intervene and simultaneously reduce the second return threshold to 40 points. This ensures that the first return threshold is always logically greater than the second return threshold, preventing uncertainty in instance classification logic or abnormal state transitions due to overlapping threshold intervals.

[0067] Reference Figure 3 The results show that the first and second return thresholds decrease as the system load factor increases. Observing the interval between these two thresholds reveals that the anti-inversion mechanism ensures that the first return threshold is always above the second return threshold, maintaining a reasonable buffer zone.

[0068] System-level experimental testing was conducted on the object pooling mechanism. The experimental conditions involved deploying 1000 simulated monitoring terminal devices in a gigabit LAN environment, continuously initiating 5000 concurrent communication connection requests per second for a test period of 72 hours. The hardware platform used a server with a 64-core processor and 128GB of memory. Three comparison groups were set up: the basic group used a traditional single-layer communication connection pool; the ablation group used a three-layer object pool with a fixed return threshold; and the complete group used a three-layer object pool with a return threshold adjusted based on the system load factor.

[0069] After 72 hours of operation, the base group achieved an average communication success rate of 84.2%, with a peak processor utilization of 96% due to frequent connection creation and destruction, and an average response time of 245ms. The ablation group improved its average communication success rate to 92.5%, reduced its peak processor utilization to 79%, and shortened its average response time to 160ms. The full group performed better under these test conditions, achieving an average communication success rate of 99.1%, keeping peak processor utilization below 63%, reducing the average response time to 105ms, and increasing overall system throughput by 1.8 times compared to the base group.

[0070] Reference Figure 4 The results demonstrate the performance of different object pooling mechanisms in terms of average communication success rate, peak processor utilization, and average response time. A comparison of the basic, ablation, and complete groups shows that the three-tiered object pooling mechanism, by distinguishing between active, standby, and abnormal instances, prioritizes the reuse of healthy connections and promptly isolates failed connections, helping to reduce invalid retries, frequent instance creation and destruction, and excessive computing resources. The further improvement of the complete group compared to the ablation group indicates that the threshold adjustment mechanism based on system load factors can effectively smooth out peak and valley loads to some extent. During high-concurrency phases, it appropriately retains sub-healthy instances with basic communication capabilities, reducing the risk of connection reconstruction storms, and increases the return threshold during low-load idle periods, accelerating the elimination of inferior instances and improving system availability, response stability, and resource utilization efficiency in high-concurrency environments.

[0071] This invention also discloses a remote monitoring system for rapid power supply box repair, including a processor and a memory. The memory stores computer program instructions, and when the computer program instructions are executed by the processor, a remote monitoring method for rapid power supply box repair according to the present invention is implemented.

[0072] The system also includes other components well known to those skilled in the art, such as communication buses and communication interfaces, the settings and functions of which are known in the art and will not be described in detail here.

[0073] It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept, and these all fall within the scope of protection of this invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for rapid inspection and remote monitoring of power supply boxes, characterized in that, include: S1. Set up an abstract factory to generate and store a device performance baseline fingerprint for different monitoring terminals, including the comprehensive overhead of handshake overhead, authentication overhead, and initialization overhead, as well as the baseline average response time. S1. Construct a three-tiered object pool divided into an active object queue, a standby object queue, and an isolation diagnostic queue, and assign an initial health assessment value to new instances; S2. When receiving instructions, prioritize allocating instances in the active object queue according to the health assessment value from high to low. If the queue is empty, allocate instances in the standby object queue; if both are empty and there are no allocated instances, create new instances by the abstract factory within the capacity constraint; if there are already allocated instances, obtain the system load factor and pool degradation degree, calculate the creation decision score based on the comprehensive overhead, the system load factor, and the pool degradation degree. If the score is lower than the preset creation threshold, create new instances by the abstract factory; otherwise, wait; S3. After communication is completed, generate a session summary containing the actual total time, error type, number of occurrences, and status code; Referring to the weight matrix that maps status codes and error types to penalty factors, and combining the deviation between the actual total time consumption and the baseline average response time, the health assessment value of the instance is updated; based on the comparison result between the health assessment value and the first return threshold and the second return threshold adjusted based on the system load factor, the instance is placed in the active object queue, the standby object queue, or the isolation diagnostic queue.

2. The method for rapid maintenance and remote monitoring of a power supply box according to claim 1, characterized in that, The abstract factory is set up to generate and store a device performance baseline fingerprint for different monitoring terminals, including a comprehensive overhead of handshake overhead, authentication overhead, and initialization overhead, as well as a benchmark average response time. This includes: in a preset test environment, initiating multiple concurrent communication connection requests to the target monitoring terminal; collecting the network socket establishment time as handshake overhead, the time for the security module to parse the digital signature credential as authentication overhead, the time for the operating system to allocate memory and port resources to the communication process as initialization overhead, and collecting the actual total time consumption of each communication connection; summing the three overheads to obtain the comprehensive overhead, and taking the average value after removing extreme values ​​from the actual total time consumption as the benchmark average response time.

3. The method for rapid maintenance and remote monitoring of a power supply box according to claim 1, characterized in that, The construction of a three-tiered object pool, consisting of an active object queue, a standby object queue, and an isolation diagnostic queue, includes: pre-allocating a contiguous address space in system memory as the storage boundary of the object pool and setting a maximum capacity limit; establishing three pointer arrays pointing to the active object queue, the standby object queue, and the isolation diagnostic queue, respectively; the active object queue stores instances that have recently successfully communicated and whose health assessment value is higher than the first return threshold; the standby object queue stores instances that have completed initialization but are currently idle and whose health assessment value is between the first return threshold and the second return threshold; and the isolation diagnostic queue stores abnormal instances that have experienced consecutive communication failures or whose health assessment value is lower than the second return threshold.

4. The method for rapid maintenance and remote monitoring of a power supply box according to claim 3, characterized in that, The step of calculating the creation decision score based on the overall overhead, the system load factor, and the pool degradation degree includes: normalizing the overall overhead by dividing it by a preset maximum tolerable overhead threshold to obtain the overhead factor; calculating the ratio of allocated instances to the maximum capacity limit to obtain the system load factor; calculating the ratio of instances in the isolation diagnostic queue to the maximum capacity limit to obtain the pool degradation degree; and multiplying the overhead factor, system load factor, and pool degradation degree by preset weighting coefficients and then performing a weighted sum to obtain the creation decision score.

5. The method for rapid maintenance and remote monitoring of a power supply box according to claim 1, characterized in that, The error types include: data frame verification failure, message length mismatch, communication timeout loss, and unauthorized instruction; for each error type, an initial penalty factor is assigned in the weight matrix, and the penalty factor increases exponentially with the cumulative number of occurrences of the same type of error in multiple consecutive communications.

6. The method for rapid maintenance and remote monitoring of a power supply box according to claim 1, characterized in that, The step of updating the instance's health assessment value by combining the deviation between the actual total time consumption and the benchmark average response time includes: calculating the difference between the actual total time consumption and the benchmark average response time; if the difference is positive, dividing the difference by the benchmark average response time to obtain the time deviation; if the difference is not positive, recording the time deviation as 0; retrieving the penalty factors corresponding to the status code and error type from the weight matrix and summing them to obtain the total penalty value; generating a positive health recovery amount based on a preset recovery coefficient when both the total penalty value and the time deviation are 0; otherwise, recording the health recovery amount as 0; generating a time decay amount based on the time deviation and a preset time decay coefficient; adding the health recovery amount to the health assessment value before return and subtracting the total penalty value and the time decay amount to obtain the updated health assessment value, and limiting it to between 0 and a preset health upper limit value through clamping logic.

7. The method for rapid maintenance and remote monitoring of a power supply box according to claim 1, characterized in that, The adjustment of the first return threshold and the second return threshold based on the system load factor includes: real-time monitoring of the system load factor of the three-level object pool; when the system load factor is greater than a set high load threshold, reducing the first return threshold and the second return threshold; when the system load factor is less than a set low load threshold, increasing the first return threshold and the second return threshold; during the adjustment process, a preset anti-inversion constraint mechanism is used to ensure that the first return threshold is always greater than the second return threshold.

8. The method for rapid maintenance and remote monitoring of a power supply box according to claim 1, characterized in that, The abstract factory setting includes: defining an abstract factory interface for the power supply box monitoring device, and deriving specific factory classes that adapt to different communication protocols; wherein, the different communication protocols include at least one of Modbus protocol, MQTT protocol and SNMP protocol.

9. The method for rapid maintenance and remote monitoring of a power supply box according to claim 1, characterized in that, The method of prioritizing the allocation of instances in the active object queue according to their health assessment values ​​from high to low includes: maintaining the active object queue using a priority blocking queue and sorting the instances according to their health assessment values ​​from high to low; when allocating instances, retrieving the instance at the head of the active object queue and assigning it to the business thread corresponding to the current instruction to perform a communication task.

10. A remote monitoring system for rapid repair of power supply boxes, characterized in that, include: A processor and a memory, wherein the memory stores computer program instructions that, when executed by the processor, implement a method for rapid maintenance of a power supply box remote monitoring as described in any one of claims 1-9.

Images