Intelligent identification method and device for idle state of rack

Abstract

The invention discloses an intelligent identification method and device for the idle state of a rack. The method comprises the steps of collecting performance index data and user operation behavior event data of an upper computer of a target rack; preprocessing the performance index data and the user operation behavior event data to form structured state sequence data; periodically uploading the state sequence data to a central server; and the central server identifies the state sequence data based on a preset composite judgment rule so as to judge whether the target rack is in an idle state at present. According to the invention, intelligent identification is carried out through the central server based on the preset composite judgment rule, and comprehensive research and judgment are carried out in combination with multi-dimensional data, so that the accuracy of judgment of the idle state of the rack is greatly improved, and the industrial pain points of opaque real-time occupation condition of the rack and difficult resource scheduling in a remote test mode are effectively solved; therefore, the dynamic management and efficient distribution of rack resources are optimized, the idle time of equipment is reduced, and the resource utilization rate and the test service production efficiency are improved.

Description

Technical Field

[0001] This invention belongs to the field of industrial automation testing technology, and more specifically, relates to an intelligent identification method and device for the idle state of a test bench. Background Technology

[0002] In high-end R&D fields such as automotive electronics, aerospace, and industrial control, hardware-in-the-loop (HIL) simulation benches are indispensable core equipment for controller verification, functional safety testing, and system integration. With the increasing complexity of testing tasks and the development of remote and automated testing modes, testing departments typically manage numerous bench resources of varying models. How to efficiently and accurately manage and schedule these expensive and limited testing resources to ensure maximum utilization has become a key challenge faced by the industry.

[0003] Currently, the industry mainly relies on the following methods to monitor and manage the status of rack resources: 1. Manual Registration and Coordination: Test engineers manually register the usage time and purpose of the test benches using paper forms or shared spreadsheets. This method relies on the conscientiousness of the staff and timely communication. During temporary adjustments, sudden tasks, or personnel handovers, it is easy for information to be out of sync, registration to be missed, or test benches to be occupied without authorization, resulting in resource allocation conflicts and a large amount of idle time.

[0004] 2. Simple monitoring based on network connectivity: Some systems roughly determine their "availability" by periodically performing network heartbeats (Ping) or checking whether the host computer on the test bench is online. However, this method has a significant drawback: it can only determine whether the device is powered on and connected to the network, but cannot distinguish whether the device is undergoing intensive testing or is merely in a "pseudo-occupancy" state where it is powered on but not used. For example, an engineer may lock the screen and leave, or the test bench may be executing a background automation script without human intervention. In this case, the network heartbeat may appear normal, but the resources can actually be rescheduled.

[0005] 3. Monitoring based on a single system metric: Some improvement solutions monitor the CPU or memory utilization of the host computer. However, when the test task load is light, or the test software is idle and waiting for input, the system resource utilization may be very low. Relying solely on this metric may misjudge the test bench as idle, thereby interrupting any ongoing silent tests or data logging tasks.

[0006] 4. Physical monitoring and access control systems: These systems use cameras or card readers to determine if someone is present. This approach is completely inadequate for the increasingly common remote testing methods. Engineers can access the test bench from any location via Remote Desktop Protocol (RDP), rendering physical monitoring methods completely ineffective in this scenario.

[0007] In summary, the main shortcomings of existing technical solutions lie in their lack of refined and highly reliable perception of the "true occupancy status" of the equipment. They may fail to reflect remote operations, distinguish between user activities and system background processes, or correlate user behavior (login, interaction) with system resource consumption. This "blind spot" in status perception directly leads to problems such as insufficient basis for resource scheduling decisions, low equipment utilization, resource contention between projects, and high management costs.

[0008] Therefore, there is an urgent need for an intelligent monitoring solution that can adapt to remote and automated testing environments and accurately and in real time determine whether the test bench is effectively occupied by integrating multiple information sources, in order to fill the aforementioned technological gap. Summary of the Invention

[0009] The purpose of this invention is to propose an intelligent identification method and device for bench idle status, which solves the technical problem that existing technologies cannot accurately and in real time determine the actual occupancy status of benches in remote and automated testing environments due to reliance on a single data source. This enables visualized monitoring and intelligent scheduling of bench resources, significantly improving the accuracy of bench status monitoring and the efficiency of dynamic resource scheduling.

