A fault data acquisition system and method

Abstract

Embodiments of the present application disclose a fault data acquisition system and method. The system comprises a sending end, a receiving end and a matching end. The sending end is configured to generate a control instruction in each sampling period, assign a monotonically increasing serial number to the control instruction as a synchronization mark, and record a time when the instruction is sent as a first time stamp T1. The receiving end is configured to, after receiving an instruction data packet, parse the serial number, execute an operation according to the control instruction, collect response execution data in the same sampling period as the sending end, record a time when the response execution data is collected as a second time stamp T2, and associate the serial number to the response execution data. The matching end is configured to obtain the instruction data packet and a corresponding feedback data packet, match the control instruction and the response execution data based on the serial number, and form an instruction-response synchronization data pair. The scheme provided by the present application can improve the data quality of trajectory data collected in a robot fault state.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a fault data acquisition system and method. Background Technology

[0002] With the widespread application of industrial and service robots in manufacturing, medical, and logistics fields, robots inevitably experience various malfunctions during operation (such as mechanical joint wear, circuit control board abnormalities, and sensor failures). When a robot malfunctions, operator intervention is typically required via teleoperation. This involves using remote control devices (such as a master hand, joystick, or VR device) to control the robot, guide it to complete remaining tasks, or move it to a safe location. Furthermore, it is necessary to collect trajectory data under fault conditions, i.e., collect trajectory data during teleoperation (such as joint angles, end effector pose, and torque signals), and clean this data for subsequent fault analysis, model training (such as imitation learning and reinforcement learning), and trajectory reuse in the production environment.

[0003] It is understandable that the quality of trajectory data under fault conditions directly determines the accuracy of subsequent fault analysis, model training, and the reliability of production reuse. However, collecting teleoperation trajectory data under robot fault conditions presents significantly different data quality challenges compared to normal operating conditions. Therefore, improving the data quality of trajectory data collected under robot fault conditions has become an urgent technical problem to be solved. Summary of the Invention

[0004] This application provides a fault data acquisition system and method to improve the data quality of trajectory data acquired under robot fault conditions. The specific technical solution is as follows.

[0005] In a first aspect, embodiments of this application provide a fault data acquisition system, the system including a transmitter, a receiver, and a matching terminal; The transmitting end is configured to generate control commands in each sampling period, assign monotonically increasing sequence numbers to the control commands as synchronization markers, record the command transmission time as a first timestamp T1, and send the command data packet carrying the control commands, the sequence numbers, and T1 to the receiving end. The receiving end is configured to receive the instruction data packet, parse it to obtain the sequence number, execute the operation according to the control instruction, collect response execution data with the same sampling period as the sending end, record the collection time of the response execution data as a second timestamp T2, associate the sequence number with the response execution data, and package the sequence number, the T2 and the response execution data together to generate a feedback data packet. The matching end is used to obtain the instruction data packet and the corresponding feedback data packet, and match the control instruction with the response execution data based on the sequence number to form an instruction-response synchronization data pair. The instruction-response synchronization data pair includes at least T1 and T2.

[0006] In one embodiment of this application, the matching end is specifically used to acquire the instruction data packet and the corresponding feedback data packet, and pair control instructions and response execution data with the same sequence number to form an initial synchronization data pair according to the sequence number; for any initial synchronization data pair, the instruction response delay Δt = T2 - T1 is calculated according to its corresponding T1 and T2; when the Δt meets the preset condition, the initial synchronization data pair is determined as a valid instruction response synchronization data pair.

[0007] In one embodiment of this application, the matching end is specifically used to determine the initial synchronization data pair as a valid instruction response synchronization data pair when the Δt is less than or equal to a preset duration threshold.

[0008] In one embodiment of this application, the matching end is further configured to discard the initial synchronization data pair and resend the control command corresponding to the initial synchronization data pair when the preset condition is not met by Δt.

[0009] In one embodiment of this application, the maximum number of times the control command can be resent is a preset number; The matching end is specifically used to discard the initial synchronization data pair and increment the retry count of the control command corresponding to the initial synchronization data pair by 1 when the Δt does not meet the preset condition. If the number of retries for the control command is less than or equal to the preset number, the control command is resent. If the control command times out after the preset number of retries, the control command will be marked as a failed match.

