Equipment detection method and device, network equipment, storage medium and program product

Abstract

The embodiment of the invention provides an equipment detection method and device, network equipment, a storage medium and a program product. The method comprises the following steps: acquiring working state data of a terminal in a first duration; performing event detection on the terminal according to the working state data to obtain a first detection result of the working state of the terminal; the event detection comprises detection of at least one of a single event, an associated event, a time sequence dependent event and an event sequence. According to the equipment detection method provided by the embodiment of the invention, the working state data of the terminal does not need to be reported to the cloud for centralized processing, a fixed threshold is not set locally, and the working state of the terminal can be accurately determined in real time through event detection. The problem that in the prior art, real-time performance and accuracy of state detection of high-availability equipment cannot be guaranteed at the same time is solved.

Description

Technical Field

[0001] This application relates to the field of equipment condition monitoring technology, specifically to an equipment testing method, apparatus, network device, storage medium, and program product. Background Technology

[0002] For high-availability terminal devices such as payment POS machines and private cloud servers that require 24 / 7 availability, it is necessary to monitor their status in real time to ensure the safe operation of the devices.

[0003] Currently, using cloud-based centralized data analysis and processing to identify the status of terminal devices is not only resource-intensive, but also results in latency due to large amounts of data being uploaded to the cloud, making it impossible to guarantee the real-time nature of terminal device status analysis. Alternatively, using fixed thresholds and / or static time windows to identify and judge the real-time status of devices leads to high false alarm and false negative rates, which can easily cause terminal device downtime. In other words, existing technologies for status detection of high-availability devices cannot simultaneously guarantee real-time performance and accuracy. Summary of the Invention

[0004] At least one embodiment of this application provides a device detection method, apparatus, network device, storage medium, and program product to solve the problem in the prior art that the status detection of high-availability devices cannot simultaneously guarantee real-time performance and accuracy.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows:

[0006] In a first aspect, embodiments of this application provide a device detection method, applied to a first server, comprising:

[0007] Acquire the terminal's operational status data within the first time period;

[0008] Based on the working status data, the terminal is subjected to event detection to obtain a first detection result indicating whether the working status of the terminal is abnormal; the event detection includes detecting at least one of the following: single event, related event, time-dependent event, and event sequence.

[0009] If the first detection result indicates that the terminal's working status is abnormal, a first alarm message is sent to the second server.

[0010] The alarm information includes a target time range for the abnormal working status of the terminal and first working status data; the first working status data is the working status data corresponding to the target time range.

[0011] Optionally, the terminal's working state is subjected to event detection based on the working state data to obtain a first detection result, including:

[0012] Based on the working status data, it is detected whether the first event has successfully occurred within the first duration;

[0013] If the first event occurs successfully, the first detection result indicates that the terminal is in normal working condition; if the first event fails to occur successfully, the first detection result indicates that the terminal is in abnormal working condition.

[0014] Optionally, the terminal's working state is subjected to event detection based on the working state data to obtain a first detection result, including:

[0015] Based on the work status data, if the second event occurs successfully, it is detected whether the third event has occurred successfully within the first time period; the third event is an event that is related to the second event.

[0016] If the third event occurs successfully, the first detection result indicates that the terminal is in normal working condition; if at least one of the third events fails to occur, the first detection result indicates that the terminal is in abnormal working condition.

[0017] Optionally, the terminal's working state is subjected to event detection based on the working state data to obtain a first detection result, including:

[0018] Based on the working status data, if the fourth event occurs successfully, it is detected whether the fifth event occurs successfully within the first time period; the fifth event is an event that depends on the occurrence of the fourth event.

[0019] If the fifth event occurs successfully, the first detection result indicates that the terminal is in normal working condition; if the fifth event fails to occur successfully, the first detection result indicates that the terminal is in abnormal working condition.

[0020] Optionally, the terminal's working state is subjected to event detection based on the working state data to obtain a first detection result, including:

[0021] Based on the work status data, it is detected whether multiple fifth events have all successfully occurred within the first time period; the multiple fifth events are time events belonging to a time series.

[0022] If all of the plurality of fifth events occur successfully, the first detection result indicates that the terminal is in normal working condition; if at least one of the plurality of fifth events fails to occur, the first detection result indicates that the terminal is in abnormal working condition.

[0023] Optionally, the method further includes:

[0024] Using a second duration as a sliding detection window, anomaly detection is performed on the terminal's working status data within the first duration to obtain a second detection result; the second duration is shorter than the first duration.

[0025] If the second detection result is normal for L consecutive times, an event detection of the terminal's working status is triggered; L is an integer greater than or equal to 1.

[0026] Optionally, using a second duration as a sliding detection window, anomaly detection is performed on the terminal's operating status data within the first duration, including:

[0027] Determine the mean and standard deviation of the working state data within the sliding detection time window;

[0028] The dynamic threshold of the working status data is determined based on the mean and the standard deviation.

[0029] If M consecutive working status data are all greater than the dynamic threshold, the second detection result is that the working status of the terminal is abnormal; M is an integer greater than or equal to 1, and M is less than or equal to L.

[0030] Optionally, the method further includes:

[0031] If the second detection result is abnormal after N consecutive anomalies, a second alarm message is sent to the second server, where N is an integer greater than or equal to 1, and M is greater than or equal to N.

[0032] Secondly, embodiments of this application provide a device detection method applied to a second server, comprising:

[0033] Receive a first detection result and working status data sent by a first server; the first detection result is the detection result when the working status of the terminal is determined to be abnormal through event detection;

[0034] Based on the first detection result, the health status of the terminal is determined;

[0035] An early warning report is generated based on the health status of the terminal.

