Distributed fault recording data acquisition and synchronization method, system and device and storage medium

Abstract

The invention relates to the technical field of fault recording data acquisition, in particular to a distributed fault recording data acquisition and synchronization method, system and device and a storage medium. Establishing network communication connection between the distributed wave recording device and the central server, configuring communication parameters, and responding to a wave recording event trigger source to start a data acquisition request; performing communication health degree evaluation on the target wave recording device, and judging a communication state through dual verification of network connectivity and port availability; when a transmission condition is met, a calling instruction is sent to a target device to obtain a wave recording file list and receive data, the data is transmitted to a central database, and a synchronization strategy of time sequence sorting and integrity verification is executed; and executing dynamic switching between the main node and the standby node based on the operation state of the service node in a redundant deployment environment. Unified acquisition, ordered synchronization and reliable storage of data of a plurality of wave recording devices are realized, and the requirements of power system fault analysis on data integrity and timeliness are met.

Description

Technical Field

[0001] This invention relates to the field of fault waveform data acquisition technology, and in particular to a distributed fault waveform data acquisition and synchronization method, system, device and storage medium. Background Technology

[0002] Fault recording devices are important equipment for recording the instantaneous changes in electrical quantities during a fault in a power system. They play a vital role in fault analysis, relay protection assessment, and safe operation of the power grid. Traditional fault recording devices operate in a stand-alone mode, with each device storing fault data locally. Maintenance personnel need to manually read the data on-site or remotely log in to each device to obtain the recording files. However, this method suffers from problems such as low data acquisition efficiency and overly fragmented historical data management.

[0003] With the increasing number of substations, dozens or even hundreds of waveform recording devices may be distributed in a single power plant or power supply area. If a large-scale fault occurs in the power grid, it is necessary to retrieve waveform recording data from multiple substations simultaneously for comprehensive analysis. However, the traditional method of calling each device one by one is time-consuming and labor-intensive, and cannot meet the needs of rapid fault location. At the same time, the data formats, storage locations, and access methods of each waveform recording device are different, which makes it difficult to manage and preserve the data in a unified manner. Although some existing fault waveform recording network devices can realize remote retrieval of data, they still have the following problems in terms of data acquisition, synchronization of data from multiple devices, and continuity of operation.

[0004] First, the lack of communication status verification before data retrieval makes data transmission prone to failure when the network is abnormal or the waveform recording device port is unavailable, and it is difficult to detect and locate the problem in a timely manner. Second, data from different waveform recording devices have disordered record order in the database in the time dimension, which affects the accuracy of fault timing analysis. Third, the common use of a single server architecture means that once the server fails, the entire data acquisition service will be interrupted, which cannot meet the high availability requirements of the power system.

[0005] Furthermore, in actual operation and maintenance, network communication between the waveform recording device and the central server may be interrupted due to reasons such as equipment restart, network maintenance, and switch failure. The existing system lacks automatic recovery of waveform recording data generated during communication interruption, requiring operation and maintenance personnel to manually check and supplement it, which increases the complexity of operation and maintenance work. At the same time, with the continuous growth of waveform recording data, data integrity verification and identification of missing data have also become important operation and maintenance issues. Summary of the Invention

[0006] In view of the problems existing in the prior art, the present invention is proposed.

[0007] Therefore, the problem to be solved by this invention is how to address the issues of communication reliability verification, distributed data synchronization management, and service continuity assurance in existing fault recording data acquisition systems.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, embodiments of the present invention provide a distributed fault waveform recording data acquisition and synchronization method, which includes: establishing a network communication connection between a distributed waveform recording device and a central server, configuring communication parameters for each waveform recording device, responding to a waveform recording event triggering source, and the waveform recording event triggering source initiating a data acquisition request to the target waveform recording device; A communication health assessment is performed on the target waveform recording device. The communication health assessment uses a dual verification method to determine whether the communication status of the target waveform recording device meets the data transmission conditions. When the communication status meets the data transmission conditions, a waveform recording file summoning command is sent to the target waveform recording device to obtain the waveform recording file list and receive the waveform recording data file returned by the waveform recording device. The received waveform recording data file is then transmitted to the central database for storage, and a data synchronization strategy is executed. When there are redundant deployment nodes on the central server, dynamic switching is performed between the primary service node and the backup service node based on the running status of the service node to obtain synchronous data collection services.

[0009] As a preferred embodiment of the distributed fault waveform recording data acquisition and synchronization method of the present invention, the waveform recording event triggering source includes an automatic triggering method based on preset rules and a manual triggering method based on user instructions; The waveform recording event trigger source initiates a data acquisition request to the target waveform recording device, including, in automatic triggering mode, monitoring the fault event signal reported by the waveform recording device, and when a fault event is detected, automatically generating a data acquisition request and identifying the faulty waveform recording device as the target waveform recording device. In manual trigger mode, the system receives a call command from the user who selects a specific waveform recording device through the monitoring interface and identifies the waveform recording device selected by the user as the target waveform recording device. Based on the urgency of the data collection request, a collection priority is assigned to different triggering methods, with priority given to collection requests automatically triggered by fault events.

[0010] As a preferred embodiment of the distributed fault recording data acquisition and synchronization method of the present invention, the step of performing a communication health assessment on the target recording device includes sending a network connectivity probe message to the target recording device, receiving the probe response and recording the response time, and determining that the network connectivity is abnormal when no response is received within a preset time. Under normal network connectivity, initiate a connection request to the data transmission port of the target waveform recording device to verify whether the port is open and can establish a data channel. Based on the network connectivity verification results and port availability verification results, the communication health level is comprehensively judged. When both verifications pass, the communication status is determined to meet the data transmission conditions. When either verification fails, abnormal information is recorded and an alarm is triggered.

[0011] The beneficial effects of this preferred technical solution are as follows: Basic network-level verification is completed by sending network connectivity probe messages to the target waveform recording device, avoiding invalid data transmission requests when the network is down, thus saving system resources; after normal network connectivity, a connection request is further initiated to the data transmission port to verify the port's open status, ensuring the availability of the data channel and preventing data transmission failures due to port closure or occupation; the results of the two verifications are combined to form a communication health level, and abnormal information is recorded and an alarm is triggered when either verification fails, achieving accurate assessment of the communication status.

[0012] As a preferred embodiment of the distributed fault waveform recording data acquisition and synchronization method of the present invention, the step of obtaining the waveform recording file list and receiving the waveform recording data file returned by the waveform recording device includes receiving waveform recording data files in multiple formats returned by the waveform recording device, wherein the multiple formats include parameter configuration files, waveform recording configuration files, data files and waveform files; Different formats of waveform recording data files are parsed and processed separately to extract key information from each file and establish the relationship between the files; The parsed waveform recording data files are stored in a designated directory on the file server, categorized by waveform recording device and data type for easy data retrieval and download later.

