A multi-protocol access power transmission line galloping online monitoring and equipment management system

Abstract

This invention belongs to the field of transmission line galloping monitoring technology, specifically involving a multi-protocol access online monitoring and equipment management system for transmission line galloping. The system architecture, with a protocol adaptation module at its core and other modules working in tandem, utilizes dynamic weight matching, CNN feature extraction, and active learning capabilities to uniformly convert private protocol and protocol variant data into standard fields, solving the problem of multi-protocol data fusion. The equipment management module establishes an association mapping between equipment ID, protocol, and protocol links, and, combined with cross-protocol fault diagnosis, solves the problem of difficult multi-link fault location. The data conversion unit corrects semantic ambiguities and conversion errors through a domain semantic association library and context verification, improving data accuracy and ultimately achieving multi-source data collaboration, efficient equipment management and control, and flexible system evolution.

Description

Technical Field

[0001] This invention belongs to the field of transmission line galloping monitoring technology, specifically relating to a multi-protocol access transmission line galloping online monitoring and equipment management system. Background Technology

[0002] In existing transmission line galloping monitoring systems, multi-protocol access typically follows a process from device acquisition, protocol encapsulation, gateway conversion, to system interaction: front-end monitoring devices (such as cameras and galloping sensors) encapsulate data using different protocols based on data type, such as I1 protocol for image transmission, MQTT protocol for real-time parameter transmission, and Modbus protocol for device status transmission. This data is then identified and converted into a system-wide format by the multi-protocol gateway before being uploaded to the core layer. When the system issues commands, it needs to convert control requirements into the corresponding protocol format, such as GB / T-28181 protocol for image preview and proprietary protocols for parameter configuration. These commands are then sent to the devices via the gateway, and responses are received. However, due to the fundamental differences in data structure and transmission rules between different protocols, frequent format adaptation is required during gateway conversion, which can easily lead to increased data latency or even packet loss, making it difficult to guarantee the real-time performance and integrity of transmission line galloping monitoring data.

[0003] Meanwhile, multi-protocol access mode brings significant challenges to equipment management: multi-protocol links on a single device (such as the I1 protocol data reporting link and the GB / T-28181 protocol preview link) require different configuration parameters, operation and maintenance rules, and fault diagnosis logic. Once a fault occurs, operation and maintenance personnel need to debug the status of each protocol link separately and verify the responsiveness of different protocols one by one. This decentralized management not only significantly increases the workload and cost of operation and maintenance, but may also lead to the neglect of the correlation between protocols. For example, the interruption of a protocol link may affect the data transmission of other protocols, resulting in a decrease in the overall stability of the equipment, and thus making it difficult to meet the requirements of efficient and reliable operation of the transmission line galloping monitoring system. Summary of the Invention

[0004] To address the aforementioned problems in the existing technology, this invention provides a multi-protocol access-based online monitoring and equipment management system for transmission line galloping, which solves the problems of frequent format conversion, difficulty in quickly locating faults due to the complexity of multi-protocol links, and the difficulty in identifying ambiguous and overlapping protocol features when using multi-protocol access.

[0005] The objective of this invention can be achieved through the following technical solution: a multi-protocol access transmission line galloping online monitoring and equipment management system, comprising a data acquisition module, a protocol adaptation module, a central control application module, an equipment management module, and a data storage module that are sequentially connected in communication;

[0006] The data acquisition module is used to acquire transmission line galloping monitoring data and equipment operating status data, and encapsulates the data using corresponding protocols according to the different data types of the two types. The equipment includes a galloping data acquisition device and an associated device that supports multi-protocol interaction.

[0007] The protocol adaptation module is used to receive the data encapsulated by the protocol, identify the protocol type and convert it into standard fields; at the same time, it receives the control commands issued by the central control application module, converts the control commands into command frames of the corresponding protocol format according to the protocol types supported by different devices and transmits them to the corresponding devices.

[0008] The central control application module is used to perform transmission line galloping detection and analysis based on the standard fields, and convert the device responses of different ports into control commands and send them to the protocol adaptation module.

[0009] The device management module is used to establish an association mapping between the unique identifier of the device and the multi-protocol access link, and to perform centralized monitoring of multi-protocol link transmission, batch parameter configuration, and cross-protocol fault diagnosis.

[0010] The data storage module is used to store the standard field data output by the protocol adaptation module and the associated mapping data generated by the device management module.

[0011] Preferably, the data acquisition module includes a motion sensor, a high-definition camera, and a weather station data acquisition unit;

[0012] The data acquisition module uses a data-protocol mapping rule to encapsulate different data types using different protocols. The data-protocol mapping rule is as follows: the image data acquired by the high-definition camera is encapsulated using the I1 protocol, the amplitude and frequency data of the dancing sensor are encapsulated using the MQTT protocol, and the device's operating status data is encapsulated using the Modbus protocol.

[0013] Preferably, the protocol adaptation module includes:

[0014] The protocol identification unit, based on the set protocol feature library, uses a multi-feature matching algorithm to extract the header identifier, port number, and field separator features of the data frame and match them with the protocol features pre-stored in the protocol feature library to determine the protocol type.