[0036] Thirdly, embodiments of this application provide a device testing apparatus, comprising:

[0037] The acquisition module is used to acquire the terminal's working status data within a first time period;

[0038] The detection module is used to perform event detection on the terminal based on the working status data, and obtain a first detection result indicating whether the working status of the terminal is abnormal; the event detection includes detecting at least one of the following: single event, related event, time-dependent event, and event sequence;

[0039] The sending module is used to send a first alarm message to the second server when the first detection result indicates that the terminal's working state is abnormal;

[0040] The alarm information includes a target time range for the abnormal working status of the terminal and first working status data; the first working status data is the working status data corresponding to the target time range.

[0041] Fourthly, embodiments of this application provide a device detection apparatus applied to a first server, comprising:

[0042] The receiving module is used to receive a first detection result and working status data sent by a first server; the first detection result is the detection result when the working status of the terminal is determined to be abnormal through event detection.

[0043] A determining module is used to determine the health status of the terminal based on the first detection result;

[0044] The generation module is used to generate an early warning report based on the health status of the terminal.

[0045] Fifthly, embodiments of this application provide a network device applied to a second server, including a transceiver and a processor, wherein...

[0046] The transceiver is used to acquire the terminal's working status data within a first time period;

[0047] The processor is configured to perform event detection on the terminal based on the working status data, and obtain a first detection result indicating whether the working status of the terminal is abnormal; the event detection includes detecting at least one of the following: single event, related event, time-dependent event, and event sequence.

[0048] The transceiver is also used to send a first alarm message to the second server when the first detection result indicates that the terminal's working status is abnormal;

[0049] The alarm information includes a target time range for the abnormal working status of the terminal and first working status data; the first working status data is the working status data corresponding to the target time range.

[0050] Sixthly, embodiments of this application provide a network device applied to a second server, including a transceiver and a processor, wherein...

[0051] The transceiver is used to receive a first detection result and working status data sent by a first server; the first detection result is the detection result when the working status of the terminal is determined to be abnormal through event detection.

[0052] The processor is configured to determine the health status of the terminal based on the first detection result;

[0053] An early warning report is generated based on the health status of the terminal.

[0054] In a seventh aspect, embodiments of this application provide a network device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the method as described in any of the first aspects.

[0055] Eighthly, embodiments of this application provide a computer-readable storage medium storing a program that, when executed by a processor, implements the steps of the method described in any of the first aspects.

[0056] Ninthly, embodiments of this application provide a computer program product including computer instructions that, when executed by a processor, implement the steps of the method as described in the first aspect or any of the above.

[0057] Compared with existing technologies, the device detection method, apparatus, network device, storage medium, and program product provided in this application embodiment, through the terminal's working status data obtained from the first server within the first market, can perform event detection on the terminal based on the working status data, thereby determining the terminal's working status. The solution in this application embodiment does not require reporting the terminal's working status data to the cloud for centralized processing, nor does it set fixed thresholds locally. Through event detection, the working status of the terminal can be determined in real time and accurately. For payment terminals, the device detection method in this application embodiment can detect the health of the payment terminal's transaction link in a timely and accurate manner; for payment gateways, it can efficiently and accurately detect memory leaks in the terminal; and it solves the problem in existing technologies where the status detection of high-availability devices cannot simultaneously guarantee real-time performance and accuracy. Attached Figure Description

[0058] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0059] Figure 1 This is a schematic diagram illustrating the steps of the device detection method applied to the first server in an embodiment of this application;

[0060] Figure 2 This is a logical schematic diagram of the device detection method according to an embodiment of this application;

[0061] Figure 3 This is a logical schematic diagram of a device detection method according to another embodiment of this application;

[0062] Figure 4 This is a schematic diagram of the device detection apparatus applied to the second server according to an embodiment of this application;

[0063] Figure 5 This is a schematic diagram of the network device applied to the first server according to an embodiment of this application;

[0064] Figure 6 This is a schematic diagram of the network device applied to the second server according to an embodiment of this application;

[0065] Figure 7 This is a schematic diagram of the structure of a network device according to an embodiment of this application;

[0066] Figure 8 This is a schematic diagram of the structure of a network device according to another embodiment of this application;

[0067] Figure 9 This is a schematic diagram of the structure of a network device according to another embodiment of this application. Detailed Implementation

[0068] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, without limiting the number of objects; for example, the first object can be one or more. Furthermore, "or" in this application indicates at least one of the connected objects. For example, "A or B" covers three scenarios: Scenario 1: including A but not B; Scenario 2: including B but not A; Scenario 3: including both A and B. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0069] The term "instruction" in this application can be either a direct instruction (or explicit instruction) or an indirect instruction (or implicit instruction). A direct instruction can be understood as one in which the sender explicitly informs the receiver of specific information, the operation to be performed, or the requested result, etc.; an indirect instruction can be understood as one in which the receiver determines the corresponding information based on the instruction sent by the sender, or makes a judgment and determines the operation to be performed or the requested result, etc., based on the judgment result.

[0070] It is worth noting that the technologies described in this application are not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA), or other systems. The terms "system" and "network" in this application are often used interchangeably, and the described technologies can be used in the systems and radio technologies mentioned above, as well as in other systems and radio technologies. The following description describes New Radio (NR) systems for illustrative purposes, and the term NR is used in most of the following description; however, these technologies can also be applied to systems other than NR systems, such as 6th Generation (6G) communication systems.

[0071] To enable those skilled in the art to better understand the embodiments of this application, the following description is provided first:

[0072] The terminal can be an all-weather (7×24 hours) mobile payment terminal (such as a POS terminal, barcode scanning device, self-service terminal, payment gateway).