[0013] As a preferred embodiment of the distributed fault recording data acquisition and synchronization method of the present invention, the execution of the data synchronization strategy includes receiving recording data files from different recording devices and parsing the timestamp information and device identification information of each data file. Data files from multiple waveform recording devices are sorted in time sequence according to timestamp information to ensure that data is stored in the central database in the order of actual occurrence time. Check the integrity of data files, verify whether the file format and file size meet the preset specifications, mark incomplete or abnormally formatted files and trigger a re-call; During database storage, the correspondence between the waveform recording device and the data file is maintained, and the source device, acquisition time, and synchronization status of the data are recorded to achieve data traceability.

[0014] The beneficial effects of this preferred technical solution are as follows: by parsing the timestamp information and device identification information of each waveform recording data file, a dual index of time and space dimensions is established for the data; data files from multiple distributed waveform recording devices are sorted according to the timestamps to ensure that the data in the central database is stored in the order of actual fault occurrence time, avoiding data sequence disorder caused by network transmission delays or concurrent acquisition; the integrity of data files is detected and the file format and size are verified, and abnormal files are triggered for re-recall to ensure the quality of the data entering the database; the correspondence between waveform recording devices and data files is maintained and the acquisition time and synchronization status are recorded to achieve full traceability of data.

[0015] As a preferred embodiment of the distributed fault recording data acquisition and synchronization method of the present invention, the step of performing dynamic switching between the main service node and the backup service node includes real-time monitoring of the operating status of the main service node, including the operating status of the communication program, the database service status and the file service status. When an anomaly is detected in the primary service node, the backup service node is activated to take over the data acquisition and synchronization tasks, and the communication connection of the waveform recording device is switched to the backup service node. During the switchover process, the configuration information and unfinished data transmission tasks between the primary and backup service nodes are synchronized to ensure a smooth transition of service switching. After the primary service node recovers, a service rollback operation is performed to return the data collection and synchronization tasks to the primary service node and update the data on the standby service node to the latest state.

[0016] As a preferred embodiment of the distributed fault waveform recording data acquisition and synchronization method of the present invention, it further includes: during the data acquisition process, monitoring the communication status between each waveform recording device and the central server, and when a communication interruption is detected, recording the interruption time and the interruption reason; In the event of data transmission failure due to communication interruption, a data recovery process is automatically triggered after communication is restored to obtain the waveform data generated during the interruption. The monitoring interface displays the communication status and data acquisition progress of each waveform recording device in real time, and sends alarm information to maintenance personnel when abnormal situations occur. Regularly perform data integrity checks by comparing the list of waveform recording files stored locally on the waveform recording device with the stored records in the central database to identify and supplement missing waveform recording data.

[0017] Secondly, embodiments of the present invention provide a distributed fault recording data acquisition and synchronization system, which includes a communication management module for establishing a network communication connection between the distributed recording devices and the central server, and configuring the communication parameters of each recording device. The trigger response module is used to respond to the waveform recording event trigger source and initiate a data acquisition request to the target waveform recording device. The health assessment module is used to perform a communication health assessment on the target waveform recording device and determine whether the communication status of the target waveform recording device meets the data transmission conditions. The data retrieval module is used to send a waveform recording file retrieval command to the target waveform recording device, obtain a list of waveform recording files, and receive the waveform recording data files returned by the waveform recording device. The data synchronization module is used to transfer the received waveform data files to the central database for storage and to execute the data synchronization strategy. The node switching module is used to dynamically switch between the primary service node and the backup service node based on the running status of the service node, so as to obtain the synchronous service of data collection.

[0018] Thirdly, embodiments of the present invention provide a computer device, including a memory and a processor, wherein the memory stores a computer program, wherein: when the computer program instructions are executed by the processor, they implement the steps of the distributed fault recording data acquisition and synchronization method as described in the first aspect of the present invention.

[0019] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program instructions are executed by a processor, they implement the steps of the distributed fault recording data acquisition and synchronization method as described in the first aspect of the present invention.

[0020] The beneficial effects of this invention are as follows: By establishing a network communication connection between the distributed waveform recording device and the central server and responding to waveform recording event triggering sources, this invention solves the problems of delayed fault response and scattered data management among multiple devices in traditional waveform recording data acquisition; by performing a communication health assessment using a dual verification method of network connectivity and port availability, it confirms that the communication status meets the conditions before data transmission, avoiding invalid transmission and data loss due to network anomalies or port unavailability, thus reducing the acquisition failure rate; by sending a summoning command to the target waveform recording device to obtain the waveform recording file and executing a data synchronization strategy, it sorts data from multiple distributed devices by timestamp and maintains the mapping relationship between devices and files, solving the problems of disordered data timing and untraceable sources in a distributed environment, ensuring that data is stored in the order of actual fault occurrence; through dynamic switching of primary and backup service nodes, when the primary node fails, the backup node takes over the task and synchronizes configuration information and unfinished tasks, solving the service interruption problem caused by single point of failure and ensuring the continuous availability of data acquisition services. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart of a distributed fault waveform data acquisition and synchronization method; Figure 2 A diagram of a computer device for a distributed fault recording data acquisition and synchronization method; Figure 3 This is a network topology diagram for a distributed fault recording data acquisition and synchronization method. Detailed Implementation

[0023] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0024] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0025] Secondly, the term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places throughout this specification does not necessarily refer to the same embodiment, nor is it a single embodiment or an embodiment selectively excluded from other embodiments.

[0026] Example 1 Reference Figure 1 - Figure 2 This is the first embodiment of the present invention, which provides a distributed fault recording data acquisition and synchronization method, including: S100: Establishes a network communication connection between the distributed waveform recording device and the central server, configures the communication parameters of each waveform recording device, responds to the waveform recording event trigger source, and the waveform recording event trigger source initiates a data acquisition request to the target waveform recording device.

[0027] S200: Perform a communication health assessment on the target waveform recording device. The communication health assessment uses a dual verification method to determine whether the communication status of the target waveform recording device meets the data transmission conditions.

[0028] S300: When the communication status meets the data transmission conditions, send a waveform recording file summoning command to the target waveform recording device, obtain the waveform recording file list and receive the waveform recording data file returned by the waveform recording device, transmit the received waveform recording data file to the central database for storage, and execute the data synchronization strategy.

[0029] S400: When there are redundant deployment nodes on the central server, dynamic switching is performed between the primary service node and the backup service node based on the running status of the service node to obtain synchronous data collection services.