[0010] In one embodiment of this application, the matching end is further configured to add a status label to each instruction response synchronization data pair to obtain an annotated synchronization data pair; the status label includes at least a timestamp label, an instruction response delay label, a retry count label, and a matching status label.

[0011] In one embodiment of this application, the matching end is further configured to trigger a system alarm and record the start and end timestamps of the continuous timeouts when it is determined that the Δt of N consecutive control commands is greater than a preset delay threshold. All data within the time period defined by the start timestamp and the end timestamp are marked as communication anomaly data.

[0012] In one embodiment of this application, the matching end is further configured to perform fault analysis on the instruction response data pair to detect whether a fault has occurred; When a fault is detected, the sampling frequency of the sampling period is adjusted according to the different periods in which the fault occurs.

[0013] In one embodiment of this application, the different periods include: the initial stage of the fault, the stable period of the fault, and the recovery period of the fault. The sampling frequency during the initial stage of the fault is greater than the sampling frequency during the fault recovery period, and the sampling frequency during the fault recovery period is greater than the sampling frequency during the fault stabilization period.

[0014] In one embodiment of this application, the matching end is the sending end, the receiving end, or a third end independent of the sending end and the receiving end.

[0015] Secondly, embodiments of this application provide a fault data acquisition method, the method comprising: In each sampling period, a control command is generated, a monotonically increasing sequence number is assigned to the control command as a synchronization marker, and the command transmission time is recorded as the first timestamp T1; the command data packet carrying the control command, the sequence number, and T1 is sent out. The system receives the instruction data packet, parses it to obtain the sequence number, executes the operation according to the control instruction, and collects response execution data at the same sampling period as the sending side. The collection time of the response execution data is recorded as the second timestamp T2, and the sequence number is associated with the response execution data. The sequence number, the T2, and the response execution data are associated and packaged to generate a feedback data packet. The instruction data packet and the corresponding feedback data packet are obtained. The control instruction and the response execution data are matched based on the sequence number to form an instruction-response synchronization data pair. The instruction-response synchronization data pair includes at least T1 and T2.

[0016] In one embodiment of this application, the step of obtaining the instruction data packet and the corresponding feedback data packet, and matching the control instruction with the response execution data based on the sequence number to form an instruction-response synchronization data pair includes: The instruction data packet and the corresponding feedback data packet are obtained. According to the sequence number, control instructions and response execution data with the same sequence number are paired to form an initial synchronization data pair. For any initial synchronization data pair, the instruction response delay Δt = T2 - T1 is calculated according to its corresponding T1 and T2. When Δt is less than or equal to a preset duration threshold, the initial synchronization data pair is determined as a valid instruction response synchronization data pair.

[0017] In one embodiment of this application, the method further includes: When Δt is less than or equal to a preset duration threshold, the initial synchronization data pair is discarded, and the corresponding control command is retried. If the number of retries for the control command is less than or equal to the preset number, the control command is resent. If the control command times out after the preset number of retries, the control command will be marked as a failed match.

[0018] In one embodiment of this application, the method further includes: The command response data is used to perform fault analysis to identify the different stages of the fault, and the sampling frequency is adjusted according to the initial stage of the fault, the stable stage of the fault, and the recovery stage of the fault. The sampling frequency during the initial stage of the fault is greater than the sampling frequency during the fault recovery period, and the sampling frequency during the fault recovery period is greater than the sampling frequency during the fault stabilization period.