[0073] The first server is an edge node that is adjacent to the terminal.

[0074] As described in the background section, existing technologies for detecting terminal devices either involve uploading data from the terminal to the cloud for centralized processing to monitor the terminal's status, setting fixed thresholds on the terminal side to determine if there are any anomalies, or setting a static time window to determine the terminal's status based on the average value of data within a fixed time period. In other words, existing technologies for detecting the status of high-availability devices cannot simultaneously guarantee real-time performance and accuracy.

[0075] For example:

[0076] Centralized cloud-based detection:

[0077] Core logic: The device uploads all operational data (such as CPU utilization and temperature) to a remote server for unified cloud analysis to check for anomalies. Centralized processing requires uploading massive amounts of data to the cloud (e.g., 1TB per day), leading to network congestion and processing latency exceeding 500ms. Business impact: Payment terminal failure switching needs to be completed within 100ms; the existing latency directly causes transaction failures (actual failure rate >5%).

[0078] Analogy: This is similar to uploading all surveillance footage to headquarters, where staff review each frame to identify problems.

[0079] Local fixed threshold alarm:

[0080] Core logic: The device has built-in simple rules (such as "alarm when temperature exceeds 40℃") that directly trigger local alarms. Fixed thresholds or static windows cannot adapt to dynamic scenarios (such as device load fluctuations or changes in ambient temperature), resulting in a false alarm rate >15% and a missed detection rate >20%. Business impact: False alarms lead to ineffective troubleshooting by maintenance personnel (averaging 40 hours per month), while missed detections may cause device downtime (such as a payment gateway crash).

[0081] Analogy: Similar to setting an alarm clock to ring at a fixed time, regardless of whether you actually need to get up.

[0082] Static time window detection:

[0083] Core logic: Calculate the average value of device data every fixed time interval (e.g., 10 minutes), and trigger an alarm if the value exceeds the range.

[0084] Analogy: Just like checking your heart rate every 10 minutes, it's impossible to capture the moment when your heart stops beating.

[0085] This application provides a device detection method and apparatus, which can reduce or avoid the above-mentioned situations, improve the real-time performance and accuracy of terminal status monitoring, and enhance user experience. The method and apparatus are based on the same concept, and since the principles by which they solve problems are similar, their implementations can be mutually referenced; repeated details will not be elaborated further.

[0086] Please refer to Figure 1 The device detection method provided in this application, when applied to a first server, includes the following steps:

[0087] Step 101: Obtain the terminal's working status data within the first time period;

[0088] Step 102: Perform event detection on the terminal based on the working status data to obtain a first detection result indicating whether the working status of the terminal is abnormal; the event detection includes detecting at least one of the following: single event, related event, time-dependent event, and event sequence;

[0089] If the first detection result indicates that the terminal's working status is abnormal, a first alarm message is sent to the second server.

[0090] The alarm information includes a target time range for the abnormal working status of the terminal and first working status data; the first working status data is the working status data corresponding to the target time range.

[0091] Optionally, the event detection can be performed using a No Operation Performed (NOP) operator.

[0092] It should be noted that the terminal is a terminal with internal sensors (such as temperature probes, ammeters, etc.); the terminal collects the working status data through the sensors or parses the working status data according to the protocol (Modbus / MQTT) (it also supports obtaining the working status data from third-party devices through protocols such as Modbus, MQTT, HTTP, syslog, and kafka).

[0093] The sampling frequency of the terminal for the working status data is set according to requirements or according to the data processing capability of the first server.

[0094] Optionally, the working status data includes: device operating status data (e.g., CPU utilization (0%-100%), memory usage (4GB-16GB), network traffic (10Mbps-1Gbps)), business event signals (e.g., heartbeat and transaction logs), and environmental parameters (e.g., temperature (-40℃~85℃), humidity (0%~100%RH)).

[0095] Optionally, the data is preprocessed before the terminal sends the working status data to the first server;

[0096] Specifically:

[0097] First, perform data cleaning to remove outliers (such as CPU utilization >100% or <0%).

[0098] Then, the data is standardized, for example, by converting it to JSON format (JSON (JavaScript Object Notation) is a lightweight data interchange format).

[0099] Optionally, a first alarm message is sent to the second server, including:

[0100] The alarm information is sent to the second server via a message queue.

[0101] The device detection method provided in this application embodiment uses the terminal's working status data obtained from the first server within the first market to perform event detection on the terminal, thereby determining the terminal's working status. This solution eliminates the need to report the terminal's working status data to the cloud for centralized processing, and avoids setting fixed thresholds locally. Through event detection, it can determine the terminal's working status in real time and accurately. For payment terminals, the device detection method of this application embodiment can promptly and accurately detect the health of the payment terminal's transaction chain; for payment gateways, it can efficiently and accurately detect memory leaks in the terminal; and it solves the problem in existing technologies where the status detection of high-availability devices cannot simultaneously guarantee real-time performance and accuracy.

[0102] Optionally, if it is determined that the terminal is in an abnormal working state, an alarm message is sent to the terminal to prevent the terminal from continuing to operate (e.g., interrupting subsequent payments).

[0103] Optionally, the terminal's working state is subjected to event detection based on the working state data to obtain a first detection result, including:

[0104] Based on the working status data, it is detected whether the first event has successfully occurred within the first duration;

[0105] If the first event occurs successfully, the first detection result indicates that the terminal is in normal working condition; if the first event fails to occur successfully, the first detection result indicates that the terminal is in abnormal working condition.

[0106] For example, if the first event is not detected to have occurred successfully in the working status data within the first time period, the terminal is determined to be in an abnormal working state.