[0030] It should be noted that in distributed fault waveform recording data acquisition scenarios, multiple waveform recording devices are distributed in different substations or power facilities, and the network environment, equipment status, and data generation time of each device differ. This technical solution adopts a flexible response method based on waveform recording event triggering sources, distinguishing between automatic fault triggering and manual summoning modes, and assigning acquisition priorities to different modes. Through dual verification of communication health assessment, connectivity and port availability are confirmed at both the network layer and the transport layer to avoid resource waste caused by blindly initiating data transmission. A data synchronization strategy is established through dual indexing of timestamps and device identifiers to ensure the temporal consistency and source traceability of distributed data in the central database. Dynamic switching of primary and backup service nodes ensures the continuity of acquisition services when the server is abnormal.

[0031] S100 establishes a network communication connection between the distributed waveform recording device and the central server and configures communication parameters to solve the problem of unified access for multiple waveform recording devices. By responding to waveform recording events, it triggers the source to initiate data acquisition requests, achieving timely fault response and flexible scheduling of acquisition tasks. S200 performs a communication health assessment on the target waveform recording device, solving the problem of uncertain communication status before data transmission through dual verification of network connectivity and port availability, and avoiding invalid transmissions in the event of communication anomalies. S300 sends a waveform recording file recall command and receives waveform recording data when the communication status meets the requirements. It executes a data synchronization strategy to perform time-series sorting and integrity verification on multi-source data, solving the problems of time-series consistency and quality assurance of distributed data. S400 performs dynamic switching between primary and backup nodes based on the service node's operating status, solving the problem of service interruption caused by single point of failure and ensuring the continuity and reliability of data acquisition services.

[0032] Example 2 Reference Figure 1 - Figure 3 This is the second embodiment of the present invention.

[0033] In this embodiment, step S100 establishes a network communication connection between the distributed waveform recording device and the central server, configures the communication parameters of each waveform recording device, and responds to the waveform recording event triggering source. The waveform recording event triggering source initiates a data acquisition request to the target waveform recording device, including the following A1 steps: A1: The triggering sources for waveform recording events include automatic triggering based on preset rules and manual triggering based on user commands; The waveform recording event trigger source initiates a data acquisition request to the target waveform recording device, including, in automatic triggering mode, monitoring the fault event signal reported by the waveform recording device, and when a fault event is detected, automatically generating a data acquisition request and identifying the faulty waveform recording device as the target waveform recording device. In manual trigger mode, the system receives a call command from the user who selects a specific waveform recording device through the monitoring interface and identifies the waveform recording device selected by the user as the target waveform recording device. Based on the urgency of the data collection request, a collection priority is assigned to different triggering methods, with priority given to collection requests automatically triggered by fault events.

[0034] Specifically, in automatic triggering mode, the communication program monitors the fault event signals reported by each waveform recording device in real time. When a waveform recording device detects a power grid fault, the fault judgment logic inside the device generates a fault event identifier, which includes the fault type code, the timestamp of the occurrence time, the device number, and the fault level. The communication program of the central server receives the fault event signal through the TCP protocol, parses the data packet of the signal message, extracts the device number field from the message header, and maps the number to the corresponding waveform recording device in the configuration table. Specifically, the device number uses 16-bit binary encoding, with the first 8 bits representing the substation area code and the last 8 bits representing the device serial number. The area code and serial number are extracted through bitwise operations to quickly locate the physical location and network address of the faulty waveform recording device.

[0035] Once the target waveform recording device is identified, a data acquisition request is automatically generated. This request includes a task number, the target device's IP address, the data transmission port, the call priority, and the timeout duration. The task number is generated using a combination of a timestamp and a random number to ensure the uniqueness of each acquisition task. The call priority is set according to the fault level: high priority 1 for severe faults (such as main transformer tripping or bus faults), medium priority 2 for general faults (such as line reclosing or overload alarms), and low priority 3 for early warning events.

[0036] In manual triggering mode, maintenance personnel select a specific waveform recording device and issue a summoning command through the monitoring interface: The monitoring interface graphically displays a list of all online waveform recording devices, showing the device name, the substation to which it belongs, the online status, and the most recent waveform recording time; After the user selects one or more waveform recording devices and clicks the summoning button, the interface program packages the device number selected by the user into a summoning command and sends it to the application service program on the central server via the HTTP protocol. After receiving the summoning command, the application service program traverses the list of device numbers, generates an independent data acquisition request for each device, and pushes the request into the task queue.

[0037] To ensure timely retrieval of emergency fault data, a priority scheduling algorithm is used to process data acquisition tasks: the task queue adopts a priority queue data structure, and the tasks in the queue are sorted according to their priority from high to low. When a new task is added, its priority is compared with the existing tasks in the queue, and the new task is inserted into the appropriate position. For tasks with the same priority, they are arranged in order of their generation time, that is, the tasks generated first are processed first. The task scheduler takes the highest priority task from the head of the queue and executes it. After the current task is completed, the next task is retrieved.

[0038] In this embodiment, step S200 performs a communication health assessment on the target waveform recording device. The communication health assessment uses a dual-verification method to determine whether the communication status of the target waveform recording device meets the data transmission conditions, including the following step B1: B1: Perform a communication health assessment on the target waveform recording device, including sending a network connectivity probe message to the target waveform recording device, receiving the probe response and recording the response time, and determining that the network connectivity is abnormal when no response is received within a preset time. Under normal network connectivity, initiate a connection request to the data transmission port of the target waveform recording device to verify whether the port is open and can establish a data channel. Based on the network connectivity verification results and port availability verification results, the communication health level is comprehensively judged. When both verifications pass, the communication status is determined to meet the data transmission conditions. When either verification fails, abnormal information is recorded and an alarm is triggered.

[0039] Specifically, the network diagnostic program is invoked to send ICMP Ping messages to the IP address of the target waveform recording device. The CMP message packet size is set to 64 bytes, including an 8-byte ICMP header and a 56-byte data payload. The data payload is filled with a fixed test data pattern. Three ICMP Ping messages are sent consecutively, with a 1-second interval between each message, to avoid the impact of network congestion on the test results.

[0040] A timer is started to record the sending time for each ICMP request message sent. When an ICMP echo reply message is received from the target device, the reception time is recorded. The round-trip time (RTT) is calculated as follows: in, and The time precision is in milliseconds. The round-trip delays obtained from the three tests are denoted as follows: , , The average round-trip time is calculated as follows: Simultaneously, the standard deviation σ of the round-trip delay is calculated to assess network stability. Preset network connectivity thresholds, including the maximum allowable round-trip time T. max and maximum allowable packet loss rate P max By default, T max Set to 500 milliseconds, P max The threshold is set to 33% (meaning that one out of three packets can be lost). The decision logic is as follows: If no response is received for any of the three ICMP request messages, the network connectivity is considered abnormal, and the exception code NET is logged. UNREACHABLE ; If one or two response messages are received, calculate the packet loss rate P = (3-N) / 3, where N is the number of response messages received. If P > P0 max The network connectivity was determined to be unstable, and the exception code was logged as NET. UNSTABLE ; If three response messages are received, check the average round-trip time. >T max The system determined that network connectivity latency was too high and logged the exception code as NET. HIGH ;like ≤T max If σ < 100 milliseconds, the network connectivity is considered normal.