[0019] In this embodiment, the sending end generates control commands within each sampling period, assigns a monotonically increasing sequence number to the control commands as a synchronization marker, and records the command transmission time as a first timestamp T1. The sending end then sends a command data packet carrying the control commands, sequence number, and T1 to the receiving end. After receiving the command data packet, the receiving end can parse to obtain the sequence number, execute operations according to the control commands, and collect response execution data at the same sampling period as the sending end. The collection time of the response execution data is recorded as a second timestamp T2, and the sequence number is associated with the response execution data. The sequence number, T2, and response execution data are then packaged together to generate feedback data. According to the packet; finally, the matching end can obtain the instruction data packet and the corresponding feedback data packet, and match the control instruction with the response execution data based on the sequence number to form an instruction-response synchronization data pair. The instruction-response synchronization data pair contains at least T1 and T2. That is to say, in the fault data acquisition stage, the instruction data packet and the feedback data packet can be accurately synchronized based on the sequence number and timestamp to obtain an instruction-response synchronization data pair that is completely synchronized. This reduces invalid and biased data caused by instruction-motion asynchrony from the source, improves the effectiveness of the original trajectory data, and thus improves the data quality of the trajectory data collected under robot fault conditions. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0021] Figure 1 This paper shows a schematic diagram of the structure of a fault data acquisition system provided in an embodiment of this application; Figure 2 A flowchart illustrating a fault data acquisition method provided in an embodiment of this application is shown. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0023] It should be noted that the terms "comprising" and "having," and any variations thereof, in the embodiments and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0024] During trajectory data acquisition in robot malfunction states, the quality of teleoperation data directly determines the accuracy of subsequent fault analysis, model training, and the reliability of production reuse. However, acquiring teleoperation trajectory data in robot malfunction states presents significantly different data quality challenges compared to normal operating conditions: abnormal joint movements caused by the malfunction itself (such as jamming or jitter), asynchrony between teleoperation commands and actual robot movements (response lag due to communication delays or malfunctions), and data interruptions caused by mode switching during operation all severely degrade the quality of the acquired data.

[0025] Specifically, known trajectory data acquisition methods have the following drawbacks: the data collected in fault scenarios has large deviations and a high proportion of invalid data.

[0026] It is understandable that in a robot malfunction state, there is a significant delay between the issuance of teleoperation commands and the actual movement of the robot joints (measured delays can reach over 300ms), and the abnormal joint response caused by the malfunction results in a severe deviation in the mapping relationship between commands and movements. However, known fixed-frequency sampling schemes have not been optimized for the command-movement asynchrony problem in malfunction states. Because the acquisition system cannot identify and filter these deviation data caused by asynchrony, the final acquired trajectory data contains a large number of invalid samples, with the invalid data ratio reaching as high as 30%-50%, seriously affecting subsequent use.

[0027] Therefore, to improve the quality of trajectory data in robot malfunction states, the following technical issues need to be addressed: how to synchronize teleoperation commands and robot joint motion states in real time during the acquisition of teleoperation trajectory data in robot malfunction states, thereby reducing invalid and biased data caused by command-motion asynchrony from the source and improving the effectiveness and accuracy of the original trajectory data.

[0028] Based on this, the embodiments of this application provide a fault data acquisition system and method, which can discard asynchronous trajectory data during the trajectory data acquisition stage, reduce invalid and deviation data caused by command-motion asynchrony from the source, and improve the effectiveness and accuracy of the original trajectory data.

[0029] Figure 1A schematic diagram of the structure of a fault data acquisition system provided in an embodiment of this application is shown. Figure 1 As shown, the fault data acquisition system provided in this application may include: a transmitter 110, a receiver 120, and a matching terminal 130.

[0030] The transmitter 110 is used to generate control commands in each sampling period, assign monotonically increasing sequence numbers to the control commands as synchronization markers, record the command transmission time as the first timestamp T1, and send the command data packet carrying the control command, sequence number, and T1 to the receiver 120.

[0031] The receiver 120 is used to receive the instruction data packet, parse it to obtain the sequence number, execute the operation according to the control instruction, and collect response execution data at the same sampling period as the sender. The collection time of the response execution data is recorded as the second timestamp T2, and the sequence number is associated with the response execution data. The sequence number, T2 and response execution data are associated and packaged to generate a feedback data packet.

[0032] Matching end 130 is used to acquire instruction data packets and corresponding feedback data packets, and to match control instructions with response execution data based on sequence numbers to form instruction-response synchronization data pairs. Each instruction-response synchronization data pair contains at least T1 and T2.

[0033] In this embodiment, the fault data acquisition system can collect trajectory data of the robot under fault conditions. Specifically, the core of the fault data acquisition system is a heterogeneous teleoperation synchronization control algorithm, the purpose of which is to establish a real-time alignment between the issuance of teleoperation commands and the actual movement of the robot joints, thereby reducing invalid data caused by asynchrony from the source.

[0034] Specifically, the transmitter 110 can generate control commands within each sampling period, assign monotonically increasing sequence numbers to the control commands as synchronization markers, and record the command transmission time as the first timestamp T1; it then sends a command data packet carrying the control command, sequence number, and T1 to the receiver 120. Upon receiving the command data packet, the receiver 120 parses it to obtain the sequence number, executes the operation according to the control command, and collects response execution data at the same sampling period as the transmitter, recording the collection time of the response execution data as the second timestamp T2, and associating the sequence number with the response execution data; finally, it packages the sequence number, T2, and response execution data together to generate a feedback data packet.