[0107] Optionally, if the terminal is a payment terminal, the first event is a heartbeat signal;

[0108] The terminal performs event detection to determine whether it has received a heartbeat signal from the terminal.

[0109] For example, in a payment scenario:

[0110] Definition of the first event: heartbeat signal from the payment terminal (sent every 5 seconds);

[0111] The first duration is 30 seconds;

[0112] Triggering condition: No signal received for 6 consecutive heartbeat cycles (30 seconds);

[0113] Alarm action: Mark the device as offline and start the backup terminal.

[0114] Optionally, the terminal's working state is subjected to event detection based on the working state data to obtain a first detection result, including:

[0115] Based on the work status data, if the second event occurs successfully, it is detected whether the third event has occurred successfully within the first time period; the third event is an event that is related to the second event.

[0116] If the third event occurs successfully, the first detection result indicates that the terminal is in normal working condition; if at least one of the third events fails to occur, the first detection result indicates that the terminal is in abnormal working condition.

[0117] Optionally, the third event includes event A and event B;

[0118] Event A is when the main chain traffic is lower than the preset traffic; Event B is when the backup chain traffic is lower than the preset traffic.

[0119] For example, in a payment scenario:

[0120] The third event is defined as follows: Event_A: Primary link traffic < 50Mbps; Event_B: Backup link traffic < 50Mbps;

[0121] Logical relationship: Both primary and backup links are below the threshold.

[0122] Triggering condition: Event_A and Event_B last for 10 seconds;

[0123] Alarm action: Network interruption detected, switch to 4G backup channel.

[0124] Optionally, the terminal's working state is subjected to event detection based on the working state data to obtain a first detection result, including:

[0125] Based on the working status data, if the fourth event occurs successfully, it is detected whether the fifth event occurs successfully within the first time period; the fifth event is an event that depends on the occurrence of the fourth event.

[0126] If the fifth event occurs successfully, the first detection result indicates that the terminal is in normal working condition; if the fifth event fails to occur successfully, the first detection result indicates that the terminal is in abnormal working condition.

[0127] Optionally, the fifth event and the fourth event are time-dependent events.

[0128] For example, in a payment scenario:

[0129] Technical logic: When event C occurs, but dependent event D does not occur within the expected time window, an alarm is triggered; for example, if event C is a decrease in concurrent transaction volume, then event D can be a decrease in memory utilization; that is, a decrease in memory utilization is caused by a decrease in concurrent transaction volume.

[0130] Payment scenario examples:

[0131] Event definitions: Event_C: Concurrent transaction volume decreases by 50%; Event_D: Memory utilization decreases;

[0132] Timing relationship: After Event_C occurs, Event_D should be triggered within ΔT=60 seconds;

[0133] Triggering condition: Concurrency decreases but memory is not released within 60 seconds;

[0134] Alert action: Predict memory leaks and trigger proactive memory reclamation.

[0135] Optionally, the terminal's working state is subjected to event detection based on the working state data to obtain a first detection result, including:

[0136] Based on the work status data, it is detected whether multiple fifth events have all successfully occurred within the first time period; the multiple fifth events are time events belonging to a time series.

[0137] If all of the plurality of fifth events occur successfully, the first detection result indicates that the terminal is in normal working condition; if at least one of the plurality of fifth events fails to occur, the first detection result indicates that the terminal is in abnormal working condition.

[0138] Optionally, the time series consists of multiple events occurring sequentially.

[0139] For example, in a payment scenario:

[0140] Technical logic: If the expected sequence of events does not occur completely within a specified time window, an alarm is triggered.

[0141] Payment scenario examples:

[0142] Event sequence: E1: Daily transaction clearing begins at 03:00; E2: Transaction clearing is completed at 03:05; E3: Reconciliation file is generated at 03:10; that is, events E1, E2 and E3 occur in sequence.

[0143] Time window: 03:00-03:30;

[0144] Trigger condition: E3 is still not detected at 03:30;

[0145] Alarm action: Daily cut-off process abnormal, manual intervention initiated.

[0146] The device detection method of this application embodiment uses a non-occurrence operator to perform event detection on the terminal, thereby ensuring the real-time performance and accuracy of detecting the working status of the terminal.

[0147] Optionally, if it is determined that the terminal's working state is abnormal, a third alarm message including context data is generated, the third alarm message is stored locally for fault tracing, and the third alarm message is sent (e.g., via a message queue) to a cloud server.

[0148] like Figure 2 As shown, the method further includes:

[0149] Using a second duration as a sliding detection window, anomaly detection is performed on the terminal's working status data within the first duration to obtain a second detection result; the second duration is shorter than the first duration.

[0150] If the second detection result is normal for L consecutive times, an event detection of the terminal's working status is triggered; L is an integer greater than or equal to 1.

[0151] Optionally, the second duration can be configured as needed, for example, set to 60 seconds, and the range of the second duration can be set to 10-300 seconds;

[0152] Anomaly detection is performed on the terminal's working status data within the first time period using dynamic thresholds.

[0153] like Figure 3 As shown, using the second duration as a sliding detection window, anomaly detection is performed on the terminal's working status data within the first duration, including:

[0154] Determine the mean and standard deviation of the working state data within the sliding detection time window;

[0155] The dynamic threshold of the working status data is determined based on the mean and the standard deviation.

[0156] If M consecutive working status data are all greater than the dynamic threshold, the second detection result is that the working status of the terminal is abnormal; M is an integer greater than or equal to 1, and M is less than or equal to L.

[0157] Optionally, the dynamic threshold is calculated using the following formula:

[0158] Dynamic threshold = α × mean + β × standard deviation;