[0041] When network connectivity is abnormal, the abnormal information is written to the log file. The log record includes timestamp, target device IP address, abnormal code, round-trip time data and packet loss rate. Alarm information is pushed to the monitoring interface. The alarm content includes device name and network status description. For devices with abnormal network connectivity, the subsequent data collection process is terminated to avoid invalid data transmission attempts.

[0042] Specifically, the data transmission service of the waveform recording device runs on a specific TCP port, commonly 8080 or 9000: the data transmission port number of the target device is read from the configuration file, and the Socket programming interface is called to initiate a TCP connection request to that port. The connection request process includes a three-way handshake: the client sends a SYN packet, the server responds with a SYN-ACK packet, and the client sends an ACK packet to complete the connection establishment.

[0043] Set the timeout for the connection request to 10 seconds. After initiating the connection request, wait for the server's response. If a SYN-ACK packet is successfully received and a three-way handshake is completed within 10 seconds, the port is determined to be open normally, a data channel is established, and the connection establishment time and the assigned local port number are recorded. This connection will be used for subsequent data transmission.

[0044] If the three-way handshake cannot be completed within 10 seconds, log the corresponding exception code according to the different reasons for failure: If an RST (reset) message is received, it indicates that the target port exists but the service program refuses to connect, and the exception code is recorded as PORT. REFUSED ; If an ICMP port unreachable message is received, it means the target port is not open or the firewall is blocking access. The error code is logged as PORT. CLOSED ; If the connection times out without receiving any response, it indicates a problem with the network path or that the target service is not running. The exception code will be PORT. TIMEOUT .

[0045] If port availability verification fails, try connecting to the backup port. Some waveform recording devices are configured with dual primary and backup ports, so that the backup port can be switched when the primary port fails.

[0046] Read the backup port number from the configuration table, repeat the connection request process described above, and if the backup port connection is successful, update the current working port of the target device to the backup port and continue the subsequent data acquisition process.