[0035] In other words, for any control command sent by the sending end, the response execution data collected by the receiving end has the same sequence number. Therefore, the matching end can obtain the command data packet and the corresponding feedback data packet, and match the control command with the response execution data based on the sequence number to form a command-response synchronization data pair. The command-response synchronization data pair contains at least T1 and T2. For example, control commands and response execution data with the same sequence number can be considered as a single command-response synchronization data pair.

[0036] The matching end 130 can be a sending end 110, a receiving end 120, or a third end independent of the sending end 110 and the receiving end 120. All of these are possible, and this application embodiment does not limit them.

[0037] In one implementation, after the matching end 130 obtains the instruction data packet and the corresponding feedback data packet, it first pairs the control instructions and response execution data with the same sequence number according to the sequence number to form an initial synchronization data pair; then, for any initial synchronization data pair, it calculates the instruction response delay Δt = T2 - T1 according to its corresponding T1 and T2; when Δt meets the preset condition, the initial synchronization data pair is determined as a valid instruction response synchronization data pair.

[0038] For example, when Δt is less than or equal to a preset duration threshold, the initial synchronization data pair can be determined as a valid instruction response synchronization data pair.

[0039] In other words, besides requiring identical sequence numbers, the instruction response synchronization data pair must also satisfy the condition that the time difference between the control instruction sending time and the response execution data acquisition time is less than a preset duration threshold; that is, the signal delay cannot exceed the preset duration. This further ensures the data consistency between the final instruction response synchronization data pairs and improves the data quality of the acquired data.

[0040] In one implementation, the matching end 130 is further configured to discard the initial synchronization data pair and resend the control command corresponding to the initial synchronization data pair when Δt does not meet the preset conditions. Specifically, when Δt does not meet the preset conditions, the initial synchronization data pair can be discarded, and the retry count of the control command corresponding to the initial synchronization data pair can be incremented by 1; when the retry count of the control command is less than or equal to the preset count, the control command can be resent; when the retry count of the control command reaches the preset count and still times out, the control command is marked as a matching failure.

[0041] If Δt does not meet the preset condition, it indicates that the signal delay of the initial synchronization data pair exceeds the preset duration. In this case, the initial synchronization data pair can be discarded, and the corresponding control command can be resent, i.e., the control command can be retried. The retry result can be used to determine whether the anomaly is in a single command or in the communication link. If any control command times out after a preset number of retries, it can be determined that the single control command is abnormal. In this case, the control command will no longer be retried, and it can be marked as a failed match.

[0042] When the matching end 130 determines that the Δt of N consecutive control commands is greater than the preset delay threshold, it can be determined that the communication link is abnormal. In this case, a system alarm can be triggered, and the start and end timestamps of the continuous timeouts can be recorded. All data within the time period defined by the start and end timestamps are marked as communication abnormal data.

[0043] In other words, the system can simultaneously record control command data sent by the teleoperation terminal (including target joint angles, target end-effector pose, etc.) and actual motion data fed back by the robot end (including actual joint angles, actual end-effector pose, motor current, etc.) within each sampling period, and assign a unified timestamp and synchronization tag to each pair of command-feedback data. The synchronization tag can use a monotonically increasing sequence number to ensure that each command and its corresponding motion response can be accurately matched in subsequent processing.

[0044] In addition, the system can have a built-in command response delay monitor to calculate in real time the time difference Δt between the sending of each teleoperation command to the robot and the actual response. For example, a command response delay threshold Δt_max = 300ms can be set, with the following processing rules: When Δt ≤ Δt_max: the instruction-response data pair is marked as "valid" and recorded normally; When Δt > Δt_max: the command-response data pair is marked as "timeout", and the system automatically triggers the acquisition retry mechanism: discard the current timeout data, resend the command and wait for a new response, with a maximum of 3 retries; When timeout occurs N times consecutively (e.g., N=4, 5, 6, etc.): the system issues an alarm and records the start and end timestamps of the abnormal segment for reference by the backend.