[0159] Where α and β are dynamic adjustment coefficients (default α=0.8, β=0.2, configurable range for both α and β is 0.5-1.0); α is the mean weight coefficient, reflecting the stability of historical data; β is the standard deviation weight coefficient, reflecting the sensitivity to data fluctuations. Both satisfy α+β=1. The default values ​​α=0.8 and β=0.2 are suitable for scenarios with small data fluctuations, while α=0.6 and β=0.4 are suitable for scenarios with large fluctuations.

[0160] It should be noted that the first server calculates the dynamic threshold locally based on the working status data collected by the terminal.

[0161] Specifically, the first server caches the working status data collected from the terminal in real time in its local memory according to a configured time window (e.g., 60 seconds), and independently calculates the mean and variance based on the data within this time window.

[0162] For example, for a payment terminal, the edge node may cache its CPU utilization sequence [65, 68, 72, 70, 95, 92, 90] for the most recent 60 seconds and then directly perform statistical calculations on this sequence.

[0163] Optionally, when the data standard (σ) within the window exceeds a preset threshold, the α value is automatically lowered and the β value is increased to enhance the detection sensitivity to sudden anomalies;

[0164] Furthermore, if the second detection result is normal for L consecutive times (e.g., 3 times), an event detection of the terminal's working status is triggered; for example: if the main link traffic is <80Mbps for 3 consecutive times, a master-slave switchover preparation command is triggered.

[0165] The device detection method of this application embodiment calculates dynamic thresholds through edge nodes and handles anomalies in the working status data. It does not rely on or wait for any data to be uploaded to the cloud, thus ensuring the real-time performance and accuracy of device status detection.

[0166] Optionally, after issuing an alarm message to the first server, the method further includes:

[0167] Retrieve preset rule commands;

[0168] The instructions are parsed to obtain the logical conditions and action instructions.

[0169] Optionally, the rule instructions can be stored in XML format.

[0170] For example:

[0171] The logical conditions and action instructions obtained by parsing the rule instructions are as follows:

[0172] "If the primary link traffic is below 80Mbps for 10 consecutive seconds and the backup link is in normal condition, a primary / backup switchover will be triggered."

[0173] Optionally, the parsed rule instructions can be converted into a directed acyclic graph;

[0174] The logical conditions and action instructions are obtained by parsing the directed acyclic graph.

[0175] It should be noted that the nodes in the directed acyclic graph represent detection conditions (such as flow value judgment), and the edges represent the dependencies between conditions.

[0176] Technical Implementation:

[0177] Executable programs (such as Java / Python modules) are dynamically generated using reflection technology and embedded in edge nodes to run.

[0178] The device detection method in this application supports parallel condition detection of 20+ predefined scenarios (master / standby switching, temperature overload protection, etc.).

[0179] Optionally, it also includes:

[0180] If the second detection result is abnormal after N consecutive anomalies, a second alarm message is sent to the second server, where N is an integer greater than or equal to 1, and M is greater than or equal to N.

[0181] It should be noted that if the second detection result is abnormal N times consecutively, there is no need to perform event detection to determine that the terminal's working state is abnormal.

[0182] like Figure 4 As shown in the figure, this application embodiment also provides a device detection method, applied to a second server, including the following steps:

[0183] Step 401: Receive the first detection result and working status data sent by the first server; the first detection result is the detection result when the working status of the terminal is determined to be abnormal through event detection.

[0184] Step 402: Determine the health status of the terminal based on the first detection result;

[0185] Step 403: Generate an early warning report based on the health status of the terminal.

[0186] Optionally, determining the health status of the terminal based on the first detection result includes:

[0187] The health status of the terminal is determined according to the following formula:

[0188] Health score = 0.4 × CPU + 0.3 × Memory + 0.3 × Traffic.

[0189] Optionally, the early warning report includes:

[0190] The health status of the terminal, and the operation and maintenance decisions made for the terminal.

[0191] For example, the early warning report indicates that the health status of the terminal is faulty, and the maintenance decision for the terminal is to dispatch a repair work order.

[0192] The device detection method of this application embodiment analyzes and calculates the first detection result through the second server to determine the health of the terminal, and then sends an early warning report to the application layer; it greatly reduces the amount of data that needs to be processed for terminal device detection in the cloud, and the device detection is efficient and accurate.

[0193] It should be noted that the device detection method of this application embodiment can be applied to the following scenarios:

[0194] 1. Monitoring of intelligent medical devices

[0195] Dynamic thresholding (DTA) algorithms are adapted to vital sign data (such as blood oxygen and heart rate) to enable early warning of abnormal fluctuations.

[0196] Non-occurrence operator (NOP) detection of "medication reminder non-response" events can improve patient adherence management.

[0197] 2. Smart City Security System

[0198] Use NOP rules to identify abnormal behavior (such as a camera image remaining still for more than 1 hour but the access control is triggered) to enhance security.

[0199] Edge computing architecture reduces video analytics latency and supports real-time alerts.

[0200] In one embodiment of this application, the transaction chain of the payment terminal (POS machine) is detected:

[0201] (1) Business requirements:

[0202] POS machines need to operate stably 24 / 7, with a single transaction response latency of ≤500ms. Failures that result in transaction failures will directly cause financial losses to merchants.

[0203] (2) Business pain points:

[0204] Risk of missed detection: During periods of low load at night, real CPU failures (such as virus scanning using 50% of the CPU) may go undetected because they are below a fixed threshold (90%), leading to a surge in the transaction failure rate the following morning.

[0205] False alarm interference: During peak trading hours, brief fluctuations in CPU usage (85%→92%) trigger fixed threshold alarms, even though there is no actual fault, wasting operational resources.