[0010] To achieve the above objectives, in a first aspect, the present invention proposes an intelligent identification method for the idle state of a test bench, comprising: Collect performance index data and user operation behavior event data from the target test bench's host computer. The performance index data and user operation behavior event data are preprocessed to form structured state sequence data; The state sequence data is periodically uploaded to the central server; The central server identifies the state sequence data based on preset composite judgment rules to determine whether the target rack is currently in an idle state.

[0011] Optionally, the performance metrics data include: CPU utilization and memory utilization; The user action event data includes: User login, user logout, session locking, session unlocking, and remote desktop connection events.

[0012] Optionally, the step of identifying the status data packet based on a preset composite determination rule to determine whether the target platform is currently in an idle state includes: S401. Determine whether the state sequence data meets the first set condition. If yes, determine that the target platform is currently in an idle state. If no, execute S402. S402. Determine whether the state sequence data meets the second set condition. If yes, determine that the target platform is currently in an idle state. If no, execute S403. S403. Perform a weighted calculation on the state sequence data to obtain a comprehensive state score; S404. Determine whether the comprehensive status score is greater than a preset discrimination threshold. If yes, determine that the target platform is currently in an idle state; otherwise, determine that the target platform is currently in an occupied state.

[0013] Optionally, the first setting condition includes: The idle time in the state sequence data since the last captured valid user operation event exceeds a first set time threshold. And the CPU utilization rate is lower than the first threshold; Furthermore, the memory utilization rate is lower than the second threshold.

[0014] Optionally, the second setting condition includes: The state sequence data contains no user operation events within a second set time threshold.

[0015] Optionally, the weighted calculation of the state sequence data to obtain the comprehensive state value includes: Calculate the operation idleness score based on the idle duration; Calculate the resource load score based on the CPU utilization and memory utilization; The event activity score is calculated based on the number of user operation behavior event data within the second set duration threshold. The comprehensive status score is obtained by multiplying the operation idleness score, resource load score and event activity score by their respective preset weight coefficients and then summing them.

[0016] Optionally, it also includes: The central server retrieves historical state sequence data of the target test bench for trend analysis, which is used to verify or correct the current judgment result.

[0017] Optionally, it also includes: The state sequence data is periodically uploaded to the central server using a digital signature-based encrypted heartbeat message mechanism. If no heartbeat message is received from the target test station for a set number of consecutive times, the target test station is determined to be in an abnormal state.

[0018] Optionally, the central server displays the current status of the target platform through a dynamic visualization interface, distinguishing them with different colors.

[0019] Optionally, the second set duration threshold is greater than the first set duration threshold.

[0020] Optionally, the first set duration threshold is 4 minutes, the second set duration threshold is 10 minutes, the first threshold is 10%, and the second threshold is 15%.

[0021] Optionally, the preset weighting coefficients for the operation idleness score, resource load score, and event activity score are 40%, 30%, and 30%, respectively.

[0022] Secondly, the present invention proposes an intelligent identification device for the idle state of a test bench, comprising: The monitoring terminal is used to collect performance index data and user operation behavior event data from the target test bench's host computer; preprocess the performance index data and user operation behavior event data to form structured state sequence data; and periodically upload the state sequence data to the central server. A central server is used to identify the state sequence data based on preset composite judgment rules in order to determine whether the target rack is currently in an idle state.

[0023] The beneficial effects of this invention are as follows: By collecting performance index data and user operation behavior event data from the target test bench's host computer, the operating status of the test bench and the user's operation trajectory are comprehensively captured, providing multi-dimensional data support for idle status judgment and avoiding misjudgment problems caused by a single data dimension; by preprocessing the two types of data to form structured status sequence data, the standardization and normalization of the data are achieved, improving the efficiency and accuracy of subsequent data identification; by periodically uploading status sequence data, the central server can obtain the latest status information of the test bench in real time, ensuring the real-time and continuous monitoring; by the central server performing intelligent identification based on preset composite judgment rules and combining multi-dimensional data for comprehensive judgment, the accuracy of test bench idle status judgment is greatly improved, effectively solving the industry pain points of opaque real-time occupancy status and difficult resource scheduling in remote testing mode, thereby optimizing the dynamic management and efficient allocation of test bench resources, reducing equipment idle time, improving resource utilization and test business production efficiency, and providing reliable status basis for multi-user coordinated use of test benches, ensuring the smooth progress of test business.