[0045] In one implementation, the matching end 130 can also add status tags to each finalized instruction response synchronization data pair to obtain an annotated synchronization data pair; the status tags can include at least a timestamp tag, an instruction response delay tag, a retry count tag, and a matching status tag. Thus, subsequent processing of the instruction synchronization data pairs can be performed based on the added status tags.

[0046] For example, the following status label (label field) can be added to and stored for each instruction response synchronization data pair:

[0047] In one implementation, the matching end 130 can also perform fault analysis on the instruction response data pair to detect whether a fault has occurred. When a fault is detected, the sampling frequency of the sampling period is adjusted according to the different stages of the fault. These different stages may include: the initial stage of the fault, the stable stage of the fault, and the recovery stage of the fault. The sampling frequency of the initial stage of the fault is higher than the sampling frequency of the recovery stage of the fault, and the sampling frequency of the recovery stage of the fault is higher than the sampling frequency of the stable stage of the fault.

[0048] It is understandable that the importance of trajectory data varies at different stages after a fault occurs (initial fault stage, stable fault stage, and recovery fault stage). For example, trajectory data in the initial fault stage can fully demonstrate the cause of the fault and is more likely to change, therefore it is the most important. Trajectory data in the recovery fault stage can also reflect the fault repair progress to some extent, so its importance is second. In comparison, trajectory data in the stable fault stage is relatively stable, with less data variation, and is therefore the least important.

[0049] Therefore, in this embodiment of the application, in order to save data storage resources and considering the special characteristics of robot failure scenarios, a dynamic adjustment logic for the sampling frequency can be designed. For example, the specific rules can be as follows:

[0050] In other words, when collecting data, the current stage of the fault can be determined first, and then sampling can be performed at the corresponding sampling frequency based on the current stage. The switching of the sampling frequency is automatically triggered by the fault status monitor, and a buffer can be used during the switching process to ensure that the frequency change does not introduce additional data interruptions.

[0051] In one implementation of this application, when the system detects a fault signal, it can also automatically generate a fault snapshot, recording the following key information:

[0052] A fault snapshot is a record of all robot state information at the exact moment a fault occurs. By storing a fault snapshot at the moment a fault is detected, relevant data at that moment can be recorded, facilitating subsequent fault analysis.

[0053] The system provided in this application can be applied to multiple scenarios, such as industrial robot production line fault recovery, service robot remote operation and maintenance, and special robot hazardous environment operation.

[0054] Specifically, in industrial robot production line fault recovery scenarios, such as in an automotive welding production line, a six-axis welding robot experiences a third-axis jamming due to reducer wear. The operator guides the robot remotely to complete the remaining welding tasks. The system provided in this application embodiment can collect trajectory data during this process to train an automatic recovery strategy for this fault mode, reducing downtime for similar faults in the future.

[0055] In remote maintenance scenarios for service robots, such as a delivery robot deployed in a shopping mall experiencing navigation deviation due to a circuit board malfunction, remote maintenance personnel can guide the robot to a repair point via teleoperation. The system provided in this application embodiment ensures data quality through latency monitoring and data acquisition retry even with significant remote communication latency (100-500ms), while simultaneously preserving the original fault state for subsequent circuit fault analysis.

[0056] In hazardous environments where specialized robots operate, such as nuclear power plant inspection robots experiencing abnormal movement due to sensor failure in high-radiation environments, operators can perform emergency evacuations remotely. This system uses high-frequency sampling to capture data throughout the entire sensor failure process, which will then be used to improve sensor redundancy design and fault detection algorithms.

[0057] In this embodiment, the sending end can generate control commands in each sampling period, assign a monotonically increasing sequence number to the control commands as a synchronization marker, and record the command transmission time as a first timestamp T1; the sending end sends a command data packet carrying the control command, sequence number, and T1 to the receiving end; subsequently, after receiving the command data packet, the receiving end can parse to obtain the sequence number, execute the operation according to the control command, and collect response execution data at the same sampling period as the sending end, recording the collection time of the response execution data as a second timestamp T2, associating the sequence number with the response execution data; the sequence number, T2, and response execution data are then packaged together. A feedback data packet is generated. Finally, the matching end can obtain the instruction data packet and the corresponding feedback data packet. Based on the sequence number, the control instruction and response execution data are matched to form an instruction-response synchronization data pair. The instruction-response synchronization data pair contains at least T1 and T2. That is to say, the instruction data packet and the feedback data packet can be accurately synchronized during the fault data acquisition stage to obtain an instruction-response synchronization data pair that is completely synchronized. This reduces invalid and biased data caused by instruction-motion asynchrony from the source, improves the effectiveness of the original trajectory data, and thus improves the data quality of the trajectory data collected under robot fault conditions.