[0047] Specifically, based on the results of network connectivity verification and port availability verification, the communication health level is comprehensively judged: the communication health level is defined as five levels: Excellent, Good, Average, Poor, and Abnormal. The judgment criteria are as follows: Excellent level: Network connectivity is normal ( <100 milliseconds and packet loss rate of 0), port availability is normal (connection establishment time <3 seconds), port response latency <50 milliseconds; Good level: Network connectivity is normal ( <300 milliseconds and packet loss rate of 0), port availability is normal (connection establishment time <5 seconds), port response latency <100 milliseconds; General level: Network connectivity is normal. <500 milliseconds and packet loss rate ≤33%), port availability is normal (connection establishment time <10 seconds), port response latency <500 milliseconds; Poor level: Unstable network connectivity ( <500 milliseconds but packet loss rate >33%, or (>500 milliseconds but packet loss rate ≤33%), port availability is normal; Anomaly level: Network connectivity anomaly or port availability anomaly.

[0048] When the communication health level is excellent, good, or average, the communication status is determined to meet the data transmission conditions, and the data retrieval process continues. When the communication health level is poor, a warning message is issued, but data transmission is still attempted, while the number of retransmissions and the timeout duration are increased. When the communication health level is abnormal, the data acquisition process is terminated, detailed abnormal information is recorded, and an alarm is triggered.

[0049] In this embodiment, in step S300, when the communication status meets the data transmission conditions, a waveform recording file retrieval command is sent to the target waveform recording device, a waveform recording file list is obtained, and the waveform recording data file returned by the waveform recording device is received. The received waveform recording data file is then transmitted to the central database for storage, and a data synchronization strategy is executed, including the following steps C1-C2: C1: Obtain a list of waveform recording files and receive waveform recording data files returned by the waveform recording device, including receiving waveform recording data files in various formats returned by the waveform recording device, such as parameter configuration files, waveform recording configuration files, data files, and waveform files; Different formats of waveform recording data files are parsed and processed separately to extract key information from each file and establish the relationship between the files; The parsed waveform recording data files are stored in a designated directory on the file server, categorized by waveform recording device and data type for easy data retrieval and download later.

[0050] Specifically, the summoning command uses a custom application layer protocol. The protocol message structure includes two parts: a message header and a message body. The message header has a fixed length of 32 bytes and includes a start identifier (4 bytes, fixed value 0xFFFEFDFC), a protocol version number (2 bytes), a message type (2 bytes, summoning command type is 0x0001), a message length (4 bytes, indicating the number of bytes in the message body), a task number (8 bytes), a device number (8 bytes), and a checksum (4 bytes). The message body contains summoning parameters, such as time range and file type filtering conditions.

[0051] After receiving the call command, the waveform recording device scans the local storage directory, reads the metadata information of the waveform recording files, and generates a list of waveform recording files. The file list is organized in XML format, and each file record contains the file name, file type, generation time, file size, and file path. The file type field uses enumerated values: 1 represents the parameter configuration file (.par), 2 represents the waveform recording configuration file (.cfg), 3 represents the data file (.dat), and 4 represents the waveform file (.dmf). The generation time is represented in ISO8601 format, such as "2025-03-09T14:30:15Z", and the file size is in bytes.

[0052] The recording device encapsulates the file list into a response message and returns it to the central server. The header structure of the response message is the same as the call command, the message type field is 0x8001 (indicating a call response), and the message body contains file list data in XML format. After receiving the response message, the central server first verifies the checksum of the message header to ensure that no errors have occurred during data transmission.

[0053] After verification, the XML data is parsed, each record in the file list is extracted, and the files to be summoned are filtered according to the user-defined filtering conditions, including time range, file type, and file size. For example, if the user specifies to summon all data files and waveform files generated between 14:00 and 15:00 on March 9, 2025, the file list is traversed, the generation time and type of each file are compared, and files that meet the conditions are added to the summoning queue.

[0054] For waveform recording data files of different formats, corresponding parsing and processing methods are adopted: the parameter configuration file (.par) is stored in INI format and contains the configuration parameters of the waveform recording device, such as sampling frequency, number of channels, trigger conditions, etc.; the INI file parsing library is called to read each parameter item, extract key parameter values ​​and store them in the parameter table of the database; the waveform recording configuration file (.cfg) adopts the COMTRADE standard format and contains channel configuration information, sampling rate information and trigger time information; the file header is parsed according to the COMTRADE standard to extract information such as channel name, unit, range, etc., and a channel index table is established.

[0055] The data file (.dat) contains the actual waveform data, stored in binary format. The file structure is a fixed-length sequence of data records. Each record contains a timestamp and the sampled values ​​for each channel. The timestamp is represented by a 64-bit integer in microseconds, and the sampled values ​​are represented by 16-bit or 32-bit integers depending on the channel type. The data file is read as a byte stream. Each record is parsed according to the channel configuration information, and the sampled values ​​are converted into physical quantities (such as voltage and current) using the following formula: Where ADC is the sampled value (integer). The reference voltage (volts) is n, the ADC bit depth (16 or 32), and K is the channel gain coefficient.

[0056] C2: Executes data synchronization strategies, including receiving waveform data files from different waveform recording devices and parsing the timestamp information and device identification information of each data file; Data files from multiple waveform recording devices are sorted in time sequence according to timestamp information to ensure that data is stored in the central database in the order of actual occurrence time. Check the integrity of data files, verify whether the file format and file size meet the preset specifications, mark incomplete or abnormally formatted files and trigger a re-call; During database storage, the correspondence between the waveform recording device and the data file is maintained, and the source device, acquisition time, and synchronization status of the data are recorded to achieve data traceability.

[0057] Specifically, the timestamp information and device identification information of each waveform data file are first parsed. The timestamp information is read from a fixed offset position in the header of the data file and is represented by an 8-byte long integer, recording the UTC (Coordinated Universal Time) time when the waveform is triggered. The device identification information is extracted from the file name or file header and is encoded in 16-bit binary code, with the first 8 bits being the substation code and the last 8 bits being the device serial number.

[0058] Because different recording devices have different network transmission delays, the order in which data files arrive at the central server may not be consistent with the actual order in which the faults occurred. Therefore, a timestamp-based sorting algorithm is used, and the specific steps are as follows: A temporary data buffer is created to store the metadata of all waveform data files received in the current batch. The metadata includes file identifier, trigger timestamp, device number, and file size. The data in the buffer is sorted in ascending order by timestamp using a quicksort algorithm. For a batch containing m files, the time complexity of sorting is O(m-log-m). For files with the same timestamp (which may come from different devices with the same fault), they are further sorted by the numerical value of the device number to ensure that the sorting result is deterministic and repeatable.

[0059] Data files are written to the central database in the sorted order. The database adopts a time-series database architecture (such as InfluxDB or TimescaleDB), which is specifically optimized for the storage and querying of time-series data. During the writing process, each file is assigned a unique storage identifier, which is generated by combining the device number, timestamp, and sequence number, and is encoded using a 64-bit integer to ensure uniqueness in massive amounts of data.

[0060] During the data writing process, the data file is subjected to integrity verification; integrity verification includes two aspects: file structure verification and data consistency verification. File structure verification is achieved by checking the identifier field in the file header. Different types of waveform recording files have specific file header identifiers. The first 8 bytes of the file are read and compared byte-by-byte with a predefined identifier template. For parameter configuration files, the identifier field is the hexadecimal value 0x50415253 (corresponding to the ASCII code "PARS"); for configuration files, the identifier field is 0x434F4D5452414445 (corresponding to "COMTRADE"); for data files, the identifier field is 0x44415441 (corresponding to "DATA"). If the identifier fields do not match, the file format is determined to be incorrect.

[0061] Data consistency verification is achieved by calculating a checksum of the file content. All data bytes of the file are read, and a cyclic redundancy check (CRC) algorithm is used to calculate the checksum. Assume the file contains n bytes, which are then... The check value c is calculated using polynomial division, and the generator polynomial is: Treat the file data sequence as a binary polynomial The polynomial term corresponding to the i-th byte is: The check value c is Divide by The remainder, that is: The calculated checksum is compared with the pre-stored checksum appended to the end of the file. If they match, it is determined that no data corruption occurred during file transfer; if they do not match, it is determined that the file is corrupted and needs to be retrieved.

[0062] To verify the file size, the theoretical file size is calculated based on the waveform recording configuration information: Assume the waveform recording device has k channels, each channel samples p data points, each sample point occupies q bytes (usually 2 or 4 bytes), and the file header occupies a fixed h bytes (usually 1024 bytes). Then the theoretical file size s is: Obtain the actual file size r (the number of bytes read from the file interface), and calculate the size deviation rate d: If the deviation rate d exceeds the threshold (set to 0.05, i.e. 5%), the file size is determined to be abnormal.

[0063] The size discrepancy may be caused by the following reasons: interrupted file transfer leading to incomplete reception, damaged storage medium of the recording device causing file truncation, or network transmission errors leading to data loss.

[0064] Files of abnormal size will not be added to the database, but will instead be marked as pending retransmission.

[0065] For files with incorrect formatting or corrupted data, file information is recorded in the retransmission queue. The retransmission queue uses a first-in, first-out (FIFO) data structure, and each record contains the file identifier, device number, exception type, detection time, and number of retransmissions.

[0066] The trigger time records the actual occurrence of the waveform recording event, and the synchronization time records the moment the file is successfully written to the database. The difference between the two timestamps reflects the end-to-end latency of data acquisition. Statistical analysis is performed on the latency; let the latency be t (in seconds), and calculate the mean μ and standard deviation σ of the latency. For a sample set containing N files, the mean latency is: The standard deviation of the delay is: When the delay time of a file exceeds the mean plus twice the standard deviation (i.e., t>μ+2σ), it is determined that there is an abnormal delay in the acquisition process of the file. Alarm information is recorded and the cause of the delay is analyzed (such as network congestion, excessive device load, insufficient server performance).

[0067] The synchronization status field uses an enumeration of values ​​to represent the synchronization stage of the file: 0 indicates pending synchronization (the file has been retrieved but has not started transmission), 1 indicates transmission in progress (the file is being transmitted over the network), 2 indicates verification in progress (the file has been received and is undergoing integrity verification), 3 indicates successful synchronization (the file has been verified and written to the database), and 4 indicates failed synchronization (the file verification or write operation failed).

[0068] In this embodiment, in step S400, when there are redundant deployment nodes on the central server, dynamic switching is performed between the primary service node and the backup service node based on the running status of the service nodes to obtain the data acquisition synchronization service, including the following steps D1-D2: D1: Perform dynamic switching between the primary service node and the backup service node, including real-time monitoring of the primary service node's operating status, including the communication program's operating status, database service status, and file service status; When an anomaly is detected in the primary service node, the backup service node is activated to take over the data acquisition and synchronization tasks, and the communication connection of the waveform recording device is switched to the backup service node. During the switchover process, the configuration information and unfinished data transmission tasks between the primary and backup service nodes are synchronized to ensure a smooth transition of service switching. After the primary service node recovers, a service rollback operation is performed to return the data collection and synchronization tasks to the primary service node and update the data on the standby service node to the latest state.

[0069] Specifically, a primary service node and a backup service node are deployed. Both nodes run the same software stack, including communication programs, database service programs, and file service programs. The primary service node undertakes all data acquisition and synchronization tasks, while the backup service node is in hot standby mode, continuously monitoring the operating status of the primary node and synchronizing key configuration data in real time.

[0070] Verification of the checksum ensures data integrity. Status information is parsed, and the health score of the master node is calculated. The health score uses a weighted comprehensive evaluation method. Let CPU utilization be u (a value from 0 to 100), memory utilization be v (a value from 0 to 100), disk space percentage be w (a value from 0 to 100), and the ratio of network connections to the maximum number of connections be z (a value from 0 to 1). Then, the health score E is calculated as follows: The score E ranges from 0 to 100, with a higher value indicating a healthier node operation.

[0071] When E < 50, the master node is determined to be in a high-load state; when E < 30, the master node is determined to be in an overload or abnormal state.

[0072] The backup node continuously tracks the score change trend. If the score is below 30 for 10 consecutive heartbeat cycles (i.e., 20 seconds), the backup node initiates an early warning program and sends an alarm to the monitoring system indicating that the primary node is in an abnormal state.

[0073] After determining that the primary node is faulty, the backup node performs the following verification steps to rule out false alarms: First, the backup node sends a TCP probe packet to the primary node to attempt to establish a connection, with a timeout of 5 seconds; if the TCP connection fails, the backup node sends an ICMP echo request to the primary node, with a timeout of 3 seconds; if the ICMP request also fails, the backup node confirms that the primary node is out of contact and immediately starts the automatic failover process.

[0074] The automatic switching process includes the following key steps: The first step is for the standby node to start all local service programs. Since the standby node is in hot standby mode, the service programs are loaded but not yet providing services. The standby node executes the service activation command, switching the communication program's listening port from closed to open, the database service from read-only mode to read-write mode, and the file service to accept upload and download requests.

[0075] The second step involves the backup node sending a server address update notification to all online waveform recording devices. The notification message is sent via broadcast or multicast to ensure all devices can receive it. The message content includes the new server IP address, data transmission port number, heartbeat reception port number, and configuration synchronization port number. Upon receiving the notification, the waveform recording device updates the server address parameters in its local configuration file, and subsequent data reporting and heartbeat signals are sent to the new address.

[0076] The third step involves the backup node recovering unfinished tasks from the task synchronization database. The task synchronization database is deployed on shared storage between the primary and backup nodes, or synchronized in real-time using a master-slave replication mechanism. The database records detailed information for each data acquisition task: task identifier, target device, task status (pending, in progress, completed, failed), list of transferred files, list of files to be transferred, and task progress.

[0077] After the switchover is complete, the standby node officially takes over the data acquisition and synchronization services, changing its role from standby node to primary node. The original primary node goes offline and runs in single-node mode. To ensure service continuity, the entire switchover process is completed within 30 seconds, and the data acquisition interruption time from when the standby node detects the primary node failure to when the service takeover is completed does not exceed half a minute.

[0078] Once the original primary node is repaired and restored to operation, a service rollback operation is performed: After the original primary node starts up, it first sends an online notification to the backup node (the current primary node). The notification contains the node identifier and running status information. After receiving the notification, the backup node starts monitoring the health score of the original primary node. The backup node continuously monitors for 60 heartbeat cycles (i.e., 120 seconds) and calculates the average and minimum scores of the original primary node during this period. If the average score is greater than 70 and the minimum score is greater than 60, it is determined that the original primary node has been stably restored and meets the rollback conditions.

[0079] The cutback process is as follows: The first step is for the standby node to stop receiving new data collection requests and announce that it has entered the switchback preparation state. Tasks that are in execution continue to be completed, and no new tasks are taken out from the task queue. The standby node waits for all tasks in execution to be completed, or sets a timeout period (such as 300 seconds). After the timeout, the unfinished tasks are forcibly terminated and the task status is recorded.

[0080] The second step is for the standby node to synchronize the data and configuration changes generated during the execution to the original master node. The synchronized content includes: newly collected waveform data files, newly added records in the database, changes to the configuration database, task execution logs and alarm records. After the data synchronization is completed, the standby node sends a synchronization completion confirmation to the original master node.

[0081] The third step is for each node to send a server address recovery notification to all waveform recording devices, notifying the devices to switch the data reporting address back to the original master node.

[0082] The fourth step is for the original master node to take over the data acquisition and synchronization services again, restore the master node role, and the standby node to close its external service ports, stop task scheduling, and return to standby status, while continuing to monitor the running status of the original master node.

[0083] D2: It also includes monitoring the communication status between each waveform recording device and the central server during the data acquisition process, and recording the interruption time and reason when a communication interruption is detected. In the event of data transmission failure due to communication interruption, a data recovery process is automatically triggered after communication is restored to obtain the waveform data generated during the interruption. The monitoring interface displays the communication status and data acquisition progress of each waveform recording device in real time, and sends alarm information to maintenance personnel when abnormal situations occur. Regularly perform data integrity checks by comparing the list of waveform recording files stored locally on the waveform recording device with the stored records in the central database to identify and supplement missing waveform recording data.

[0084] Specifically, the communication status between each waveform recording device and the central server is monitored in real time during the data acquisition process. The monitoring mechanism is based on two methods: timeout detection and heartbeat monitoring.

[0085] The timeout detection method records the start time of each data transmission. If the transmission is not completed and no data fragments are received within the preset time threshold (default is 60 seconds), the transmission is judged to have timed out. The heartbeat monitoring method involves the waveform recording device periodically (every 30 seconds) sending a heartbeat signal to the central server. The server records the last heartbeat time of each device. If a heartbeat signal is not received from a device within 90 seconds, the communication of that device is judged to be interrupted.

[0086] When a communication interruption is detected, the interruption event is recorded. The event information includes: device number, interruption detection time, interruption type (timeout, heartbeat loss, network unreachable, connection refused) and the last communication time before the interruption. The interruption event is written to the interruption log file, and the log is stored in JSON format for easy subsequent analysis.

[0087] Start an interrupt recovery monitoring thread. This thread scans all devices in an interrupted state every 30 seconds and performs a recovery probe on each device by sending an ICMP echo request and a TCP connection request. If both are successful, communication is considered to have been restored. Record the recovery detection time and calculate the interrupt duration as the difference between the recovery time and the interrupt time, in seconds.

[0088] After communication is restored, a data recovery process is automatically triggered. The goal of this process is to retrieve all waveform files generated by the device during the interruption, ensuring data integrity and completeness. The specific execution steps of the recovery process are as follows: The first step is to construct the time range query parameters, with the start time set to the interruption detection time minus 60 seconds (to reserve buffer time to cover data that may not have been reported in time before the interruption), and the end time set to the recovery detection time. A file list query request is sent to the waveform recording device, with the time range parameters carried in the request message.

[0089] The second step is that after receiving the query request, the waveform recording device scans the local storage directory, filters the waveform recording files whose generation time is within the specified range, and returns a file list. The file list includes the file name, file type, generation time and file size of each file.

[0090] The third step is to receive the file list, traverse each file in the list, and query the database mapping table to check if the file already exists. The checking method is to query based on a combination of device number and file generation time. If there is no corresponding record in the mapping table, the file is determined to be a missing file, and the file identifier is added to the replacement queue.

[0091] The fourth step involves retrieving file identifiers sequentially from the replenishment queue, sending a file recall request to the waveform recording device, receiving the file data and performing integrity verification, and writing it into the database after successful verification.

[0092] To prevent supplementary data collection tasks from consuming excessive resources and affecting normal data acquisition, priority and concurrency limits are set for supplementary data collection tasks. The priority of supplementary data collection tasks is set to 3 (lower than the priorities 1 and 2 of normal data acquisition tasks), and the task scheduler prioritizes high-priority tasks. The concurrency limit for supplementary data collection tasks is 3, meaning that a maximum of 3 supplementary data collection tasks can be executed simultaneously to avoid network congestion and excessive server load caused by a large number of supplementary data collection requests.

[0093] In addition to immediate recall after communication interruption, it also implements periodic data integrity verification. The verification task is triggered by a timed task scheduler, and the scheduling time is set to 2:00 AM every day. It is executed during off-peak business hours to reduce the impact on normal business.

[0094] The integrity verification process is as follows: The first step is to determine the verification time window, which defaults to 00:00:00 to 23:59:59 of the previous calendar day. A file list query request is sent to all online waveform recording devices, with the verification time window as the request parameter.

[0095] The second step is to summarize the file lists returned by all devices and count the total number of files. Given n devices, the number of files returned by the i-th device is... The total number of files M is then calculated as follows: The third step is to query the database mapping table and count the number of files with a synchronization status of "successful" within the time window, denoted as . Calculate the data integrity rate R: The fourth step is to determine whether the integrity rate has reached the preset threshold (the default is 95%, or 0.95). If R < 0.95, an integrity alarm report is generated. The report includes: verification time window, total number of files, number of synchronized files, number of missing files, integrity rate, and a list of missing files.

[0096] The expected number of files is estimated based on historical statistical data. The daily average number of waveform files generated by the device over the past 30 days is calculated as the expected number of files for that day. Let the file count sequence for the past 30 days be... The expected number of files F is calculated as follows: When the actual number of samples collected reaches more than 90% of the expected value, the progress bar will be green; when it is between 50% and 90%, it will be yellow; when it is below 50%, it will be red and an inefficiency alarm will be triggered.

[0097] When an anomaly occurs, alarm information is sent to maintenance personnel through multiple channels, including: monitoring interface pop-up prompts, log records, email notifications, and SMS notifications (for critical alarms). The alarm content includes the anomaly type, the time of occurrence, the name of the device involved, anomaly details, and suggested handling measures.

[0098] For severe anomalies (such as more than 5 devices going offline simultaneously, database available space being less than 10%, or server CPU utilization consistently exceeding 90%), an emergency alarm will be triggered. The emergency alarm will be sent to the mobile phone of the operations and maintenance personnel via SMS to ensure that the alarm information is delivered in a timely manner. The operations and maintenance personnel must respond to the emergency alarm within 30 minutes. The response methods include logging in to view details, performing troubleshooting, or activating the emergency plan.

[0099] All alarm records are stored in the alarm database. The database table structure includes: alarm number, alarm level (information, warning, critical, urgent), alarm type, occurrence time, affected objects, alarm content, processing status (unprocessed, processing, processed, ignored), and processing personnel. The alarm database supports historical query and statistical analysis functions. Operations personnel regularly (e.g., weekly or monthly) generate alarm statistical reports, analyze alarm trends and high-frequency alarm types, identify potential problems, and formulate optimization and improvement measures.

[0100] In summary, by employing both automatic and manual triggering modes and setting priority scheduling for waveform recording events, the system satisfies both the need for automatic fault response and the flexibility of maintenance personnel. Prioritizing fault events shortens the acquisition delay of urgent data. Network connectivity is assessed by conducting multiple ICMP message tests and calculating the average round-trip time and standard deviation. Combined with TCP three-way handshake verification for port availability and backup port switching, a comprehensive communication quality assessment system is established to improve data transmission reliability. Finally, by using a custom application layer protocol to retrieve and parse waveform recording files from various formats to extract key information and establish correlations, the system effectively addresses these challenges. The system establishes a unified management mechanism for parameters, configurations, data, and waveform files. Through time-series sorting, integrity checks, and retransmission in the data synchronization strategy, a cyclic redundancy check algorithm is used to verify the correctness of file transmission and trigger re-recall for abnormal files, ensuring the quality of the data entering the database. A heartbeat mechanism and health score between primary and backup nodes dynamically monitor the status of the primary node and automatically switch over in case of anomalies. During the switchover process, configuration information and unfinished tasks are synchronized to achieve seamless service migration. Combined with automatic re-recall after communication interruption and periodic integrity checks, a complete fault tolerance and data compensation system is constructed to ensure the continuity and integrity of fault waveform data acquisition in a distributed environment.

[0101] Example 3 The above is a schematic scheme for a distributed fault waveform data acquisition and synchronization method. It should be noted that the technical solution of this distributed fault waveform data acquisition and synchronization system belongs to the same concept as the technical solution of the aforementioned distributed fault waveform data acquisition and synchronization method. Details not described in detail in this embodiment can be found in the description of the technical solution of the aforementioned distributed fault waveform data acquisition and synchronization method.

[0102] This embodiment also provides a distributed fault recording data acquisition and synchronization system, including: The communication management module is used to establish a network communication connection between the distributed waveform recording devices and the central server, and to configure the communication parameters of each waveform recording device. The trigger response module is used to respond to the waveform recording event trigger source and initiate a data acquisition request to the target waveform recording device. The health assessment module is used to perform a communication health assessment on the target waveform recording device and determine whether the communication status of the target waveform recording device meets the data transmission conditions. The data retrieval module is used to send a waveform recording file retrieval command to the target waveform recording device, obtain a list of waveform recording files, and receive the waveform recording data files returned by the waveform recording device. The data synchronization module is used to transmit the received waveform data files to the central database for storage and to execute the data synchronization strategy; the node switching module is used to dynamically switch between the primary service node and the backup service node based on the service node's operating status to obtain data acquisition synchronization service.

[0103] This embodiment also provides an electronic device suitable for distributed fault waveform data acquisition and synchronization, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the distributed fault waveform data acquisition and synchronization method proposed in the above embodiment.

[0104] This embodiment also provides a storage medium on which a computer program is stored. When the program is executed by a processor, it implements the distributed fault recording data acquisition and synchronization method proposed in the above embodiments.

[0105] The storage medium proposed in this embodiment and the method for realizing distributed fault waveform data acquisition and synchronization proposed in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0106] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0107] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for distributed fault recording data acquisition and synchronization, characterized in that: This includes establishing a network communication connection between the distributed waveform recording devices and the central server, configuring the communication parameters of each waveform recording device, responding to waveform recording event triggering sources, and the waveform recording event triggering sources initiating data acquisition requests to the target waveform recording devices; A communication health assessment is performed on the target waveform recording device. The communication health assessment uses a dual verification method to determine whether the communication status of the target waveform recording device meets the data transmission conditions. When the communication status meets the data transmission conditions, a waveform recording file summoning command is sent to the target waveform recording device to obtain the waveform recording file list and receive the waveform recording data file returned by the waveform recording device. The received waveform recording data file is then transmitted to the central database for storage, and a data synchronization strategy is executed. When there are redundant deployment nodes on the central server, dynamic switching is performed between the primary service node and the backup service node based on the running status of the service node to obtain synchronous data collection services.