[0024] The system of the present invention has other features and advantages that will be apparent from or will be set forth in detail in the accompanying drawings and following detailed description, which together serve to explain the particular principles of the invention. Attached Figure Description

[0025] The above and other objects, features and advantages of the present invention will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.

[0026] Figure 1 A flowchart illustrating the steps of an intelligent identification method for bench idle state according to Embodiment 1 of the present invention is shown.

[0027] Figure 2 A flowchart is shown illustrating the steps of identifying status data packets based on a preset composite determination rule according to Embodiment 1 of the present invention to determine whether the target station is currently in an idle state.

[0028] Figure 3 A schematic diagram of an intelligent identification device for bench idle state according to Embodiment 1 of the present invention is shown. Detailed Implementation

[0029] The invention will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0030] Example 1

[0031] like Figure 1 As shown, a smart identification method for the idle state of a test bench according to the present invention includes: S1. Collect performance index data and user operation behavior event data of the target test bench host computer; In this step, the performance metrics data include: CPU utilization and memory utilization; User action event data includes: User login, user logout, session locking, session unlocking, and remote desktop connection events.

[0032] Specifically, the test bench is an integrated hardware-in-the-loop (HIL) simulation and testing platform, consisting of a real-time simulator, a signal conditioning module, a data acquisition system, and a controller under test (ECU / DUT). The platform supports multi-physics domain (electrical, hydraulic, mechanical, etc.) co-simulation and provides high-precision signal excitation and response acquisition, meeting the R&D needs of fields such as autonomous driving, aerospace, and industrial control. The host computer of the test bench is the main control computer, running test management software (such as LabVIEW, dSPACEControlDesk, ETAS INCA, etc.), responsible for test case deployment and execution, controller parameter calibration, real-time data monitoring and fault diagnosis, and test data storage and analysis. The host computer interacts with the test bench via bus protocols such as Ethernet, CAN / CAN FD, and XCP to ensure that the testing process is controllable and observable.

[0033] During the data acquisition phase, a monitoring terminal deployed on the target test bench's host computer simultaneously collects two types of core data to comprehensively capture the test bench's operating status and user operation trajectories. For performance metrics data, the monitoring terminal accesses the Windows performance counters, precisely reading the instantaneous utilization rate of the host computer's central processing unit (CPU) and the current occupancy rate of physical memory (RAM) at a fixed sampling period of once per second, and converting these values ​​into percentage values. Simultaneously, for user operation event data, the monitoring terminal subscribes to predefined event IDs from the Windows Security Event Log Service to achieve real-time capture via event triggering. The subscribed key events include, but are not limited to: event 4624 (indicating successful user login), event 4634 (indicating user logout), event 4800 (indicating session lockout), event 4801 (indicating session unlocking), event 21 (indicating the establishment of a remote desktop connection), and event 24 (indicating disconnection). Once these events occur in the operating system kernel, the monitoring terminal receives structured log entries containing detailed information such as event type, occurrence time, and associated user in near real-time. Thus, the continuous quantitative indicators from the system resource level and the discrete event logs from the user interaction level together constitute the original multimodal data stream for subsequent fusion analysis and status judgment.

[0034] S2. Preprocess the performance index data and user operation behavior event data to form structured state sequence data; Specifically, after obtaining the raw performance metric stream and discrete user operation events in the data acquisition step, the monitoring terminal immediately performs preprocessing to transform the raw data into clean, stable, and structured state sequence data. The core of the preprocessing is accomplished collaboratively by two key algorithms: First, the average value filtering algorithm is applied to continuously sampled performance metrics data. The system maintains a configurable sliding time window (e.g., 5 seconds wide). For data points such as CPU utilization and memory usage arriving per second, the algorithm calculates the arithmetic mean of all data points within the window in real time, and uses this average as the smoothed output value of the metric at the current moment. This method effectively filters out transient spikes and jitters caused by instantaneous operating system scheduling, minor process interference, or measurement noise, thereby extracting signals that more realistically and stably reflect the changing trends of system resource load.