[0058] Correspondingly, such as Figure 2 The diagram illustrates a flowchart of a fault data acquisition method provided in an embodiment of this application. The method includes the following steps: S210: Generate a control command in each sampling period, assign a monotonically increasing sequence number to the control command as a synchronization marker, record the command transmission time as the first timestamp T1, and send out the command data packet carrying the control command, the sequence number, and T1; S220: Receive the instruction data packet, parse to obtain the sequence number, execute the operation according to the control instruction, and collect response execution data with the same sampling period as the sending side, record the collection time of the response execution data as the second timestamp T2, associate the sequence number with the response execution data; associate and package the sequence number, the T2 and the response execution data to generate a feedback data packet; S230: Obtain the instruction data packet and the corresponding feedback data packet, and match the control instruction with the response execution data based on the sequence number to form an instruction-response synchronization data pair, wherein the instruction-response synchronization data pair includes at least T1 and T2.

[0059] In one embodiment of this application, the step of obtaining the instruction data packet and the corresponding feedback data packet, and matching the control instruction with the response execution data based on the sequence number to form an instruction-response synchronization data pair includes: The instruction data packet and the corresponding feedback data packet are obtained. According to the sequence number, control instructions and response execution data with the same sequence number are paired to form an initial synchronization data pair. For any initial synchronization data pair, the instruction response delay Δt = T2 - T1 is calculated according to its corresponding T1 and T2. When Δt is less than or equal to a preset duration threshold, the initial synchronization data pair is determined as a valid instruction response synchronization data pair.

[0060] In one embodiment of this application, when Δt is less than or equal to a preset duration threshold, the initial synchronization data pair is discarded, and the corresponding control command is retried and counted. If the number of retries for the control command is less than or equal to the preset number, the control command is resent. If the control command times out after the preset number of retries, the control command will be marked as a failed match.

[0061] In one embodiment of this application, fault analysis is performed on the instruction response data to identify different periods of the fault, and the sampling frequency is adjusted according to the initial stage of the fault, the stable stage of the fault, and the recovery stage of the fault. The sampling frequency during the initial stage of the fault is greater than the sampling frequency during the fault recovery period, and the sampling frequency during the fault recovery period is greater than the sampling frequency during the fault stabilization period.

[0062] In this embodiment, the instruction data packet and feedback data packet can be precisely synchronized during the fault data acquisition stage to obtain instruction response synchronization data pairs that are completely synchronized with the instruction response. This reduces invalid and biased data caused by instruction-motion asynchrony from the source, improves the effectiveness of the original trajectory data, and thus improves the data quality of the trajectory data collected under robot fault conditions.

[0063] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application.

[0064] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0065] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A fault data acquisition system, characterized in that, The system includes a transmitter, a receiver, and a matching terminal; The transmitting end is configured to generate control commands in each sampling period, assign monotonically increasing sequence numbers to the control commands as synchronization markers, record the command transmission time as a first timestamp T1, and send the command data packet carrying the control commands, the sequence numbers, and T1 to the receiving end. The receiving end is used to receive the instruction data packet, parse it to obtain the sequence number, perform the operation according to the control instruction, collect response execution data with the same sampling period as the sending end, record the collection time of the response execution data as the second timestamp T2, and associate the sequence number with the response execution data. The sequence number, T2, and response execution data are associated and packaged to generate a feedback data packet; The matching end is used to obtain the instruction data packet and the corresponding feedback data packet, and match the control instruction with the response execution data based on the sequence number to form an instruction-response synchronization data pair. The instruction-response synchronization data pair includes at least T1 and T2.

2. The system according to claim 1, characterized in that, The matching end is specifically used to acquire the instruction data packet and the corresponding feedback data packet, and pair control instructions and response execution data with the same sequence number according to the sequence number to form an initial synchronization data pair; for any initial synchronization data pair, calculate the instruction response delay Δt = T2 - T1 according to its corresponding T1 and T2; when the Δt meets the preset condition, the initial synchronization data pair is determined as a valid instruction response synchronization data pair.