[0015] The data conversion unit uses a dynamic field mapping algorithm to map raw data fields from different protocols to standard fields in a unified data format;

[0016] The instruction adaptation unit is used to query the protocol support list of the target acquisition device, convert the control instruction into an instruction frame of the corresponding protocol format, and transmit it to the corresponding device.

[0017] The self-learning unit uses an incremental learning algorithm to optimize protocol identification and field mapping logic by analyzing historical conversion logs. When a new protocol is added, its frame structure features are automatically extracted and updated to the protocol feature library.

[0018] Preferably, the protocol identification unit is used to perform the following steps:

[0019] Receive protocol-encapsulated data frames sent by the data acquisition module and extract multi-dimensional features;

[0020] Based on the standard protocol and variant protocol feature templates pre-stored in the protocol feature library, the multi-dimensional features are divided into unique features and general features. The unique features and general features are weighted separately by a dynamic weighting algorithm, and the comprehensive matching degree is calculated. The comprehensive matching degree is then compared with three set comprehensive matching degree thresholds.

[0021] If the protocol is marked as unrecognized after comprehensive matching, the sub-learning unit is triggered for processing; if it is marked as fuzzy matching, the temporal feature secondary verification is performed.

[0022] The secondary verification of timing features includes calculating the timing matching degree; if the timing matching degree passes, the protocol type is output.

[0023] Preferably, the formula for calculating the overall matching degree is: Single feature matching degree = (Number of bytes that match the actual feature and the template feature / Total number of bytes of the feature) × weight, and the overall matching degree is the sum of the matching degrees of all single features.

[0024] Preferably, the data conversion unit is used to perform the following steps:

[0025] Based on the protocol type and version output by the protocol identification unit, the corresponding protocol's basic field mapping rule table is called;

[0026] Semantic matching is performed on the fields after parsing the original data frame based on a pre-set semantic association library;

[0027] Perform contextual validity checks on the mapped standard fields.

[0028] Preferably, the context validity check includes format checking, range checking, and timing checking.

[0029] Preferably, the instruction adaptation unit further includes instruction pre-verification, which includes parsing logic for the protocol version of the target device. If the verification fails, it automatically switches to a compatible version rule for re-encapsulation.

[0030] Preferably, the self-learning unit includes using the DBSCAN clustering algorithm to analyze the feature vector differences of multi-frame data of the new protocol to obtain core clusters and edge clusters, extracting stable features in the core clusters and extracting variable features in the edge clusters.

[0031] Preferably, the device management module includes:

[0032] The mapping unit uses the device physical ID as the core key to associate the device's multi-protocol access link information and generate a device-protocol association file containing protocol type, link IP and configuration parameters.

[0033] The monitoring unit collects the transmission delay, packet loss rate and response time of each protocol link to determine the link status, and triggers cross-protocol linkage alarms when a transmission failure is detected.

[0034] The judgment unit performs batch configuration of multiple protocol parameters for the same acquisition device, associates protocol adaptation logs with device status data, uses a rule engine to determine the root cause of the fault, and outputs a diagnostic report and repair suggestions.

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

[0036] This invention employs a system architecture centered on a protocol adaptation module, with other modules working in tandem. The protocol adaptation module, leveraging dynamic weight matching, CNN feature extraction, and active learning capabilities, uniformly converts private protocol and protocol variant data into standard fields, solving the challenge of multi-protocol data fusion. The device management module establishes a mapping between device ID, protocol, and protocol link, and, combined with cross-protocol fault diagnosis, addresses the difficulties of debugging devices one by one and locating faults. The data conversion unit, through a domain semantic association library and context verification, corrects semantic ambiguities and conversion errors in fields, improving data accuracy. The self-learning unit rapidly adapts to new device protocols, replacing the traditional manual plugin development model and solving the problem of weak system scalability. Ultimately, this achieves multi-source data collaboration, efficient device management and control, and flexible system evolution. Attached Figure Description

[0037] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0038] Figure 1 This is a system structure block diagram of the present invention; Detailed Implementation

[0039] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.

[0040] Please see Figure 1 This embodiment provides a multi-protocol access transmission line galloping online monitoring and equipment management system, characterized in that it includes a data acquisition module, a protocol adaptation module, a central control application module, an equipment management module and a data storage module that are connected in sequence via communication.

[0041] The data acquisition module is used to acquire transmission line galloping monitoring data and equipment operating status data, and encapsulates the data using corresponding protocols according to the different data types of the two types. The equipment includes galloping data acquisition equipment and associated equipment that supports multi-protocol interaction.

[0042] The data acquisition module includes a gob sensor, a high-definition camera, and a weather station data acquisition unit. The data acquisition module uses a data-protocol mapping rule to encapsulate different data types using different protocols. The data-protocol mapping rule is as follows: image data acquired by the high-definition camera is encapsulated using the I1 protocol, gob amplitude and frequency data acquired by the gob sensor are encapsulated using the MQTT protocol, and the device's operating status data is encapsulated using the Modbus protocol.