[0035] Secondly, outlier removal algorithms work in parallel to identify and exclude obviously unreasonable or potentially data-extrema points that may be caused by acquisition malfunctions. These algorithms are typically based on statistical rules or predefined physical thresholds. For example, for CPU utilization, the system might set a reasonable upper limit (e.g., 100%), and any readings exceeding this value or being negative would be considered invalid. More sophisticated methods might employ dynamic thresholds, such as calculating the standard deviation of the data within a sliding window, marking data points that significantly deviate from the mean (e.g., more than 3 standard deviations) as outliers and removing them. Removed data points are not included in the mean calculation; their values ​​are typically replaced by the previous valid value or an interpolation result to ensure the continuity of the data stream.

[0036] Through the aforementioned collaborative processing, the raw performance data, which might have contained noise and outliers, is transformed into a smooth and reliable time-series sequence. Simultaneously, user operation event data is parsed, accurately timestamped, and converted to a standard format. Finally, the system aligns and encapsulates the smoothed performance indicator sequence and the standardized event list along a unified timeline, forming a high-quality structured state sequence data packet for subsequent transmission and analysis. This preprocessing step is fundamental to the entire judgment process, and its quality directly determines the accuracy of subsequent state identification.

[0037] S3. Periodically upload the state sequence data to the central server; Specifically, the monitoring terminals deployed on each rack of host computers maintain a long-term connection with the central server via encrypted TCP / IP protocol to achieve real-time data status synchronization. Security measures such as TLS 1.3 mutual authentication, HMAC verification, and code signing ensure the integrity and confidentiality of communication and data transmission.

[0038] The monitoring terminal encapsulates the pre-processed structured state sequence data into standard network packets according to a preset fixed heartbeat cycle (e.g., 60 seconds) and uploads them to the central server. At the beginning of each transmission cycle, the agent constructs a data packet containing the following core fields: a unique identifier for the rack, used to accurately distinguish the data source on the server side; a timestamp of the data packet generation, marking the cutoff time of the state sequence; a summary of aggregated performance metrics, such as average CPU utilization, average memory usage, and their peak values ​​within the window period; and a list of all user operation events captured within that cycle, arranged in chronological order. To ensure the security and data integrity of the transmission process, the data packet is encrypted using a transport layer security protocol before being sent and an authentication code based on a hash algorithm is attached. Subsequently, the monitoring terminal sends the data packet to the designated access endpoint of the central server via a reliable network protocol. After verifying the integrity and decrypting the data packet, the receiving service on the central server persistently stores the time-series data in a dedicated time-series database and simultaneously triggers the real-time analysis engine to perform subsequent state judgments. This periodic upload mechanism ensures the continuity of monitoring data while also enabling implicit monitoring of the agent's own liveness status through a heartbeat mechanism.

[0039] S4. The central server identifies the status sequence data based on preset composite judgment rules to determine whether the target rack is currently in an idle state.

[0040] like Figure 2 As shown, in this step, the status data packet is identified based on a preset composite judgment rule to determine whether the target station is currently in an idle state, including: S401. Determine whether the state sequence data meets the first set condition. If yes, determine that the target platform is currently in an idle state. If no, execute S402. In this step, the first set conditions include: The idle time in the state sequence data since the last captured valid user operation event exceeds a first set time threshold; And the CPU utilization is below the first threshold; Furthermore, memory utilization is below the second threshold.

[0041] Specifically, after the central server receives and parses the structured state sequence data from the target rack, its embedded rule engine first executes the core judgment logic, that is, checks whether the data simultaneously meets the first set condition consisting of three key sub-conditions. The first sub-condition of the first set condition is an operation idle time check: the rule engine extracts the timestamp of the most recently identified "valid" user operation event (such as a successful login, unlock, or remote desktop connection event) from the data packet and compares it with the current server system time. If the calculated time difference continuously exceeds the preset first set time threshold (e.g., 4 minutes), it indicates that there are significant idle signs at the user interaction level. At the same time, the rule engine performs a system resource load check in parallel, that is, verifies whether the average CPU utilization reported in the data packet has dropped below the preset first threshold (e.g., 15%), and whether the average memory utilization is also below the second threshold (e.g., 10%). Only when the above three sub-conditions (operation idle timeout, low CPU load, and low memory load) are logically true simultaneously ("AND" relationship) does the system initially determine that the current state sequence data meets the first set condition. The core of this judgment mechanism is that it eliminates the misjudgment that may be caused by a single indicator. By requiring evidence of both missing user behavior and low system resource consumption to be present simultaneously, it ensures that the identified "idle state" has a higher confidence level. It is more likely to correspond to a scenario where the bench is not actually used for effective testing, rather than just a special phase where the user is temporarily away or the system is running at low load in the background.