3. The system according to claim 2, characterized in that, The matching end is specifically used to determine the initial synchronization data pair as a valid instruction response synchronization data pair when the Δt is less than or equal to a preset duration threshold.

4. The system according to claim 2, characterized in that, The matching end is also used to discard the initial synchronization data pair and resend the control command corresponding to the initial synchronization data pair when the Δt does not meet the preset condition.

5. The system according to claim 4, characterized in that, The maximum number of times the control command can be resent is a preset number; The matching end is specifically used to discard the initial synchronization data pair and increment the retry count of the control command corresponding to the initial synchronization data pair by 1 when the Δt does not meet the preset condition. If the number of retries for the control command is less than or equal to the preset number, the control command is resent. If the control command times out after the preset number of retries, the control command will be marked as a failed match.

6. The system according to claim 5, characterized in that, The matching end is also used to add a status label to each instruction response synchronization data pair to obtain an annotated synchronization data pair; the status label includes at least a timestamp label, an instruction response delay label, a retry count label, and a matching status label.

7. The system according to claim 2, characterized in that, The matching end is also used to trigger a system alarm and record the start and end timestamps of the consecutive timeouts when it is determined that the Δt of N consecutive control commands is greater than a preset delay threshold. All data within the time period defined by the start timestamp and the end timestamp are marked as communication anomaly data.

8. The system according to claim 2, characterized in that, The matching end is also used to perform fault analysis on the instruction response data pair to detect whether a fault has occurred; When a fault is detected, the sampling frequency of the sampling period is adjusted according to the different periods in which the fault occurs.

9. The system according to claim 8, characterized in that, The different periods include: the initial stage of the fault, the stable stage of the fault, and the recovery stage of the fault. The sampling frequency during the initial stage of the fault is greater than the sampling frequency during the fault recovery period, and the sampling frequency during the fault recovery period is greater than the sampling frequency during the fault stabilization period.

10. The system according to any one of claims 1-9, characterized in that, The matching end is the sending end, the receiving end, or a third end independent of the sending end and the receiving end.

11. A method for acquiring fault data, characterized in that, The method includes: In each sampling period, a control command is generated, a monotonically increasing sequence number is assigned to the control command as a synchronization marker, and the command transmission time is recorded as the first timestamp T1; the command data packet carrying the control command, the sequence number, and T1 is sent out. The system receives the instruction data packet, parses it to obtain the sequence number, executes the operation according to the control instruction, and collects response execution data at the same sampling period as the sending side. The collection time of the response execution data is recorded as the second timestamp T2, and the sequence number is associated with the response execution data. The sequence number, the T2, and the response execution data are associated and packaged to generate a feedback data packet. The instruction data packet and the corresponding feedback data packet are obtained. The control instruction and the response execution data are matched based on the sequence number to form an instruction-response synchronization data pair. The instruction-response synchronization data pair includes at least T1 and T2.

12. The method according to claim 11, characterized in that, The steps of acquiring the instruction data packet and the corresponding feedback data packet, and matching the control instruction with the response execution data based on the sequence number to form an instruction-response synchronization data pair include: The instruction data packet and the corresponding feedback data packet are obtained. According to the sequence number, control instructions and response execution data with the same sequence number are paired to form an initial synchronization data pair. For any initial synchronization data pair, the instruction response delay Δt = T2 - T1 is calculated according to its corresponding T1 and T2. When Δt is less than or equal to a preset duration threshold, the initial synchronization data pair is determined as a valid instruction response synchronization data pair.

13. The method according to claim 12, characterized in that, The method further includes: When Δt is less than or equal to a preset duration threshold, the initial synchronization data pair is discarded, and the corresponding control command is retried. If the number of retries for the control command is less than or equal to the preset number, the control command will be resent. If the control command times out after the preset number of retries, the control command will be marked as a failed match.

14. The method according to claim 12, characterized in that, The method further includes: The command response data is used to perform fault analysis to identify the different stages of the fault, and the sampling frequency is adjusted according to the initial stage of the fault, the stable stage of the fault, and the recovery stage of the fault. The sampling frequency during the initial stage of the fault is greater than the sampling frequency during the fault recovery period, and the sampling frequency during the fault recovery period is greater than the sampling frequency during the fault stabilization period.

Images