2. The distributed fault recording data acquisition and synchronization method as described in claim 1, characterized in that: The waveform recording event triggering sources include automatic triggering based on preset rules and manual triggering based on user commands; The waveform recording event trigger source initiates a data acquisition request to the target waveform recording device, including, in automatic triggering mode, monitoring the fault event signal reported by the waveform recording device, and when a fault event is detected, automatically generating a data acquisition request and identifying the faulty waveform recording device as the target waveform recording device. In manual trigger mode, the system receives a call command from the user who selects a specific waveform recording device through the monitoring interface and identifies the waveform recording device selected by the user as the target waveform recording device. Based on the urgency of the data collection request, a collection priority is assigned to different triggering methods, with priority given to collection requests automatically triggered by fault events.

3. The distributed fault recording data acquisition and synchronization method as described in claim 2, characterized in that: The communication health assessment of the target waveform recording device includes sending a network connectivity probe message to the target waveform recording device, receiving the probe response and recording the response time, and determining that the network connectivity is abnormal when no response is received within a preset time. Under normal network connectivity, initiate a connection request to the data transmission port of the target waveform recording device to verify whether the port is open and can establish a data channel. Based on the network connectivity verification results and port availability verification results, the communication health level is comprehensively judged. When both verifications pass, the communication status is determined to meet the data transmission conditions. When either verification fails, abnormal information is recorded and an alarm is triggered.