[0042] S402. Determine whether the state sequence data meets the second set condition. If yes, determine that the target platform is currently in an idle state. If no, execute S403. In this step, the second set of conditions includes: The state sequence data contains no user operation events within the second set time threshold.

[0043] Specifically, if the state sequence data does not meet the aforementioned requirements of being both idle and having low resource consumption (the first condition), the rule engine will switch to an alternative decision path that focuses more on direct behavioral evidence: checking whether the data meets the second condition. The core design of this condition lies in its exclusive reliance on the temporal characteristics of user action events. The rule engine will retrieve the list of user action events attached to the state sequence data packet and check whether, within a continuous second-set time threshold (e.g., 10 minutes) traced back from the current moment, any user action event records defined by the system as valid interactions are completely absent from this list. These events typically include user login, logout, session locking, session unlocking, and remote desktop connection. In other words, this decision logic does not focus on specific CPU or memory values, but only on a more fundamental phenomenon: within a sufficiently long time window, no direct or indirect user interaction signals are captured by the system. Once this condition is met, even if the system resource utilization does not drop below the threshold of the first condition due to background processes or other factors, the rule engine will determine that the target rack is currently in an "idle" state. This design reflects the hierarchy and robustness of the judgment strategy. It recognizes that in certain special scenarios (such as background services that continuously consume resources or test software that has not completely exited), resource indicators may not accurately reflect the true intention to occupy resources. In this case, the lack of user behavior for a long period of time becomes a stronger evidence of idleness, ensuring the system's judgment coverage capability in complex environments.

[0044] S403. Perform weighted calculations on the state sequence data to obtain a comprehensive state score; In this step, the state sequence data is weighted and calculated to obtain the comprehensive state value, which includes: Calculate the operation idleness score based on idle time; Calculate resource load score based on CPU utilization and memory utilization; The event activity score is calculated based on the number of user action event data within a second set time threshold. The overall status score is obtained by multiplying the operation idleness score, resource load score, and event activity score by their respective preset weight coefficients and then summing them.

[0045] Specifically, if neither of the aforementioned two direct judgments based on explicit thresholds holds true, the rule engine will initiate a more refined weighted calculation process to address complex scenarios in critical or ambiguous states. This process first performs multi-dimensional quantitative analysis of the state sequence data: the idle time score is calculated using a function associated with a preset first set duration threshold; generally, the closer the idle time is to or exceeds this threshold, the higher the score. The resource load score is calculated comprehensively based on the levels of CPU utilization and memory utilization relative to their respective thresholds. For example, linear or non-linear functions can be used to transform the degree of "CPU utilization below the first threshold" and "memory utilization below the second threshold" into a unified low load score; the lower the resource utilization, the higher the score. The event activity score is calculated based on the number of valid user operation events captured within a second set duration threshold; the fewer the events, the higher the score, indicating low user interaction activity. Subsequently, the system substitutes these three scores, representing different dimensions of the status—operation idleness score (A), resource load score (B), and event activity score (C)—into a weighted summation formula: Overall Status Score = A * Wa + B * Wb + C * Wc. Here, Wa, Wb, and Wc are pre-configured and dynamically adjustable weight coefficients, corresponding to the importance percentage of each dimension in the final judgment (e.g., Wa=40%, Wb=30%, Wc=30%). This weighted fusion process essentially transforms discrete logical judgments into continuous numerical evaluations, enabling a more nuanced distinction between subtle states such as "light usage but about to become idle," "pseudo-occupancy due to background tasks," and "continuous testing with low interaction." The resulting overall status score is a scalar value that serves as the direct basis for the final status determination.

[0046] S404. Determine whether the overall status score is greater than the preset judgment threshold. If yes, determine that the target station is currently in an idle state; otherwise, determine that the target station is currently in an occupied state.