[0206] (3) Implementation of technical solutions

[0207]

[0208] (4) Dynamic threshold calculation

[0209] Suppose that within a 30-second sliding window, 7 CPU utilization data points (unit: %) are collected: [15, 18, 16, 14, 50, 48, 52]. The first 4 are normal low load, and the last 3 are the start of a fault (assuming it is caused by a network attack).

[0210] Step 1: Calculate the mean (μ)

[0211] μ=∑i=1nxin=15+18+16+14+50+48+527=2137≈30.43%

[0212] Step 2: Calculate the standard deviation (σ)

[0213] Calculate the variance:

[0214]

[0215] Sum of squares = 238.02+154.50+208.22+269.94+382.98+308.76+465.32 = 2027.74

[0216] Variance = 2027.74 / 7 ≈ 289.68

[0217] Standard deviation (σ): σ = √variance = √289.68 ≈ 17.02%

[0218] Step 3: Dynamic Threshold Calculation (DTA Algorithm)

[0219] Threshold = α⋅μ + β⋅σ = ​​0.7 × 30.43 + 0.3 × 17.02 = 21.30 + 5.11 = 26.41%

[0220] Step 4: Exception Trigger Judgment

[0221] Rule: Three consecutive data points > threshold (26.41%) → trigger an alarm.

[0222] The latest 3 data points were detected:

[0223]

[0224] (5) Implementation results

[0225] Missed reports eliminated: 100% fault detection rate at night;

[0226] False alarms reduced: False alarms due to intraday transient fluctuations decreased by 90%;

[0227] Business benefits: Fault switching speed <100ms.

[0228] In another embodiment of this application, memory leaks in the payment gateway are detected:

[0229] (1) Business requirements

[0230] The payment gateway needs to handle a peak of 100,000 transaction requests per minute. Memory leaks or sudden surges in traffic may cause the system to crash, triggering large-scale transaction interruptions.

[0231] (2) Business pain points

[0232] Hidden risk: Memory usage continues to rise (e.g., from 45% to 58%), but because it does not exceed a fixed threshold (90%), it is not detected in time, eventually leading to system crash.

[0233] Instantaneous missed detection: During the peak traffic of "Double Eleven", the traditional static window (10-minute average) cannot capture second-level anomalies.

[0234] (3) Implementation of technical solutions

[0235]

[0236] (4) Dynamic threshold calculation

[0237] Suppose at a certain point in time, we observe the following: Concurrent transaction volume: decreasing from 10,000 transactions / minute to 9,000 transactions / minute, then to 5,000 transactions / minute (a 50% decrease); Memory utilization: 45%, 48%, 58% (the last three points show a continuous increase). Non-occurrence operator rule: If concurrency decreases by 50% but memory utilization does not decrease (i.e., memory utilization exceeds a dynamic threshold), then a memory leak is predicted.

[0238] Step 1: Calculate the average memory usage (μ)

[0239] μ=45+48+583=1513≈50.33%μ=345+48+58=3151≈50.33%

[0240] Step 2: Calculate the standard deviation of memory (σ)

[0241] Calculate the variance:

[0242]

[0243] Sum of squares = 28.41+5.43+58.83 = 92.67

[0244] Variance = 92.67 / 3 ≈ 30.89

[0245] Standard deviation (σ):

[0246] σ = √30.89 ≈ 5.56%

[0247] Step 3: Dynamic Threshold Calculation (DTA Algorithm)

[0248] Threshold = α⋅μ + β⋅σ = ​​0.6 × 50.33 + 0.4 × 5.56 = 30.20 + 2.22 = 32.42%

[0249] Step 4: Non-occurrence operator early warning judgment

[0250] Verification of decreased concurrency:

[0251] (Latest concurrency - Baseline concurrency) / Baseline concurrency = (5000 - 10000) / 10000 = -50%

[0252] Memory not released verification:

[0253] Latest memory usage 58% > Dynamic threshold 32.42% → Meets the "memory usage has not decreased" condition;

[0254] Warning triggered:

[0255] A 50% decrease in concurrency and unreleased memory triggers a memory leak warning.

[0256] (5) Implementation results

[0257] Fault prevention: 13 early warnings of memory leaks prevented system crashes;

[0258] Resource optimization: Dynamic expansion mechanism reduces redundant servers by 30%;

[0259] Peak handling: The rate of missed detection of second-level traffic spikes has been reduced from 15% to 2.1%.

[0260] 3. Technical Analysis of the Calculation Process

[0261] (1) Parameter selection principle

[0262]

[0263] (2) Business protection mechanism

[0264] Continuous triggering mechanism: The payment terminal needs to exceed the threshold for 3 consecutive points before triggering an alarm → filtering out instantaneous fluctuations during the day (such as 85% → 92% → 86%).

[0265] Multi-indicator correlation: Payment gateway requires concurrency to decrease and memory not to be released → to avoid misjudgment based on a single indicator.

[0266] The device detection method of this application embodiment does not require uploading to the cloud. By processing and judging the working status data of the terminal at the edge node, it avoids network congestion caused by uploading a large amount of data to the cloud, thereby ensuring the real-time performance of device detection. By setting dynamic thresholds and event detection, the accuracy of device detection can be guaranteed.

[0267] This application also provides a device detection method applied to a second server, comprising the following steps:

[0268] Receive early warning information and first status data; the first status data is status data indicating that the terminal is abnormal; the status data includes: device operation data and business event data;

[0269] The health status of the terminal is determined based on the first status data.

[0270] It should be noted that the second server is a cloud server;

[0271] The first server only sends abnormal data to the second server so that the second server can calculate the health of the terminal.