4. The distributed fault recording data acquisition and synchronization method as described in claim 3, characterized in that: The step of obtaining the list of waveform recording files and receiving the waveform recording data files returned by the waveform recording device includes receiving waveform recording data files in multiple formats returned by the waveform recording device, wherein the multiple formats include parameter configuration files, waveform recording configuration files, data files and waveform files; Different formats of waveform recording data files are parsed and processed separately to extract key information from each file and establish the relationship between the files; The parsed waveform recording data files are stored in a designated directory on the file server, categorized by waveform recording device and data type for easy data retrieval and download later.

5. The distributed fault recording data acquisition and synchronization method as described in claim 4, characterized in that: The execution data synchronization strategy includes receiving waveform recording data files from different waveform recording devices and parsing the timestamp information and device identification information of each data file; Data files from multiple waveform recording devices are sorted in time sequence according to timestamp information to ensure that data is stored in the central database in the order of actual occurrence time. Check the integrity of data files, verify whether the file format and file size meet the preset specifications, mark incomplete or abnormally formatted files and trigger a re-call; During database storage, the correspondence between the waveform recording device and the data file is maintained, and the source device, acquisition time, and synchronization status of the data are recorded to achieve data traceability.

6. The distributed fault recording data acquisition and synchronization method as described in claim 5, characterized in that: The dynamic switching between the primary service node and the backup service node includes real-time monitoring of the primary service node's operating status, including the communication program's operating status, database service status, and file service status. When an anomaly is detected in the primary service node, the backup service node is activated to take over the data acquisition and synchronization tasks, and the communication connection of the waveform recording device is switched to the backup service node. During the switchover process, the configuration information and unfinished data transmission tasks between the primary and backup service nodes are synchronized to ensure a smooth transition of service switching. After the primary service node recovers, a service rollback operation is performed to return the data collection and synchronization tasks to the primary service node and update the data on the standby service node to the latest state.