[0047] Specifically, after obtaining the comprehensive status score as a quantitative criterion, the system performs the final, decisive status classification operation. The essence of this operation is to compare a continuous value representing "idleness tendency" with a pre-calibrated scale that serves as a decision boundary. This "preset discrimination threshold" is a key constant set manually based on machine learning analysis of a large amount of historical operational data or domain knowledge; it precisely defines the numerical boundary between "prone to idleness" and "prone to occupancy." The specific decision logic is as follows: if the comprehensive status score is greater than this preset discrimination threshold, it indicates that the evidence strength after weighted fusion calculation has clearly crossed the confidence threshold required for determining idleness. At this point, the system generates a definitive conclusion that "the target rack is currently in an idle state." This conclusion will immediately trigger an update to the resource status database, notify the scheduling system to reallocate resources, and may change the visual identifier of the rack on the human-machine interface (e.g., change it to green). Conversely, if the overall status score is less than or equal to the preset threshold, it means that the current multi-dimensional evidence evaluation result is still insufficient to support the idle status, or is more inclined to indicate an occupied status. Therefore, the system will output the conclusion of "occupied status". This simple mechanism based on comparing a single value with a fixed threshold is the core step in achieving efficient and stable conversion between complex, multi-dimensional raw data and clear, executable management instructions. It ensures the clarity and reliability of the final output result of the entire complex judgment process.

[0048] In this embodiment, it also includes: The central server retrieves historical status sequence data of the target platform for trend analysis, which is used to verify or correct the current judgment results.

[0049] Specifically, to enhance the robustness and anti-interference capability of status judgment, this embodiment introduces a verification and correction step based on historical data after making an immediate decision based on real-time data. While generating the current status judgment result (idle / occupied), the central server asynchronously queries the time-series database for historical status sequence data of the target rack over a past time window, typically retrieving data records from the past 15 to 30 minutes or the most recent 10 to 30 consecutive heartbeat cycles. The system performs time-series analysis on this historical data, the core of which is to evaluate the consistency and rationality of the current judgment result within historical trends. For example, if the current judgment is "idle," the analysis engine will check whether there has been a continuous lack of user operation events and a steady decline in CPU and memory utilization over previous cycles. If the historical trend matches this, the current judgment is considered a reasonable continuation of the trend, and its confidence level is significantly enhanced. Conversely, if historical data shows that the rack was still in a high-load "occupied" state in the past period, with resource indicators dropping sharply without a smooth transition, and no normal user logouts or other events, then the current sudden "idle" determination may be an "isolated point" or false alarm caused by abnormal process exit, network interruption, or momentary failure of the monitoring agent. In this case, the system will not immediately adopt this single determination result, but will mark it as "pending verification" or "low confidence," and may take one or more corrective actions: delay the final state switch, trigger an immediate detailed diagnostic command for the rack, or provide a prompt alarm on the management interface instead of directly releasing resources. This mechanism, which integrates real-time decision-making and historical context analysis, essentially constructs a simple state machine smoothing filter. It can effectively suppress state flip noise caused by momentary anomalies, ensuring that the state signals output by the system are stable, reliable, and consistent with the actual physical process, thereby significantly improving the overall reliability of resource scheduling decisions.

[0050] In this embodiment, it also includes: A digital signature-based encrypted heartbeat message mechanism is used to periodically upload state sequence data to the central server; If no heartbeat message is received from the target tester for a set number of consecutive times, the target tester is determined to be in an abnormal state.

[0051] Specifically, to ensure the integrity, authenticity, and confidentiality of monitoring data during transmission and to monitor the operational health status of the monitoring stations themselves, this embodiment employs an encrypted heartbeat message mechanism based on digital signatures. At the monitoring terminal, each structured status sequence data packet to be sent is encapsulated using the agent's unique private key to generate a unique digital signature for the core content of the data packet (such as station identifier, timestamp, performance indicators, and event list). Then, the data packet, digital signature, and other necessary header information are encrypted using a high-strength transport layer encryption protocol to form the final heartbeat message. This encrypted message is periodically uploaded to the central server via a secure channel. Upon receiving the message, the central server first decrypts it and then uses a pre-stored public key corresponding to the agent to verify the attached digital signature. Successful signature verification double-confirms that the data has not been tampered with during transmission and confirms the authenticity of the data source—that is, it indeed originates from the claimed monitoring station. If verification fails, the heartbeat data is discarded and recorded as a security event. Simultaneously, the central server maintains a heartbeat reception status timer for each station. If no valid and verified heartbeat message is received from a target station within several consecutive preset heartbeat cycles (e.g., three consecutive times), the system will determine that the monitoring connection to that station has suffered a serious failure. This failure may stem from network interruption, agent process crash, or abnormal shutdown of the host computer itself. In this case, the system will bypass the business status (idle / occupied) judgment logic and directly mark the overall status of the target station as "abnormal" or "offline." This determination will immediately trigger high-level alarm notifications (such as SNMP traps, in-platform pop-ups, SMS messages, etc.) and may activate backup diagnostic channels for investigation. This mechanism not only ensures the security and reliability of the monitoring data stream but also elevates the heartbeat itself into a probe of system survivability, enabling the monitoring system to possess self-diagnosis and fault isolation capabilities.