[0272] In one embodiment of this application, the first server sends the abnormal data and statistical results (a 90% reduction in bandwidth compared to a full upload) to the second server;

[0273] Protocol: MQTT (supports resume download after network outage, and edge caching of data for 72 hours);

[0274] The second server calculates the device health score in real time.

[0275] Specifically, a score of ≥80% indicates a healthy condition (green); a score of 60% ≤ score < 80% indicates a warning (yellow); and a score < 60% indicates a malfunction (red).

[0276] The various methods of the embodiments of this application have been described above. Apparatus for implementing the above methods will now be provided.

[0277] like Figure 5 As shown in the illustration, this application also provides a device detection apparatus applied to a first server, comprising:

[0278] The acquisition module 501 is used to acquire the terminal's working status data within a first time period;

[0279] Detection module 502 is used to perform event detection on the terminal based on the working status data to obtain a first detection result indicating whether the working status of the terminal is abnormal; the event detection includes detecting at least one of the following: single event, related event, time-dependent event, and event sequence;

[0280] The sending module 503 is used to send a first alarm message to the second server when the first detection result indicates that the terminal's working state is abnormal;

[0281] The alarm information includes a target time range for the abnormal working status of the terminal and first working status data; the first working status data is the working status data corresponding to the target time range.

[0282] The device detection apparatus provided in this application embodiment uses the terminal's working status data obtained from the first server within the first market to perform event detection on the terminal, thereby determining the terminal's working status. The solution in this application embodiment does not require reporting the terminal's working status data to the cloud for centralized processing, nor does it set fixed thresholds locally. Through event detection, it can determine the terminal's working status in real time and accurately. For payment terminals, the device detection method of this application embodiment can detect the health of the payment terminal's transaction link in a timely and accurate manner; for payment gateways, it can efficiently and accurately detect memory leaks in the terminal; it solves the problem in the prior art that the status detection of high-availability devices cannot simultaneously guarantee real-time performance and accuracy.

[0283] like Figure 6As shown in the illustration, this application also provides a device detection apparatus applied to a second server, comprising:

[0284] The receiving module 601 is used to receive a first detection result and working status data sent by the first server; the first detection result is the detection result when the working status of the terminal is determined to be abnormal through event detection;

[0285] The determining module 602 is used to determine the health status of the terminal based on the first detection result;

[0286] The generation module 603 is used to generate an early warning report based on the health status of the terminal.

[0287] The device detection apparatus of this application embodiment analyzes and calculates the first detection result through the second server to determine the health of the terminal, and then sends an early warning report to the application layer; it greatly reduces the amount of data that needs to be processed for terminal device detection in the cloud, and the device detection is efficient and accurate.

[0288] like Figure 7 As shown in the illustration, this application also provides a network device, including a transceiver 701 and a processor 702, wherein...

[0289] The transceiver 701 is used to acquire the terminal's working status data within a first time period;

[0290] The processor 702 is configured to perform event detection on the terminal based on the working status data, and obtain a first detection result indicating whether the working status of the terminal is abnormal; the event detection includes detecting at least one of the following: single event, related event, time-dependent event, and event sequence.

[0291] If the first detection result indicates that the terminal's working status is abnormal, a first alarm message is sent to the second server.

[0292] The alarm information includes a target time range for the abnormal working status of the terminal and first working status data; the first working status data is the working status data corresponding to the target time range.

[0293] like Figure 8 As shown in the illustration, this application also provides a network device, including a transceiver 801 and a processor 802, wherein,

[0294] The transceiver 801 is used to receive a first detection result and working status data sent by the first server; the first detection result is the detection result when the working status of the terminal is determined to be abnormal through event detection.

[0295] The processor 802 is configured to determine the health status of the terminal based on the first detection result.

[0296] An early warning report is generated based on the health status of the terminal.

[0297] The network device provided in this application embodiment, through the terminal's working status data obtained from the first server within the first market, can perform event detection on the terminal based on the working status data, thereby determining the terminal's working status. The solution in this application embodiment does not require reporting the terminal's working status data to the cloud for centralized processing, nor does it set fixed thresholds locally. Through event detection, it can determine the terminal's working status in real time and accurately. This solves the problem in the prior art that the status detection of high-availability devices cannot simultaneously guarantee real-time performance and accuracy.

[0298] Another embodiment of this application provides a network device, such as... Figure 9 As shown, it includes a transceiver 910, a processor 900, a memory 920, and a program or instructions stored in the memory 920 and executable on the processor 900; when the processor 900 executes the program or instructions, it implements the various processes of the device detection method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0299] The transceiver 910 is used to receive and send data under the control of the processor 900.

[0300] Among them, Figure 9 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 900 and memory represented by memory 920 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. Transceiver 910 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium. For different user equipment, user interface 930 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0301] The processor 900 is responsible for managing the bus architecture and general processing, while the memory 920 can store the data used by the processor 900 during operation.

[0302] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described device detection method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0303] This application also provides a computer program product, including computer instructions. When the computer instructions are executed by a processor, they implement the various processes of the above-described device detection method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0304] If the solution involves implicit data collection such as user location and internet access behavior, add a statement similar to the following to the specification:

[0305] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in this disclosed technical solution all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security and network security.

[0306] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0307] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0308] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A device detection method, applied to a first server, the method comprising: The method comprises: acquiring working state data of a terminal within a first time length; performing event detection on the terminal according to the working state data to obtain a first detection result indicating whether the working state of the terminal is abnormal; the event detection comprises detecting at least one of the following: a single event, a related event, a time sequence dependent event, and an event sequence; in a case where the first detection result indicates that the working state of the terminal is abnormal, sending first alarm information to a second server; wherein the alarm information comprises a target time range in which the working state of the terminal is abnormal and first working state data; the first working state data is the corresponding working state data within the target time range.