7. The distributed fault recording data acquisition and synchronization method as described in claim 6, characterized in that: It also includes monitoring the communication status between each waveform recording device and the central server during the data acquisition process, and recording the interruption time and reason when a communication interruption is detected; In the event of data transmission failure due to communication interruption, a data recovery process is automatically triggered after communication is restored to obtain the waveform data generated during the interruption. The monitoring interface displays the communication status and data acquisition progress of each waveform recording device in real time, and sends alarm information to maintenance personnel when abnormal situations occur. Regularly perform data integrity checks by comparing the list of waveform recording files stored locally on the waveform recording device with the stored records in the central database to identify and supplement missing waveform recording data.

8. A distributed fault recording data acquisition and synchronization system, based on the distributed fault recording data acquisition and synchronization method according to any one of claims 1 to 7, characterized in that: It also includes a communication management module, which is used to establish a network communication connection between the distributed waveform recording devices and the central server, and to configure the communication parameters of each waveform recording device; The trigger response module is used to respond to the waveform recording event trigger source and initiate a data acquisition request to the target waveform recording device. The health assessment module is used to perform a communication health assessment on the target waveform recording device and determine whether the communication status of the target waveform recording device meets the data transmission conditions. The data retrieval module is used to send a waveform recording file retrieval command to the target waveform recording device, obtain a list of waveform recording files, and receive the waveform recording data files returned by the waveform recording device. The data synchronization module is used to transfer the received waveform data files to the central database for storage and to execute the data synchronization strategy. The node switching module is used to dynamically switch between the primary service node and the backup service node based on the running status of the service node, so as to obtain the synchronous service of data collection.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the distributed fault recording data acquisition and synchronization method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the distributed fault recording data acquisition and synchronization method according to any one of claims 1 to 7.

Images