[0052] In this embodiment, the central server displays the current status of the target platform through a dynamic visualization interface, distinguishing them by different colors.

[0053] Specifically, the central server presents the final rack status determination to system administrators or resource schedulers in real time through a dynamic, visual interface based on a browser and server architecture. This interface represents each physical rack using graphical elements (such as cards, icons, or list items) and distinguishes them based on their current status using a pre-defined color coding system: for example, racks determined to be idle are highlighted in green, intuitively conveying the "available" signal; racks in use are marked in red, warning of "in use"; and racks marked as abnormal or offline may be indicated in yellow, gray, or flashing. The status information on the interface is not static but is synchronized with the server-side real-time judgment engine and database, dynamically updated at a configurable high refresh rate (e.g., once per second), ensuring that administrators always see the current, instantaneous overview of the system's resources. In addition, the visualization interface typically integrates interactive functions, allowing users to click on specific racks to view their detailed status sequence data, historical records, and current occupant information. This transforms the complex multimodal data analysis results from the background into decision support information for the front end in a concise, intuitive, and operable manner, greatly improving the efficiency and response speed of resource monitoring and management.

[0054] In this embodiment, the performance index data also includes: List of active system processes, network connection status, and peripheral device access status.

[0055] Specifically, this embodiment also introduces three dimensions of indicators: a list of active system processes, network connection status, and peripheral device access status. These provide crucial contextual information and direct evidence for judgment, greatly enriching the connotation of "occupied" or "idle" states. For the list of active system processes, the judgment engine compares it in real-time with a predefined "key test process feature library." If the list contains processes strongly related to the test task, such as LabVIEW.exe, ControlDesk.exe, and INCA.exe, regardless of their instantaneous CPU usage, this is a strong signal supporting the "occupied" state. The system may directly reject the "idle" judgment based on this, or significantly reduce the score of the "resource load" component in the overall status score. For network connection status, the rule engine not only checks whether the network interface is "up," but also analyzes its activity, such as whether there are active TCP connections on specific ports (e.g., port 5555 used for XCP measurements), or whether network traffic is consistently higher than the background noise level. Continuous network activity matching the test protocol is strong evidence that the test is in progress. Regarding peripheral access, the system verifies whether a series of pre-configured "essential peripherals" (such as specific CAN cards and GPIB connections for programmable power supplies) are recognized by the operating system and are in a ready state. If critical peripherals are missing, even with user login and process execution, it may mean that the test has actually been interrupted due to hardware problems. This information will be taken into consideration, and the status may be corrected to "abnormal" or "restricted occupancy." Ultimately, the analysis results of these three indicators will be quantified into several sub-rules or correction factors, organically integrated into the aforementioned weighted decision model or direct judgment conditions, enabling the system to accurately distinguish between "formal low load" and "substantial free idle" across the entire link from hardware connection and software process to network communication.

[0056] The method in this embodiment has the following advantages: Improve equipment utilization: 1. Reduce idle time: By monitoring the occupancy of the equipment rack in real time, the usage status of the equipment can be accurately understood, thereby reducing the idle time of the equipment.

[0057] 2. Optimized scheduling solves the problem of uneven distribution of testing resources. Based on real-time data, production plans and equipment scheduling can be arranged more rationally to ensure maximum utilization of equipment.

[0058] Improve production efficiency: 1. Rapid response and real-time monitoring allow production managers to quickly respond to equipment idle status, adjust production tasks in a timely manner, and avoid production stoppages.

[0059] 2. Reduce waiting time: Employees can understand the equipment status in real time, reducing production delays caused by waiting for equipment.

[0060] It can monitor multiple racks simultaneously without limiting the number of racks; it can quickly detect the occupancy or idle status of racks and update data in a timely manner, providing feedback to the platform's human-machine interface without time delay; it monitors rack occupancy and idle status through the actual login and logout status of the host computer; after logging into the operating system, users are required to enter their private account password for platform verification, eliminating the possibility of false alarms.