2. The method of claim 1, wherein, The event detection on the working state of the terminal according to the working state data to obtain a first detection result comprises: detecting, according to the working state data, whether a first event successfully occurs within the first time length; if the first event successfully occurs, the first detection result is that the working state of the terminal is normal; if the first event does not successfully occur, the first detection result is that the working state of the terminal is abnormal.

3. The method of claim 1, wherein, The event detection on the working state of the terminal according to the working state data to obtain a first detection result comprises: in a case where a second event successfully occurs, detecting, according to the working state data, whether a third event successfully occurs within the first time length; the third event is an event having a related relationship with the second event; if the third event successfully occurs, the first detection result is that the working state of the terminal is normal; if at least one of the third events does not successfully occur, the first detection result is that the working state of the terminal is abnormal.

4. The method of claim 1, wherein, The event detection on the working state of the terminal according to the working state data to obtain a first detection result comprises: in a case where a fourth event successfully occurs, detecting, according to the working state data, whether a fifth event successfully occurs within the first time length; the fifth event is an event dependent on the occurrence of the fourth event; if the fifth event successfully occurs, the first detection result is that the working state of the terminal is normal; if the fifth event does not successfully occur, the first detection result is that the working state of the terminal is abnormal.

5. The method of claim 1, wherein, The event detection on the working state of the terminal according to the working state data to obtain a first detection result comprises: detecting, according to the working state data, whether a plurality of fifth events successfully occur within the first time length; the plurality of fifth events belong to a time sequence; if the plurality of fifth events successfully occur, the first detection result is that the working state of the terminal is normal; if at least one of the plurality of fifth events does not successfully occur, the first detection result is that the working state of the terminal is abnormal.

6. The method of claim 1, wherein, The method further comprises: performing abnormality detection on the working state data of the terminal within the first time length with a second time length as a sliding detection window to obtain a second detection result; the second time length is less than the first time length; In a case that the second detection result is normal for L consecutive times, triggering event detection on the working state of the terminal; L is an integer greater than or equal to 1.

7. The method of claim 6, wherein, With the second time length as a sliding detection window, performing anomaly detection on the working state data of the terminal in the first time length, comprising: determining the mean and standard deviation of the working state data in the sliding detection time window; determining a dynamic threshold of the working state data according to the mean and the standard deviation; in a case that M consecutive working state data are greater than the dynamic threshold, the second detection result is that the working state of the terminal is abnormal; M is an integer greater than or equal to 1, and M is less than or equal to L.

8. The method of claim 7, wherein, Further comprising: in a case that the second detection result is abnormal for N consecutive times, sending second alarm information to a second server, N is an integer greater than or equal to 1, and M is greater than or equal to N.

9. A device detection method applied to a second server, comprising: Comprising: receiving the first detection result and the working state data sent by the first server; the first detection result is the detection result in a case that the working state of the terminal is determined to be abnormal through event detection; determining the health degree of the terminal according to the first detection result; generating a pre-warning report according to the health degree of the terminal.

10. A device detection apparatus applied to a first server, characterized in that, Comprising: an acquisition module for acquiring working state data of a terminal in a first time length; a detection module for performing event detection on the terminal according to the working state data, to obtain a first detection result for indicating whether the working state of the terminal is abnormal; the event detection comprises detecting at least one of the following: a single event, a correlation event, a time sequence dependent event and an event sequence; a sending module for sending first alarm information to a second server in a case that the first detection result indicates that the working state of the terminal is abnormal; wherein, the alarm information comprises a target time range in which the working state of the terminal is abnormal and first working state data; the first working state data is the corresponding working state data in the target time range.

11. A device detection apparatus applied to a second server, characterized in that, Comprising: a receiving module for receiving the first detection result and the working state data sent by the first server; the first detection result is the detection result in a case that the working state of the terminal is determined to be abnormal through event detection; a determination module for determining the health degree of the terminal according to the first detection result; a generation module for generating a pre-warning report according to the health degree of the terminal.

12. A network device, applied to a first server, characterized in that, Comprising a transceiver and a processor, wherein, the transceiver is configured to acquire working state data of a terminal in a first time length; the processor is configured to perform event detection on the terminal according to the working state data, to obtain a first detection result for indicating whether the working state of the terminal is abnormal; the event detection comprises detecting at least one of the following: a single event, a correlation event, a time sequence dependent event and an event sequence; the transceiver is further configured to send first alarm information to a second server in a case that the first detection result indicates that the working state of the terminal is abnormal; The alarm information comprises a target time range of an abnormal working state of the terminal and first working state data.

13. A network device, applied to a second server, characterized in that, Comprising a transceiver and a processor, wherein, The transceiver is configured to receive first detection results and working state data sent by a first server, wherein the first detection results are detection results determined by event detection when the working state of the terminal is abnormal. The processor is configured to determine the health degree of the terminal according to the first detection results. An early warning report is generated according to the health degree of the terminal.

14. A network device, comprising: Comprising: a transceiver, a processor, a memory, and a program or instructions stored on the memory and executable on the processor; The processor implements the steps of the method according to any one of claims 1 to 9 when executing the program or instructions.

15. A computer-readable storage medium, characterized in that, The computer program is stored on the computer readable storage medium, and the computer program is executable by the processor to implement the steps of the method according to any one of claims 1 to 9.

16. A computer program product, characterised in that, The computer program comprises computer instructions executable by the processor to implement the steps of the method according to any one of claims 1 to 9.

Images