[0043] The protocol adaptation module is used to receive protocol-encapsulated data, identify the protocol type and convert it into standard fields; at the same time, it receives control commands issued by the central control application module, converts the control commands into command frames of the corresponding protocol format according to the protocol types supported by different devices and transmits them to the corresponding devices.

[0044] The central control application module is responsible for data fusion analysis and control command generation, specifically including:

[0045] 1. Used for transmission line galloping detection and analysis based on standard fields.

[0046] The system receives standardized data output from the protocol adaptation module, aligns it with the time and space (unified timestamp, associated device geographical location), and uses machine learning algorithms based on the acquired icing monitoring data to identify icing risks of transmission lines, combining existing conventional technical means. This can be achieved by using a prioritized icing-galloping-environment association model; and by using machine learning algorithms (such as random forest) to identify risk patterns and generate real-time risk levels (low, medium, high).

[0047] Second: Based on the device responses from different ports, control commands are converted and sent to the protocol adaptation module. Specifically: control commands are automatically generated based on the risk level (such as issuing commands to focus the camera on the icy area or activate the wire de-icing device in case of high risk), or manual remote operation is supported (selecting devices and operations through a visual interface); when the command is generated, it is associated with the device capability list of the device management module to ensure the legality of the command.

[0048] The device management module is used to establish a mapping between unique device identifiers and multi-protocol access links, enabling centralized monitoring of multi-protocol link transmission, batch parameter configuration, and cross-protocol fault diagnosis. Specifically, it includes:

[0049] The mapping unit uses the device physical ID as the core key to associate the device's multi-protocol access link information and generate a device-protocol association file containing protocol type, link IP and configuration parameters, such as icing sensor S-001 → private protocol → 4G link → port 8080.

[0050] The monitoring unit collects the transmission delay, packet loss rate and response time of each protocol link to determine the link status, and triggers cross-protocol linkage alarms when a transmission failure is detected.

[0051] The judgment unit monitors the operational metrics (bandwidth utilization, packet loss rate, latency) of multi-protocol links in real time and displays abnormal links through a visual dashboard (e.g., an alarm is triggered when the latency of an MQTT link is greater than 500ms). It supports batch configuration of parameters based on protocol type (e.g., adjusting the sampling frequency from 5Hz to 10Hz for all Modbus protocol sensors with one click). The configuration command is converted by the protocol adaptation module and then issued. It is associated with protocol adaptation logs and device status data, and the rule engine determines the root cause of the fault and outputs a diagnostic report and repair suggestions.

[0052] The data storage module stores standard field data output by the protocol adaptation module and associated mapping data generated by the device management module. It uses a time-series database (such as InfluxDB) to store standardized monitoring data (indexed by time series, supporting high-concurrency writing to meet the real-time analysis needs of icing and dancing); a relational database (such as MySQL) to store device associated mapping data and fault diagnosis logs (supporting structured queries for easy device management); and a distributed file system (such as HDFS) to store unstructured data such as high-definition images and videos (supporting large-capacity expansion), combined with compression algorithms (such as LZ77) to reduce storage costs.

[0053] The system architecture, with the protocol adaptation module at its core and other modules working in tandem, employs the following methods: The protocol adaptation module leverages dynamic weight matching, CNN feature extraction, and active learning capabilities to uniformly convert private protocol and protocol variant data into standard fields, solving the challenge of multi-protocol data fusion; The device management module establishes a mapping between device ID, protocol, and protocol link, and combined with cross-protocol fault diagnosis, addresses the difficulties of debugging devices one by one and locating faults; The data conversion unit corrects semantic ambiguities and conversion errors through a domain semantic association library and context verification, improving data accuracy; The self-learning unit rapidly adapts to new device protocols, replacing the traditional manual plugin development model and solving the problem of weak system scalability, ultimately achieving multi-source data collaboration, efficient device management and control, and flexible system evolution.

[0054] The protocol adaptation module includes:

[0055] The protocol identification unit, based on a set protocol feature library, uses a multi-feature matching algorithm to extract header identifiers, port numbers, and field separator features from data frames and match them with pre-stored protocol features in the protocol feature library to determine the protocol type. The protocol identification unit uses dynamically optimized feature matching logic to solve problems such as ambiguous protocol features and misjudgment of variant protocols. Specific functional details are as follows:

[0056] A1: After receiving the raw data frames (byte stream format) transmitted by the data acquisition module, preprocessing is performed first: redundant padding bytes at the end of the frame (such as 0x00 added for alignment bytes in some protocols) are removed, and valid data segments are extracted; then, 12 key features are extracted using the feature extraction engine, including:

[0057] Basic characteristics: Frame header identifier (a fixed sequence of the first 3-5 bytes, such as MQTT fixed header 0x30-0x3F, Modbus-RTU start character 0x01), frame tail identifier (such as the end character "0xFF00" of the I1 protocol), port number (transport layer bound port, such as MQTT default 1883, HTTP default 80);