[0061] The method in this embodiment constructs a complete closed-loop monitoring process from data acquisition, data preprocessing, heartbeat transmission, intelligent judgment to anomaly handling. This process makes full use of multimodal data fusion, dynamic parameter configuration, and historical data trend analysis to accurately determine whether the rack is idle, providing a precise basis for scheduling decisions, thereby significantly improving resource allocation efficiency (by 300%) and anomaly response speed (reduced to within 30 seconds).

[0062] Example 2

[0063] like Figure 3 As shown, this embodiment provides an intelligent identification device for the idle state of a test bench, including: The monitoring terminal is used to collect performance index data and user operation behavior event data from the target platform's host computer; preprocess the performance index data and user operation behavior event data to form structured state sequence data; and periodically upload the state sequence data to the central server. The central server is used to identify state sequence data based on preset composite judgment rules in order to determine whether the target rack is currently in an idle state.

[0064] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

Claims

1. A method for intelligently identifying the idle state of a test bench, characterized in that, include: Collect performance index data and user operation behavior event data from the target test bench's host computer. The performance index data and user operation behavior event data are preprocessed to form structured state sequence data; The state sequence data is periodically uploaded to the central server; The central server identifies the state sequence data based on preset composite judgment rules to determine whether the target rack is currently in an idle state.

2. The intelligent identification method for the idle state of a test bench according to claim 1, characterized in that, The performance metrics data include: CPU utilization and memory utilization; The user action event data includes: User login, user logout, session locking, session unlocking, and remote desktop connection events.

3. The intelligent identification method for the idle state of a test bench according to claim 2, characterized in that, The step of identifying the status data packet based on a preset composite judgment rule to determine whether the target rack is currently in an idle state includes: S401. Determine whether the state sequence data meets the first set condition. If yes, determine that the target platform is currently in an idle state. If no, execute S402. S402. Determine whether the state sequence data meets the second set condition. If yes, determine that the target platform is currently in an idle state. If no, execute S403. S403. Perform a weighted calculation on the state sequence data to obtain a comprehensive state score; S404. Determine whether the comprehensive status score is greater than a preset discrimination threshold. If yes, determine that the target platform is currently in an idle state; otherwise, determine that the target platform is currently in an occupied state.

4. The intelligent identification method for the idle state of a test bench according to claim 3, characterized in that, The first set conditions include: The idle time in the state sequence data since the last captured valid user operation event exceeds a first set time threshold. And the CPU utilization rate is lower than the first threshold; Furthermore, the memory utilization rate is lower than the second threshold.

5. The intelligent identification method for the idle state of a test bench according to claim 4, characterized in that, The second setting conditions include: The state sequence data contains no user operation events within a second set time threshold.

6. The intelligent identification method for the idle state of a test bench according to claim 5, characterized in that, The weighted calculation of the state sequence data to obtain the comprehensive state value includes: Calculate the operation idleness score based on the idle duration; Calculate the resource load score based on the CPU utilization and memory utilization; The event activity score is calculated based on the number of user operation behavior event data within the second set duration threshold. The comprehensive status score is obtained by multiplying the operation idleness score, resource load score and event activity score by their respective preset weight coefficients and then summing them.

7. The intelligent identification method for the idle state of a test bench according to claim 6, characterized in that, Also includes: The central server retrieves historical state sequence data of the target test bench for trend analysis, which is used to verify or correct the current judgment result.

8. The intelligent identification method for the idle state of a test bench according to claim 1, characterized in that, Also includes: The state sequence data is periodically uploaded to the central server using a digital signature-based encrypted heartbeat message mechanism. If no heartbeat message is received from the target test station for a set number of consecutive times, the target test station is determined to be in an abnormal state.

9. The intelligent identification method for the idle state of a test bench according to claim 1, characterized in that, The central server displays the current status of the target platform through a dynamic visual interface, distinguishing them by different colors.

10. An intelligent identification device for the idle state of a test bench, characterized in that, include: The monitoring terminal is used to collect performance index data and user operation behavior event data from the host computer of the target test bench. The performance index data and user operation behavior event data are preprocessed to form structured state sequence data; And periodically upload the state sequence data to the central server; A central server is used to identify the state sequence data based on preset composite judgment rules in order to determine whether the target rack is currently in an idle state.

Images