[0058] Structural features: field separators (such as Modbus field separator 0x2C, private protocols "#"), frame length range, such as I1 protocol image frames are fixed at 1024 bytes / frame, and dancing sensor MQTT frames are dynamic from 128 to 512 bytes.

[0059] Check characteristics: check bit algorithm, such as Modbus CRC16, I1 protocol MD5 digest, check bit position, including the first 2 bytes of the frame tail or the last 1 byte of the frame header;

[0060] Timing characteristics: transmission interval of 3 consecutive frames (e.g., a fixed 500ms / frame for a weather station Modbus frame, and a dynamic 200-1000ms / frame for a camera I1 frame due to image compression), request-response interaction mode, such as the fixed timing of "master request → slave response" in Modbus, and the asynchronous timing of "publish → confirm" in MQTT;

[0061] A2: Dynamic weight matching and preliminary determination of protocol type:

[0062] Multi-feature weighted matching is performed based on the protocol feature library, which stores feature templates for various mainstream protocols and variant protocols, such as simplified versions of "Modbus-RTUv1.0" and "MQTTv3.1.1".

[0063] Dynamic weight allocation: The decision tree model trained by historical error logs assigns a weight of 0.7-0.8 to unique features with high discriminative power (such as the "0xAA55" header identifier unique to a manufacturer's proprietary sensor protocol). For general features, such as port number 502 which may be shared by multiple protocols, a weight of 0.1-0.2 is assigned. For structural features (such as frame length distribution), a weight of 0.2-0.3 is assigned.

[0064] The matching degree is calculated as follows: Single feature matching degree = (number of bytes that match between the actual feature and the template feature / total number of bytes of the feature) × weight, and the overall matching degree is the sum of the matching degrees of all single features;

[0065] Preliminary judgment rules: If the overall matching degree of a protocol template is ≥90%, it is directly judged as the protocol; if 80%≤matching degree<90%, it is marked as "fuzzy matching" and enters the second verification of time-series features; if <80%, it is marked as "unrecognized protocol" and triggers subsequent self-learning unit learning or manual labeling.

[0066] A3: Secondary verification of timing characteristics and version confirmation:

[0067] For "fuzzy matching" scenarios (such as "Modbus-RTU v1.0" and "v2.0" differing only in their checksum algorithms, with a basic feature matching accuracy of 85%), deep temporal feature analysis is used for differentiation. Specifically:

[0068] Extract the interaction timing data of 5 consecutive frames, such as the time difference between the request frame and the response frame, and the frame interval fluctuation rate, and compare it with the timing templates of each version in the protocol feature library. For example, the response delay of v1.0 is ≤100ms, and the delay of v2.0 due to encryption processing is 150-200ms.

[0069] Calculate the time series matching degree (e.g., delay matching degree × 0.6 + volatility matching degree × 0.4). If the time series matching degree of a certain version is ≥ 85% (time series matching degree threshold), then confirm the protocol and version (e.g., "Modbus-RTU v2.0") based on the preliminary judgment results.

[0070] Output results: final protocol type (including version) and feature matching details (e.g., "header identifier matching degree 98%, time sequence matching degree 89%)", synchronized to the data conversion unit and log system;

[0071] The protocol identification unit uses a dynamic weight matching mechanism to assign higher weights to unique features with high discriminative power and lower weights to common features (such as public port numbers) to reduce interference caused by the crossover of common features. It also uses temporal feature fusion verification to perform secondary differentiation on ambiguous scenes with matching degree close to the threshold through the interaction time sequence of multiple consecutive frames, thereby reducing the false judgment rate.

[0072] The data conversion unit employs a dynamic field mapping algorithm to map raw data fields from different protocols to standard fields in a unified data format. Through domain-specific semantic mapping and multi-dimensional validation, the data conversion unit resolves issues such as semantic ambiguity and conversion errors. Specific functional details are as follows:

[0073] B1: Protocol-Field Mapping Rule Invocation and Raw Field Parsing:

[0074] After receiving the "protocol type + version" (e.g., "I1 protocol v3.0") output by the protocol identification unit, the system retrieves the specific parsing rules for that protocol from the local rule base. Specifically:

[0075] The parsing rules include: field offset (e.g., the "image resolution" field in the I1 protocol is located 10-13 bytes after the frame header), data type (int16 / string / float32), and encoding format (ASCII / binary).

[0076] Raw field extraction: Parse the data frame according to the rules to obtain the raw field key-value pairs (e.g., I1 protocol parsing yields "resolution=1920x1080" and "frame_rate=25fps", MQTT protocol parsing yields "swing_amplitude=0.35m" and "vibration_freq=1.2Hz").

[0077] Special handling: For variable-length fields (such as the "wind speed description" text field in the Modbus protocol of a weather station), the complete content is dynamically extracted by means of the field length identifier (such as the length of the first 2 bytes of the record);

[0078] B2: Intelligent matching of domain semantic association library:

[0079] Field mapping is performed based on a semantic association library in the field of power transmission line monitoring. The semantic association library is stored in a graph database and contains synonymous field mapping relationships for multiple physical quantities. The specific matching logic is as follows:

[0080] The associated database structure consists of core nodes with standard fields (such as "swing amplitude", "device temperature", and "image sampling frequency"), and edges with synonymous original fields (such as "swing amplitude", "swing_amplitude", "dance_range", "amplitude", etc.), along with metadata, such as data unit: m / cm; value range: 0-5m; conversion formula: cm to m requires dividing by 100.

[0081] Matching logic: The original field name is segmented into words, such as "dance_rate" being split into "dance" and "rate". The standard field is matched using a semantic similarity algorithm (Word2Vec calculates the vector cosine value). If the similarity is ≥0.85, it is directly associated; if the similarity is 0.6≤s<0.85, a secondary matching is performed based on the data unit. For example, if the unit of "rate" is "Hz", "dance frequency" is associated first.

[0082] B3: Context validation and error correction:

[0083] Three-layer validation is performed on the mapped standard fields to ensure data validity. Specifically:

[0084] Format validation: Check data type, such as "dance amplitude" must be float, not string, and unit consistency, such as uniformly using "m", automatically converting "30cm" to "0.3m";

[0085] Range verification: Based on the equipment parameter library (such as the range of the gyratory sensor 0-5m), determine whether the value is within a reasonable range. For example, if "gyratory amplitude = 6.2m" is out of range, mark it as abnormal.

[0086] Timing verification: Compare the historical data of the previous 5 frames of the device. If the current value fluctuates by more than 3σ, such as the average frequency of the previous 5 frames being 1.2Hz and the current value suddenly changing to 5.8Hz, trigger a second matching of synonym fields, such as confirming whether "vibration frequency" was mistakenly mapped to "dancing frequency".

[0087] For fields that fail validation, mark the error type, such as "range out of limit" or "semantic ambiguity", synchronize them to the self-learning unit to optimize the mapping rules, and output the "to be confirmed" standard field (with original value) to the central control application module.

[0088] B4: Output standard fields and log records:

[0089] The output conforms to a standardized field format, which is a JSON structure. The conversion process (original field → matching path → validation result) is written to the conversion log for subsequent analysis by the self-learning unit.

[0090] By constructing a semantic association library for the transmission line icing monitoring neighborhood, storing synonymous field mappings of physical quantities, annotating metadata, and adding a context verification mechanism to verify the rationality of mapping results, the conversion error caused by differences in the field names of the same physical quantity is resolved, and the accuracy of semantic matching is improved.

[0091] The instruction adaptation unit is used to query the protocol support list of the target acquisition device, convert the control instructions into instruction frames of the corresponding protocol format, and transmit them to the corresponding device. The instruction adaptation unit resolves issues such as instruction version incompatibility and device rejection through fine-grained protocol version management and pre-verification. Specific functional details are as follows:

[0092] C1: Command and target device information reception and protocol support query:

[0093] After receiving control commands (such as {"command type":"adjust sampling frequency","parameter":{"frequency":10,"unit":"Hz"},"target device ID":"CAM-001"}) issued by the central control application module, execute:

[0094] Send a query request to the device management module to obtain a list of supported protocols for the target device, including version and priority, such as [{"protocol":"I1","version":"v3.0","priority":1}, {"protocol":"HTTP","version":"1.1","priority":2}];

[0095] Synchronously acquire device command permissions and filter out valid protocols. Command permissions include, for example, "CAM-001" only allows I1 protocol to adjust the sampling frequency, and HTTP protocol only supports querying.

[0096] C2: Call the protocol feature library and generate instruction frames:

[0097] Based on the target protocol and version, such as "I1v3.0", the instruction frame format template is called from the protocol feature library, which includes:

[0098] Fixed structure: Frame header (4 bytes "0x11223344"), Device ID field (8 bytes ASCII code), Instruction type code (1 byte, such as "adjust frequency" corresponding to 0x05), Parameter area length (2 bytes), Checksum area (4 bytes CRC32), Frame tail (2 bytes "0xEEFF");

[0099] There are differences between the protocols: for example, the I1v2.0 checksum is 2 bytes CRC16, while v3.0 is upgraded to 4 bytes CRC32; the v2.0 parameter area only supports integers, while v3.0 supports floating-point numbers;

[0100] Generate instruction frame: Generate raw instruction frame byte stream by filling in the template content. The filling content, such as the device ID "CAM-001", is converted to 8-byte ASCII, and the parameter "10Hz" is converted to 4-byte floating-point type according to v3.0 format.

[0101] C3: Verify compatibility between command frames and protocols. To prevent command frames from being rejected by the device due to version incompatibility, a pre-verification process is performed, specifically:

[0102] Simulate the protocol parsing logic of the target device: Load the I1v3.0 device parsing algorithm, obtain the parsing SDK provided by the manufacturer from the device management module, and perform integrity verification (such as whether the CRC32 check bits are correct) and format verification (whether the parameter area conforms to the floating-point encoding rules) on the generated instruction frame.

[0103] If the pre-verification fails (e.g., the frame is mistakenly generated in v2.0 format), it automatically switches to the next highest priority version (e.g., I1v2.0), regenerates the instruction frame (the parameter "10Hz" is converted to a 2-byte integer), and performs pre-verification again; if all versions fail, it returns an "instruction not supported" error to the central control application module.

[0104] Adjust priority: Record the verification success rate of each version and dynamically update the device protocol priority. For example, if I1v3.0 fails 3 times in a row, the priority of v2.0 will be increased.

[0105] C4: Transmission command frame and transmission status feedback:

[0106] Send command frames through the communication link corresponding to the target protocol (such as the fiber optic link bound to the I1 protocol, port number 9001), and listen for the device response at the same time. For example, in the I1 protocol, the "acknowledgment frame" 0x00 indicates success, and 0x01 indicates a format error.

[0107] If a successful response is received, a message "Command executed successfully" will be sent to the central control application module.

[0108] If no response is received within a timeout period or an error response is received, the retransmission mechanism is triggered (up to 3 times, with an interval of 1 second). If it still fails, a "command transmission failure" log is recorded and synchronized to the self-learning unit to optimize the protocol selection logic.

[0109] The instruction adaptation unit establishes a protocol feature library to store the differences in instruction frame formats for each version. Through the instruction pre-verification process, it simulates the version parsing logic of the target device. If the matching fails, it automatically switches to a compatible version, thereby improving the success rate of instruction transmission by addressing the device rejection problem caused by device version differences.

[0110] The self-learning unit uses an incremental learning algorithm to optimize protocol identification and field mapping logic by analyzing historical conversion logs. When a new protocol is added, its frame structure features are automatically extracted and updated to the protocol feature library. Through a data-driven learning mechanism, it solves problems such as poor compatibility of protocol variants and incomplete feature extraction of new protocols. Specific functional details are as follows:

[0111] D1: Collect multi-dimensional logs and build a sample library:

[0112] Real-time collection of three core log types to build an incremental learning sample library:

[0113] Identification Log: Includes unidentified frames (raw byte stream), fuzzy matching frames (the relationship between feature matching details and actual protocol labels), and misjudged frames, such as frames and features that misjudged "private protocol A" as "Modbus";

[0114] Transformation logs include semantic matching failure frames (original fields combined with standard field candidate sets) and validation error frames (such as mapping results and original data that exceed the range limit).

[0115] Command log: contains frames with incompatible protocol versions (command frames and device responses) and transmission failure frames (link status and retry records);

[0116] Sample labeling: For manually confirmed error cases (such as "unidentified frame is actually protocol B" marked by maintenance personnel), add tags and store them in the sample library;

[0117] D2: For unidentified or variant protocols, a CNN model (input is grayscale conversion of data frame byte stream, output is feature vector) is used to automatically extract deep features:

[0118] The CNN learning model is trained using labeled protocol frames from the sample library. Convolutional layers extract local byte patterns, and fully connected layers extract global features, including frame length distribution and field offset patterns.

[0119] For unrecognized frames, a 128-dimensional feature vector is output by the trained CNN, and the similarity is calculated by Euclidean distance with the feature vectors of existing protocols in the protocol feature library for feature comparison.

[0120] Compared to manually defined features, CNNs can capture subtle differences in variant protocols. For example, a variant of MQTT may omit the third byte of control bits, which is easily overlooked by humans, but CNNs can identify it through local patterns.

[0121] D3: When adding new protocol devices (such as proprietary icing sensors from a certain manufacturer) to the transmission line icing galloping monitoring system, to ensure complete protocol feature extraction and avoid missing key information, the DBSCAN clustering algorithm (eps=0.1, min_samples=5) is used to analyze the differences in feature vectors and extract features from multiple frames of data (the threshold can be set to 50 frames) of the new protocol. The specific process of D3 includes:

[0122] D31: First, collect 50 frames of raw data sent by the newly added protocol device. 50 frames is a threshold that balances feature coverage and processing efficiency. Too few frames will easily miss features, while too many frames will increase the computational cost. The CNN model converts each frame of data into a 128-dimensional feature vector containing dimensions such as "header, checksum, structure, and time sequence".

[0123] D32: Perform DBSCAN clustering analysis. The parameters of the DBSCAN algorithm are set as follows: eps=0.1, which controls the similarity range of feature vectors (the smaller the eps, the higher the similarity requirement); min_samples=5, which controls the density threshold of the core cluster (ensuring that the commonality of frames within the core cluster is high enough). Cluster the feature vectors of 50 frames:

[0124] When the feature similarity of the feature vectors of a certain set of frames is ≥90%, and there are at least 5 frames in the range eps=0.1, they are automatically aggregated into a core cluster, representing the set of common frames of the protocol.

[0125] When the feature similarity of the feature vectors of a certain part of the frames is only 70%-89% similarity to the core cluster (they can be associated but do not meet the core cluster standard), and the number of frames is less than 5, an edge cluster is formed, which represents the set of unique frames of this protocol.

[0126] D33: Perform feature classification and extraction:

[0127] Stable features are extracted from the core cluster. These stable features are those that remain consistent across all frames of the newly added protocol and serve as the protocol's identifying characteristics. For example, the fixed header "0xABAB" feature can be extracted using the CRC32 checksum algorithm. These features are then directly stored in the protocol feature library for subsequent protocol identification. For instance, when the system receives a frame containing the "0xABAB" header, it can quickly match it to the newly added protocol.

[0128] Variable features are extracted from edge clusters. These variable features are those that change with the protocol's data content or transmission requirements but do not affect the protocol's essence; they are the protocol's adaptive features. Changes in these features do not alter the protocol's core attributes, such as differences in frame end padding bytes or frame interval fluctuations. These features are then synchronously updated to the protocol feature library's compatibility rules. For example, when the system receives a frame of this protocol with a frame end of "0x02" the next time, it will not mistakenly identify it as an unrecognized protocol due to frame end differences.

[0129] Calculate the similarity with existing features in the protocol feature library (interviews with an edit distance ≤ 2 bytes are considered duplicates) to avoid duplicate entries into the library;

[0130] DBSCAN clustering accurately distinguishes the stable commonalities and variable individualities of protocols, ensuring the accuracy of core features (for protocol identification) and covering the compatibility of variable features (for protocol variant adaptation). This solves the problem that traditional manual feature extraction is prone to missing variable features, resulting in incomplete adaptation to new protocols, and provides technical support for the system to quickly become compatible with new icing and dancing monitoring equipment.

[0131] D4: When the recognition accuracy of the newly added protocol is less than the set threshold, the active learning process is triggered. The recognition accuracy is the percentage of correctly predicted frames by the CNN. The set threshold here can be 70%.

[0132] Using uncertainty sampling (selecting frames with CNN prediction probabilities of 0.4-0.6), 10-20 frames are pushed to the manual annotation interface, along with a visualization of the feature vectors extracted by the CNN.

[0133] Fine-tuning the CNN model with labeled samples can improve recognition accuracy. Fine-tuning can be done by freezing the first 3 layers and training only the fully connected layers.

[0134] Based on the annotation results, optimize the semantic association library (such as adding the mapping of "vib_freq" → "vibration frequency") and the protocol feature library (such as supplementing the instruction frame check bit algorithm of a certain version), and synchronize them to the data conversion unit and instruction adaptation unit;

[0135] D5: The protocol feature library and semantic association library adopt an incremental update mechanism.

[0136] When adding new features or rules, a version number (e.g., V2.1.20251020) is generated, and the updated content is recorded, such as "Added Protocol C feature" and "Optimized Modbus v2.0 mapping rules";

[0137] Retain historical versions; if new rules cause the error rate to increase (e.g., >5%), support one-click rollback to the previous stable version.

[0138] Daily learning reports are generated, including the number of new protocols, the improvement in recognition accuracy, and details of rule optimizations, for review by operations and maintenance personnel.

[0139] The self-learning unit uses the DBSCAN clustering algorithm combined with the CNN learning algorithm to analyze multi-frame data of the new protocol, identify core features (such as the header identifier common to all frames) and variable features (such as dynamic field length), and avoid missing key features.

[0140] Due to frequent updates to power grid monitoring equipment (such as the use of proprietary protocols by new millimeter-wave icing sensors), traditional systems require manual development of protocol adaptation plugins (taking 1-2 weeks). Self-learning units can complete new protocol adaptation in a short time, supporting plug-and-play functionality.

[0141] Improved compatibility with protocol variants (such as the simplified Modbus protocol for older sensors) extends the lifespan of existing equipment and reduces equipment replacement costs.

[0142] The protocol adaptation module overcomes the challenge of identifying ambiguous and overlapping protocol features through dynamic weight matching and temporal feature fusion. It leverages CNN and active learning to achieve efficient adaptation to protocol variants and proprietary protocols. It eliminates semantic ambiguity in field mapping by relying on a domain semantic association library and contextual verification. Combined with a protocol version feature library and pre-verification, it ensures cross-version compatibility of instructions. DBSCAN clustering ensures complete extraction of new protocol features. This series of optimizations enables accurate identification of multiple protocol inputs, reducing false positive rates, improving semantic matching accuracy, achieving unambiguous conversion, and increasing instruction transmission success rates. Ultimately, it provides seamless fusion capabilities of multi-source data for transmission line icing and galloping monitoring, improving data real-time performance and accuracy, ensuring the effectiveness of remote equipment control, enhancing the system's adaptability to equipment upgrades, and significantly reducing maintenance costs and failure risks caused by protocol adaptation issues. This lays a crucial protocol-layer foundation for comprehensive monitoring and accurate early warning.

[0143] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A multi-protocol access-based online monitoring and equipment management system for transmission line galloping, characterized in that: It includes a data acquisition module, a protocol adaptation module, a central control application module, an equipment management module, and a data storage module that are connected in sequence. The data acquisition module is used to acquire transmission line galloping monitoring data and equipment operating status data, and encapsulates the data using corresponding protocols according to the different data types of the two types. The equipment includes a galloping data acquisition device and an associated device that supports multi-protocol interaction. The protocol adaptation module is used to receive the data encapsulated by the protocol, identify the protocol type and convert it into standard fields; at the same time, it receives the control commands issued by the central control application module, converts the control commands into command frames of the corresponding protocol format according to the protocol types supported by different devices and transmits them to the corresponding devices. The central control application module is used to perform transmission line galloping detection and analysis based on the standard fields, and convert the device responses of different ports into control commands and send them to the protocol adaptation module. The device management module is used to establish an association mapping between the unique identifier of the device and the multi-protocol access link, and to perform centralized monitoring of multi-protocol link transmission, batch parameter configuration, and cross-protocol fault diagnosis. The data storage module is used to store the standard field data output by the protocol adaptation module and the associated mapping data generated by the device management module; The protocol adaptation module includes: The protocol identification unit, based on the set protocol feature library, uses a multi-feature matching algorithm to extract the header identifier, port number, and field separator features of the data frame and match them with the protocol features pre-stored in the protocol feature library to determine the protocol type. The data conversion unit uses a dynamic field mapping algorithm to map raw data fields from different protocols to standard fields in a unified data format; The instruction adaptation unit is used to query the protocol support list of the target acquisition device, convert the control instruction into an instruction frame of the corresponding protocol format, and transmit it to the corresponding device. The self-learning unit uses an incremental learning algorithm to optimize protocol identification and field mapping logic by analyzing historical conversion logs. When a new protocol is added, its frame structure features are automatically extracted and updated to the protocol feature library. The protocol identification unit is used to perform the following steps: Receive protocol-encapsulated data frames sent by the data acquisition module and extract multi-dimensional features; Based on the standard protocol and variant protocol feature templates pre-stored in the protocol feature library, the multi-dimensional features are divided into unique features and general features. The unique features and general features are weighted separately by a dynamic weighting algorithm, and the comprehensive matching degree is calculated. The comprehensive matching degree is then compared with three set comprehensive matching degree thresholds. If the protocol is marked as unrecognized after comprehensive matching, the sub-learning unit is triggered for processing; if it is marked as fuzzy matching, the temporal feature secondary verification is performed. The secondary verification of timing features includes calculating the timing matching degree; if the timing matching degree passes, the protocol type is output.

2. The online monitoring and equipment management system for transmission line galloping with multi-protocol access as described in claim 1, characterized in that: The data acquisition module includes a motion sensor, a high-definition camera, and a weather station data acquisition unit. The data acquisition module uses a data-protocol mapping rule to encapsulate different data types using different protocols. The data-protocol mapping rule is as follows: the image data acquired by the high-definition camera is encapsulated using the I1 protocol, the amplitude and frequency data of the dancing sensor are encapsulated using the MQTT protocol, and the device's operating status data is encapsulated using the Modbus protocol.

3. The online monitoring and equipment management system for transmission line galloping with multi-protocol access as described in claim 1, characterized in that: The formula for calculating the overall matching degree is: Single feature matching degree = (Number of bytes that match the actual feature and the template feature / Total number of bytes of the feature) × weight, and the overall matching degree is the sum of the matching degrees of all single features.

4. The online monitoring and equipment management system for transmission line galloping with multi-protocol access according to claim 1, characterized in that: The data conversion unit is used to perform the following steps: Based on the protocol type and version output by the protocol identification unit, the corresponding protocol's basic field mapping rule table is called; Semantic matching is performed on the fields after parsing the original data frame based on a pre-set semantic association library; Perform contextual validity checks on the mapped standard fields.

5. The online monitoring and equipment management system for transmission line galloping with multi-protocol access according to claim 4, characterized in that: The context validity check includes format checking, range checking, and timing checking.

6. The online monitoring and equipment management system for transmission line galloping with multi-protocol access according to claim 1, characterized in that: The instruction adaptation unit also includes instruction pre-verification, which includes parsing logic for the protocol version of the target device. If the verification fails, it switches to a compatible version rule for re-encapsulation.

7. The online monitoring and equipment management system for transmission line galloping with multi-protocol access according to claim 1, characterized in that: The self-learning unit includes using the DBSCAN clustering algorithm to analyze the feature vector differences of multi-frame data of the new protocol to obtain core clusters and edge clusters, extracting stable features in the core clusters and variable features in the edge clusters.

8. The online monitoring and equipment management system for transmission line galloping with multi-protocol access according to claim 1, characterized in that: The device management module includes: The mapping unit uses the device physical ID as the core key to associate the device's multi-protocol access link information and generate a device-protocol association file containing protocol type, link IP and configuration parameters. The monitoring unit collects the transmission delay, packet loss rate and response time of each protocol link to determine the link status, and triggers cross-protocol linkage alarms when a transmission failure is detected. The judgment unit performs batch configuration of multiple protocol parameters for the same acquisition device, associates protocol adaptation logs with device status data, uses a rule engine to determine the root cause of the fault, and outputs a diagnostic report and repair suggestions.

Images