Multi-protocol compatible standardized interface method, system and equipment for icing monitoring terminal and medium

Abstract

The invention discloses a multi-protocol compatible standardized interface method, system and device for an icing monitoring terminal and a medium, and belongs to the technical field of power monitoring, and the method comprises the steps: configuring a protocol rule set for a hardware interface channel; analyzing the byte stream data according to the protocol rule set to obtain an original data value; converting the original data value into a standardized data object according to a data conversion rule, and uploading the standardized data object to a monitoring system; establishing an equipment mapping relation; packaging the control instruction into byte stream data according to the equipment mapping relation, and sending the byte stream data to the target equipment; and monitoring the communication quality of the hardware interface channel and adjusting the data quality identification of the standardized data object. According to the method, protocol abstraction and interface virtualization are realized through a cooperation mechanism of the protocol rule set, the data conversion rule and the equipment mapping relation, so that the icing monitoring terminal can flexibly support access of various communication protocol equipment on the premise of not modifying hardware and firmware, and the system integration difficulty and the maintenance cost are reduced.

Description

A multi-protocol compatible standardized interface method, system, device, and medium for icing monitoring terminals. Technical Field

[0001] This invention relates to the field of power monitoring technology, and specifically to a multi-protocol compatible standardized interface method, system, device and medium for icing monitoring terminals. Background Technology

[0002] As a crucial device for safety monitoring of power transmission lines, icing monitoring terminals require the integration of various types of sensors and external equipment, such as tension sensors, temperature sensors, humidity sensors, and micro-weather stations. These devices come from different manufacturers and employ different communication protocols, such as Modbus RTU, DL / T645, and custom protocols, leading to significant protocol compatibility issues during the integration of icing monitoring terminals.

[0003] In existing technologies, icing monitoring terminals typically handle multi-protocol compatibility issues in the following ways: First, they hardcode dedicated parsing programs for each protocol, requiring modification of the terminal firmware and recompilation and reprogramming when a new protocol device needs to be connected, resulting in long development cycles and high maintenance costs; second, they use protocol conversion gateways, which increases system hardware costs and failure risks; and third, they restrict access to devices that only meet specific protocols, severely limiting the system's openness and scalability.

[0004] In addition, existing solutions generally lack a real-time monitoring mechanism for communication quality, and cannot feed back the underlying communication status to the data layer, resulting in a lack of data quality assessment. This makes it difficult for maintenance personnel to detect potential equipment failures or communication interference problems in a timely manner.

[0005] Therefore, how to achieve flexible compatibility of icing monitoring terminals with multiple communication protocols, how to support the access of new protocol devices without modifying hardware and firmware, and how to establish a correlation feedback mechanism between communication quality and data quality are technical problems that urgently need to be solved in this field. Summary of the Invention

[0006] In view of the above-mentioned problems, the present invention provides a multi-protocol compatible standardized interface method, system, device and medium for icing monitoring terminals.

[0007] Therefore, the technical problems solved by this invention are: how to achieve flexible compatibility and unified management of multiple communication protocols in the icing monitoring terminal, how to support the access of new protocol devices without modifying hardware and firmware, and how to establish a correlation feedback mechanism between communication quality and data quality.

[0008] To address the aforementioned technical problems, this invention provides the following technical solution: a multi-protocol compatible standardized interface method for an icing monitoring terminal, comprising: configuring protocol rule sets for multiple hardware interface channels, wherein the protocol rule sets include data parsing rules and data encapsulation rules for the corresponding channels; receiving byte stream data sent by external devices through the hardware interface channels, parsing and verifying the byte stream data according to the protocol rule set corresponding to the hardware interface channel to obtain the original data value; converting the original data value into a standardized data object according to data conversion rules, wherein the standardized data object includes a data value, a data unit, and a data quality identifier, and uploading the standardized data object to the monitoring system; establishing a device mapping relationship, wherein the device mapping relationship associates the device address with the corresponding protocol rule set and hardware interface channel; when receiving a control command from the monitoring system for a target device, searching for the protocol rule set and hardware interface channel corresponding to the target device according to the device mapping relationship, encapsulating the control command into byte stream data according to the found protocol rule set, and sending it to the target device through the corresponding hardware interface channel; monitoring the communication quality of each hardware interface channel, and adjusting the data quality identifier of the standardized data object obtained through the corresponding hardware interface channel according to the communication quality.

[0009] As a preferred embodiment of the multi-protocol compatible standardized interface method for an icing monitoring terminal described in this invention, the step of parsing and verifying the byte stream data according to the protocol rule set corresponding to the hardware interface channel to obtain the original data value includes: identifying the frame start identifier of the byte stream data according to the data parsing rules in the protocol rule set; extracting device address information and function codes from the byte stream data according to the data parsing rules; determining the length and position of the data field according to the data parsing rules; performing integrity verification on the byte stream data according to the verification algorithm in the protocol rule set; and when the integrity verification passes, extracting the original data value from the data field according to the data mapping rules in the protocol rule set.

[0010] As a preferred embodiment of the multi-protocol compatible standardized interface method for an icing monitoring terminal described in this invention, the step of converting the raw data value into a standardized data object according to data conversion rules includes: identifying the sensor type that generated the raw data value; obtaining the corresponding dimension conversion parameter from the data conversion rules according to the sensor type; converting the raw data value into a data value in standard units using the dimension conversion parameter; encapsulating the converted data value, the corresponding data unit, the acquisition timestamp, and the initial data quality identifier into a standardized data object with a structured format; and adding device identifier and observation parameter information to the standardized data object.

[0011] As a preferred embodiment of the multi-protocol compatible standardized interface method for an icing monitoring terminal described in this invention, the method for establishing device mapping relationships includes: establishing a correspondence between device addresses and protocol rule sets, recording the protocol rule set used by each device address; establishing a correspondence between device addresses and hardware interface channels, recording the hardware interface channels connected to each device address; storing the device type and communication parameters corresponding to each device address; generating a device mapping relationship table, which contains the association information of device addresses, protocol rule sets, and hardware interface channels; and providing query and update interfaces for device mapping relationships.

[0012] As a preferred embodiment of the multi-protocol compatible standardized interface method for an icing monitoring terminal described in this invention, the monitoring of the communication quality of each hardware interface channel includes: setting a preset time window for each hardware interface channel; recording the number of communication attempts and the number of successful communication responses received for each hardware interface channel within the preset time window; calculating the communication success rate of each hardware interface channel, wherein the communication success rate is the ratio of the number of successful communication attempts to the number of communication attempts; and comparing the communication success rate with a preset threshold to determine the communication quality status of the corresponding hardware interface channel.

[0013] The beneficial effects of this preferred technical solution are as follows: By calculating the communication success rate by counting the number of communication attempts and successes within a preset time window, compared to judging the success or failure of a single communication, the time window statistical method can filter out single communication failures caused by occasional electromagnetic interference or transient faults, avoiding misjudging the channel as abnormal due to a single failure. When there is continuous interference on the line or equipment failure, the success rate within the time window will remain below the threshold, accurately reflecting the true communication status of the channel.

[0014] As a preferred embodiment of the multi-protocol compatible standardized interface method for an icing monitoring terminal described in this invention, the step of adjusting the data quality identifier of the standardized data object obtained through the corresponding hardware interface channel according to the communication quality includes: determining that the communication quality of the hardware interface channel is abnormal when the communication success rate of the hardware interface channel is lower than the preset threshold; reducing the confidence value corresponding to the data quality identifier in the standardized data object obtained through the hardware interface channel; adding a communication quality abnormality status label to the standardized data object; generating communication quality early warning information, the communication quality early warning information including the abnormal hardware interface channel identifier, communication success rate, and abnormal occurrence time; and uploading the communication quality early warning information to the monitoring system.

[0015] The beneficial effects of this preferred technical solution are as follows: When the communication success rate is lower than a preset threshold, by reducing the confidence level, adding abnormal status tags, and generating early warning information containing abnormal channel identifiers, communication success rates, and abnormal times, maintenance personnel can directly locate the specific faulty hardware interface channel and abnormal time period based on the early warning information, without the need for manual inspection of the communication logs of each channel. Simultaneously, after the confidence level is reduced, upper-layer applications can filter data based on the confidence level, avoiding the use of data with abnormal quality for decision analysis.

[0016] As a preferred embodiment of the multi-protocol compatible standardized interface method for an icing monitoring terminal described in this invention, the step of encapsulating the control command into byte stream data according to the found protocol rule set includes: determining the frame structure format according to the data encapsulation rules in the protocol rule set; filling the target device address in the control command into the address field of the frame structure format; mapping the operation type in the control command to the corresponding function code and filling it into the function code field of the frame structure format; filling the control parameters in the control command into the data field of the frame structure format; calculating the checksum according to the check algorithm in the protocol rule set and adding it to the frame structure format; and generating complete byte stream data.

[0017] This invention provides a multi-protocol compatible standardized interface system for icing monitoring terminals.

[0018] To address the aforementioned technical problems, this invention provides the following technical solution: a multi-protocol compatible standardized interface system for an icing monitoring terminal, comprising: a protocol storage unit for storing multiple protocol rule sets, the protocol rule sets including data parsing rules and data encapsulation rules; a hardware interface pool unit containing multiple hardware interface channels for communicating with external devices; a protocol processing engine unit for parsing, verifying, and encapsulating byte stream data according to the protocol rule sets corresponding to the hardware interface channels; a data conversion unit for converting raw data values ​​into standardized data objects according to data conversion rules; a routing mapping unit for storing and managing device mapping relationships, the device mapping relationships associating device addresses with corresponding protocol rule sets and hardware interface channels; a communication quality monitoring unit for monitoring the communication quality of each hardware interface channel and adjusting the data quality identifier of the standardized data objects according to the communication quality; and a configuration management unit for configuring the protocol rule sets and communication parameters corresponding to each hardware interface channel.

[0019] The present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the multi-protocol compatible standardized interface method for an icing monitoring terminal.

[0020] The present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the multi-protocol compatible standardized interface method for an icing monitoring terminal.

[0021] The beneficial effects of this invention are as follows: By configuring a protocol rule set for the hardware interface channel and establishing a mapping relationship between the device address and the protocol rule set and the hardware interface channel, the decoupling of the interface and the protocol is achieved. When a new protocol device is connected, the connection can be completed by adding a new protocol rule set and updating the device mapping relationship through the configuration management unit, avoiding the need to modify the hardware circuit or re-flash the firmware, shortening the device connection cycle, and reducing the workload of firmware maintenance.

[0022] By statistically analyzing communication success rates within a time window, when the success rate falls below a preset threshold, the confidence value of standardized data objects is reduced and an abnormal status label is added. Simultaneously, an early warning message containing the abnormal channel identifier and success rate is generated and uploaded to the monitoring system. Maintenance personnel can directly locate the faulty channel and abnormal time period based on the early warning information, eliminating the need to check each hardware interface channel individually, thus shortening troubleshooting time.

[0023] Data conversion rules transform raw data values ​​obtained from different protocols into standardized data objects containing data values, data units, timestamps, and data quality identifiers. When processing data, the monitoring system does not need to write dedicated data parsing programs for each protocol; it can directly read fields from the standardized data objects to obtain sensor data and its quality status, reducing the development workload of upper-layer applications. Attached Figure Description

[0024] 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.

[0025] Figure 1 is a general flowchart of a multi-protocol compatible standardized interface method for an icing monitoring terminal provided by an embodiment of the present invention. Detailed Implementation

[0026] To make 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. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0027] Example 1, referring to Figure 1, is an embodiment of the present invention. This embodiment provides a multi-protocol compatible standardized interface method for an icing monitoring terminal, including: Step 1: configuring protocol rule sets for multiple hardware interface channels respectively, wherein the protocol rule sets include data parsing rules and data encapsulation rules for the corresponding channels; Step 2: receiving byte stream data sent by external devices through the hardware interface channels, and parsing and verifying the byte stream data according to the protocol rule set corresponding to the hardware interface channel to obtain the original data value; Step 3: converting the original data value into a standardized data object according to the data conversion rules, wherein the standardized data object includes data value, data unit, and data quality. Step 4: Establish a device mapping relationship, which associates the device address with the corresponding protocol rule set and hardware interface channel; Step 5: When a control command for a target device is received from the monitoring system, the corresponding protocol rule set and hardware interface channel for the target device are found according to the device mapping relationship. The control command is encapsulated into byte stream data according to the found protocol rule set and sent to the target device through the corresponding hardware interface channel; Step 6: Monitor the communication quality of each hardware interface channel and adjust the data quality identifier of the standardized data object obtained through the corresponding hardware interface channel according to the communication quality.

[0028] Ice accretion monitoring terminals need to simultaneously connect to multiple sensor devices from different manufacturers, each employing different communication protocols. For example, a tension sensor might use the Modbus RTU protocol, a temperature sensor the DL / T645 protocol, and a micro-weather station a custom protocol. In traditional solutions, the terminal needs to hard-code dedicated parsing and encapsulation programs for each protocol. When a new protocol device needs to be connected, the firmware must be modified and re-flashed, resulting in long development cycles and difficult maintenance. Furthermore, the data formats and dimensions obtained from different protocols vary, requiring the upper-level monitoring system to write dedicated data processing programs for each protocol. Simultaneously, existing solutions lack real-time monitoring of communication quality, making it impossible to determine the reliability of the collected data. When sensors malfunction or communication lines are interfered with, abnormal data is still reported, affecting the accuracy of the monitoring system's decision-making.

[0029] This embodiment addresses the issue of hard-coded protocol parsing programs by configuring a protocol rule set, including parsing and encapsulation rules, for the hardware interface channel in step 1. Steps 2 and 3 parse byte stream data from different protocols into raw data values, then uniformly convert them into standardized data objects containing data values, units, and quality identifiers using data conversion rules, thus resolving data heterogeneity issues. Step 4 establishes a mapping relationship between device addresses, the protocol rule set, and the hardware interface channel. Step 5 accurately encapsulates control commands and sends them to the target device based on this mapping relationship, resolving the addressing and command delivery issues for multi-protocol devices. Step 6 monitors communication quality and adjusts data quality identifiers to feed back the communication status to the data layer, addressing the problem of missing data reliability assessment. Through the synergy of these steps, flexible access and unified management of multi-protocol devices are achieved.

[0030] Example 2, an embodiment of the present invention, provides a multi-protocol compatible standardized interface method for an icing monitoring terminal based on the previous embodiment, including: further, in step 1, the configuration information of the hardware interface channel is represented by: the configuration information of each hardware interface channel i as a configuration vector Configi: Among them, ProtocolType is the protocol type identifier, such as ModbusRTU or DL / T645; BaudRate is the baud rate; DataBits are the data bits; StopBits are the stop bits; and Parity is the parity method.

[0031] By modifying the parameter values ​​in the configuration vector `Configi` through the configuration management unit, the same RS-485 physical interface can be configured as a Modbus RTU master station or a concentrator mode operating according to other protocols, achieving both hardware resource versatility and flexible interface configuration. When a new protocol device needs to be connected, only the configuration vector of the corresponding hardware interface channel needs to be adjusted, without replacing the hardware or modifying the firmware.

[0032] In step 2, the byte stream data is parsed and verified according to the protocol rule set corresponding to the hardware interface channel to obtain the original data value, including the following steps A1-A4: A1: Identify the frame start identifier of the byte stream data according to the data parsing rules in the protocol rule set; extract the device address information and function code from the byte stream data according to the data parsing rules; A2: Determine the length and position of the data field according to the data parsing rules; A3: Perform integrity verification on the byte stream data according to the verification algorithm in the protocol rule set; A4: When the integrity verification passes, extract the original data value from the data field according to the data mapping rules in the protocol rule set.

[0033] In this embodiment of the application, in step A1, the protocol rule set is defined as follows: The protocol rule set P is defined as a set containing six core elements, including a frame start identifier S, device address information A, data field length rule L, function code field position F, verification algorithm C, and data mapping rule M. The frame start identifier S defines the characteristic byte sequence that marks the start of a frame in the byte stream data and its position within the frame; the device address information A defines the byte position and length of the device address field within the frame; the function code field position F defines the byte position and length of the function code field within the frame; the data field length rule L defines how to extract or calculate the length value of the data field from the frame; the verification algorithm C defines the calculation method of the checksum and the position of the checksum within the frame, such as the CRC-16 algorithm; and the data mapping rule M defines the correspondence between each byte sequence in the data field and physical quantity parameters. The protocol rule set P is stored in the protocol storage unit. When the hardware interface channel receives byte stream data, a parsing operation is performed according to the protocol rule set P configured for that channel.

[0034] In an optional implementation, in step A1, the protocol rule set can be defined by: using a configuration file to define protocol rules, the configuration file containing six configuration items: frame start byte, address position, function code position, data length field position, check type, and data field definition; the system reads the configuration file and parses the values ​​of each configuration item; a protocol parsing process is generated based on the values ​​of the configuration items, the parsing process extracts each field from the byte stream according to the position and method defined by the configuration item; and the generated parsing process is used to parse the received byte stream data.

[0035] In another optional implementation, in step A1, the protocol rule set can also be implemented by: establishing a protocol definition table in the database, where each record corresponds to a protocol, and the fields include protocol name, frame header identifier, address byte range, function code byte range, length byte range, verification method, and data parsing rules; when it is necessary to parse the byte stream of a certain protocol, query the database according to the protocol name to obtain the definition record of that protocol; extract each field in the byte stream according to the byte range in the definition record; verify the integrity of the byte stream according to the verification method; and extract the physical quantity values ​​according to the data parsing rules.

[0036] Furthermore, in step A1, the byte stream data parsing process is as follows: Let the received byte stream data be an ordered set B, represented as: in, For a single byte, n is the total length of the frame in bytes.

[0037] Protocol rule P is defined as a set containing key elements: Where S is the frame start identifier; A is the device address information; L is the data field length rule; F is the position of the function code field; and C is the verification algorithm. For data mapping rules.

[0038] The protocol processing engine executes the parsing process Parse(B, P), first verifying the integrity of the frame, such as checking if the CRC checksum is correct; if the verification passes, the original data value is extracted from the data field according to the mapping rule M. The data mapping rule M explicitly defines the correspondence between each byte sequence in the data domain and physical quantity parameters such as tensile force and temperature.

[0039] In step 3, the raw data values ​​are converted into standardized data objects according to the data conversion rules, including the following steps B1-B5: B1: Identify the sensor type that generated the raw data values; B2: Obtain the corresponding dimension conversion parameters from the data conversion rules according to the sensor type; B3: Use the dimension conversion parameters to convert the raw data values ​​into data values ​​in standard units; B4: Encapsulate the converted data values, the corresponding data units, the acquisition timestamp, and the initial data quality identifier into a standardized data object with a structured format; B5: Add device identifiers and observation parameter information to the standardized data object.

[0040] In this embodiment, step 3 involves the following steps: determining the sensor type T based on the device identifier; extracting the corresponding dimension conversion parameters from the data conversion rules based on the sensor type T, extracting the dimension conversion coefficient for a tension sensor and the proportionality coefficient and offset for a temperature sensor; performing numerical conversion on the original data values, where the tension sensor obtains a standard data value in Newtons by multiplying the original data value by the dimension conversion coefficient, and the temperature sensor obtains a standard data value in degrees Celsius by multiplying the original data value by the proportionality coefficient and adding the offset; and encapsulating the converted standard data value, the corresponding standard unit, the current acquisition timestamp, and the initial confidence value into a structured, standardized data object, and adding the device's unique identifier and observation parameter type information to this object.

[0041] In an optional implementation, in step 3, the data conversion rule can be achieved by: establishing a mapping table from sensor type to conversion parameters, where each record in the mapping table contains three fields: sensor type, conversion coefficient, and target unit; when the original data value is received, searching for the corresponding record in the mapping table according to the sensor type, and reading the conversion coefficient and target unit; performing a multiplication operation on the original data value using the found conversion coefficient to obtain the data value of the target unit; and encapsulating the calculation result, target unit, and timestamp into a standardized data object.

[0042] In another optional implementation, in step 3, the data conversion rules can also be defined as follows: A conversion rule is defined for each sensor type in the configuration file, the rule including the conversion method type and parameter values, where the conversion method type is either linear or polynomial; the configuration file is read and parsed to extract the conversion method type and parameter values ​​corresponding to the sensor type; the appropriate calculation process is selected based on the conversion method type, with linear conversion performing multiplication and addition operations, and polynomial conversion performing exponentiation and accumulation operations; the calculated data values ​​and the unit information in the configuration file are encapsulated into a standardized data object.

[0043] In this embodiment of the application, in step B4, the structured format is achieved by: constructing a standardized data object using the JSON-LD format; defining a value field in the JSON-LD object to store the converted standard data value, defining a unit field to store the corresponding standard unit; defining a timestamp field to store the data acquisition timestamp, defining a confidence field to store the confidence level value corresponding to the data quality identifier; defining a deviceID field to store the unique identifier of the device, defining an observedProperty field to store the observation parameter type; and assembling each field into a complete standardized data object according to the JSON-LD syntax rules. This object contains complete information such as data value, unit, timestamp, confidence level, device identifier, and observation parameters.

[0044] In an optional implementation, in step B4, the structured format can be achieved by: constructing a standardized data object using XML format; defining the root element as SensorData, and defining child elements Value to store data values, Unit to store units, and Timestamp to store timestamps under the root element; defining child elements Confidence to store confidence levels, DeviceID to store device identifiers, and Parameter to store observation parameters; and generating a complete XML document as the standardized data object according to XML syntax rules.

[0045] In another alternative implementation, in step B4, the structured format can also be achieved by: defining a fixed-length binary data structure; allocating fields sequentially in the data structure, with the first 4 bytes storing the data value, the next 2 bytes storing the unit code, the next 8 bytes storing the timestamp, the next 2 bytes storing the confidence score, the next 4 bytes storing the device identifier, and the next 2 bytes storing the observation parameter code; and writing each field value into the corresponding byte position according to big-endian or little-endian byte order to generate a standardized data object in binary format.

[0046] Furthermore, in step B3, the data standardization transformation process involves: executing a standardization transformation function. , is represented as: in, Here are the raw data values, and T represents the sensor type. These are the raw data values ​​parsed from different protocols. Differences exist in units, precision, and format. The data standardization unit performs a transformation based on the sensor type T, generating a standardized data object. Standardized data objects A unified representation is achieved using a structured data format that includes data values, units, timestamps, and can also include device identifiers, the meaning of observation parameters, and data quality reliability, making it convenient for upper-layer applications to use and process directly.

[0047] In step 4, the device mapping relationship is established, including the following steps C1-C5: C1: Establish the correspondence between device addresses and protocol rule sets, and record the protocol rule set used by each device address; C2: Establish the correspondence between device addresses and hardware interface channels, and record the hardware interface channels connected to each device address; C3: Store the device type and communication parameters corresponding to each device address; C4: Generate a device mapping relationship table, which contains the association information of device address, protocol rule set and hardware interface channel; C5: Provide query interface and update interface for device mapping relationship.

[0048] In this embodiment, step 4 establishes the device mapping relationship by: assigning a unique logical address to each target device; establishing a mapping relationship between each logical address and a protocol rule set, recording the protocol type used by the device, such as Modbus RTU or DL / T645; establishing a mapping relationship between each logical address and a hardware interface channel, recording the physical interface channel number connected to the device; storing the association relationship between the logical address, protocol rule set, and hardware interface channel as a routing table; and providing query and update functions for the routing table. When it is necessary to send control commands to the target device, the corresponding protocol rule set and hardware interface channel of the device are obtained by querying the routing table.

[0049] In an optional implementation, in step 4, the device mapping relationship can be established by: creating a device configuration database, where each record contains three fields: device address, protocol type, and interface channel number; when a new device is connected, inserting a new record into the database and filling in the device's address, protocol type, and interface channel number; when it is necessary to look up the device mapping relationship, performing a query operation in the database based on the device address to obtain the corresponding protocol type and interface channel number; and determining the protocol rule set and hardware interface channel to be used based on the query results.

[0050] In another optional implementation, in step 4, the device mapping relationship can also be defined by: using a configuration file to define the device mapping relationship, where each device entry in the configuration file contains three items: device address, protocol name, and channel number; reading the configuration file when the system starts up, parsing each device entry into a correspondence between device address and protocol name and channel number; loading the parsing result into a mapping table structure in memory; and achieving fast lookup of device address to protocol and channel by accessing the memory mapping table.

[0051] Furthermore, in step C4, the routing mechanism for device mapping relationships involves: the system maintaining a routing table R and establishing the logical address of the target device. To use the protocol rules Mapping relationship with the connected hardware channel: in, The unique logical address of the target device; The protocol rules used by the target device; Channel is the hardware interface channel to which the target device is connected.

[0052] Furthermore, in step 5, the encapsulation process of the control instructions is performed by the protocol processing engine through the encapsulation process Encapsulate(Cmd, ),according to The defined frame structure fills the standardized instruction Cmd into the corresponding address field, function code field, and data field, then calculates the checksum, and finally generates a byte stream that the target device can recognize. Then it is sent through the specified Channel.

[0053] In step 5, the control instructions are encapsulated into byte stream data according to the found protocol rule set, including the following steps D1-D9: D1: Set a preset time window for each hardware interface channel; D2: Record the number of communication attempts and the number of successful communication responses received for each hardware interface channel within the preset time window; D3: Calculate the communication success rate for each hardware interface channel, where the communication success rate is the ratio of the number of successful communication attempts to the number of communication attempts; D4: Compare the communication success rate with a preset threshold to determine the communication quality status of the corresponding hardware interface channel.

[0054] D5: When the communication success rate of the hardware interface channel is lower than the preset threshold, the communication quality of the hardware interface channel is determined to be abnormal; D6: Reduce the confidence value corresponding to the data quality identifier in the standardized data object obtained through the hardware interface channel; D7: Add a communication quality abnormality status label to the standardized data object; D8: Generate communication quality early warning information, which includes the abnormal hardware interface channel identifier, communication success rate, and time of abnormality occurrence; D9: Upload the communication quality early warning information to the monitoring system.

[0055] Furthermore, in step D3, the communication success rate is calculated by maintaining a dynamic communication success rate index for each communication channel within the module. This metric, used to quantify communication reliability, is based on a time window. Internal communication history: in, It is in the window The number of successful and valid responses received in communication; This represents the total number of communication attempts.

[0056] When a certain channel When the signal quality falls below the preset alarm threshold, the module can send an early warning to the upper-level system, reporting the degradation of communication quality in the channel and helping maintenance personnel to promptly identify potential sensor failures or line interference issues.

[0057] Further, in step D1, the preset time window is set by determining the preset time window Tw based on the communication frequency of the hardware interface channel. For high-frequency communication channels with more than 10 communications per minute, the time window Tw is set to 10 to 30 minutes; for medium-frequency communication channels with 1 to 10 communications per minute, the time window Tw is set to 30 to 60 minutes; and for low-frequency communication channels with less than 1 communication per minute, the time window Tw is set to 60 to 120 minutes. In step D4, the preset threshold is set by determining the preset threshold based on the application scenario and reliability requirements of the hardware interface channel. For scenarios requiring high reliability, the preset threshold is set to 95% to 98%; for general application scenarios, the preset threshold is set to 90% to 95%; and for scenarios allowing occasional communication failures, the preset threshold is set to 85% to 90%.

[0058] Furthermore, in step D6, the association mechanism between communication quality and data quality identifiers is achieved by: when the module detects the communication success rate of a certain channel... When the confidence value remains consistently low or below the threshold, the confidence value corresponding to that data entry can be actively lowered, or an additional status label can be added to the data object, when collecting data through this channel and generating standardized output. This directly maps the underlying communication quality status to the metadata of the final output data.

[0059] Communication success rate It serves not only as the basis for alarms but also as a reference for internal module decisions. When When the value is too low, the module can automatically try to switch to alternative communication parameters, increase the number of retries, or adjust the polling strategy. The purpose of these internal behaviors is to ensure the continuity and reliability of the final output data.

[0060] Communication reliability assessment is embedded in the entire data acquisition, processing, and reporting chain. It monitors the health of the input process through quantitative indicators and feeds this status information back to the output results. It may also trigger maintenance actions, thus ensuring the credibility of the final output data and the maintainability of the system itself.

[0061] In step D6, the confidence level is reduced by calculating a confidence adjustment coefficient based on the difference between the communication success rate η and a preset threshold. When the communication success rate η is lower than the preset threshold, the confidence adjustment coefficient is set to the ratio of η to the preset threshold. The initial confidence level in the standardized data object is multiplied by the confidence adjustment coefficient to obtain the adjusted confidence level. For example, when the preset threshold is 95% and the communication success rate η is 85%, the confidence adjustment coefficient is approximately 0.89 (85 ÷ 95). If the initial confidence level is 1.0, the adjusted confidence level is 0.89.

[0062] In step 6, the communication quality of each hardware interface channel is monitored, and the data quality identifier of the standardized data object obtained through the corresponding hardware interface channel is adjusted according to the communication quality. This includes the following steps E1-E6: E1: Determine the frame structure format according to the data encapsulation rules in the protocol rule set; E2: Fill the target device address in the control instruction into the address field of the frame structure format; E3: Map the operation type in the control instruction to the corresponding function code and fill it into the function code field of the frame structure format; E4: Fill the control parameters in the control instruction into the data field of the frame structure format; E5: Calculate the checksum according to the check algorithm in the protocol rule set and add it to the frame structure format; E6: Generate complete byte stream data.

[0063] It should be noted that the method in this embodiment involves protocol abstraction and interface virtualization. This is achieved by defining a formal protocol model P and standardized data conversion functions. And the routing mapping R from device address to protocol and channel makes the complex and diverse multi-protocol and multi-interface compatibility issues a problem that can be configured and managed through a unified interface.

[0064] Protocol model P defines how to parse raw data from byte stream B. And how to encapsulate the standardized Cmd instruction into a specific byte stream. It is the core rule base for handling protocol differences.

[0065] Data conversion functions Receive raw data of different formats parsed from different protocols. Combined with sensor type T, it is converted into an internally unified data object. This solves the problem of heterogeneity in data format and units, and achieves a unified data representation.

[0066] The routing mapping R establishes the logical device address Addr to its dedicated protocol rules. And the mapping relationship between physical ports and channels. When communication with a device is required, R ensures that commands and data can be sent and received through the correct hardware interface channel using the correct protocol rules.

[0067] In the uplink data stream, the Channel receives the raw byte stream, finds the corresponding P according to the Channel configuration, and parses it to obtain the data. Combined with sensor type Function to standard data conversion Reporting. In the downlink instruction stream, upon receiving the standard instruction Cmd for a specific Addr, query R to find the corresponding... and Channel, using Wrap Cmd as a byte stream and send it through the specified Channel.

[0068] The method in this embodiment simplifies the development difficulty and long-term maintenance costs of integrating icing monitoring terminals with equipment from different manufacturers.

[0069] Example 3 is an embodiment of the present invention, which provides a multi-protocol compatible standardized interface method for an icing monitoring terminal. In order to verify the beneficial effects of the present invention, scientific demonstration is carried out through experiments.

[0070] This embodiment relates to tower #127 of a 500kV transmission line in a mountainous area. This tower is equipped with an icing monitoring terminal, requiring the integration of three key devices from different manufacturers. Manufacturer A's tension sensor monitors conductor icing load, using an RS-485 communication interface and Modbus RTU protocol. Manufacturer B's tilt sensor monitors the insulator string tilt angle, also using an RS-485 communication interface and a proprietary binary protocol. Manufacturer C's micro-weather station monitors ambient temperature, humidity, and wind speed, using an RS-232 communication interface and a custom ASCII string protocol.

[0071] This invention's solution integrates a multi-protocol compatible standardized interface module between the terminal controller and the three sensors. The terminal controller only needs to interact with the module through a unified API; all protocol conversions and interface adaptations are handled by the module. In traditional solutions, the terminal controller needs to write three different sets of driver code, resulting in inconsistent physical wiring interfaces and making maintenance and upgrades extremely difficult.

[0072] The overall system configuration of this embodiment is as follows: the top-level monitoring center cloud platform communicates with the main control of the icing monitoring terminal through a 4G / 5G network; the middle-layer terminal main control and the interface module of this invention interact through a unified API, and the data uses the standard JSON format. The main control does not process the underlying protocol; the core layer interface module contains a processor, a protocol parsing and encapsulation engine, a protocol library, and a hardware interface pool. The protocol library pre-stores three different protocol rules; the three sensors at the bottom layer that use different protocols and interfaces are respectively connected to three standardized physical interfaces in the hardware interface pool, namely RS-485 channel 1, RS-485 channel 2, and RS-232 channel 3. The module is responsible for isolating the complexity of all underlying protocols at the bottom layer.

[0073] When the system is powered on or deployed, the maintenance engineer uses a laptop to log in to the module's built-in web configuration interface via the module's Ethernet port. The configuration process is as follows: The RS-485 interface connecting the tension sensor to Channel 1 is set to "Channel 1". The engineer uses the web interface drop-down menu to select the "ModbusRTU" protocol type, and simultaneously sets the slave address to 1, baud rate to 9600, data bits to 8, stop bits to 1, and parity to no. This configuration is stored as a configuration vector. Channel 2 is configured with the RS-485 interface of the tilt sensor as "Channel 2". Because the protocol is proprietary, the engineer first defined the rules of this proprietary protocol PB in the custom protocol library according to the manufacturer's documentation. The frame start identifier S is 0xAA0x55; the device address A is the 3rd byte; the data field length L is fixed at 4 bytes, containing a 16-bit signed integer representing the X-axis and Y-axis tilt angles; the function code F is the 4th byte, 0x01 representing reading data; the checksum C is a CRC-16 checksum, from the 1st byte to the second-to-last byte. Subsequently, this newly defined PB protocol is selected for Channel 2, and the baud rate is set to 115200. This configuration is stored as a configuration vector. Channel 3 is configured with the RS-232 interface connected to the micro-weather station set to "Channel 3", the protocol type selected is "Custom ASCII Protocol", the rule PC is defined as using a carriage return and line feed as the end character, and the data format is "T:%f,H:%f,W:%f", representing temperature, humidity, and wind speed respectively. This configuration is stored as a configuration vector: The configuration management unit persistently stores these configuration vectors in the module's Flash memory, and the processor uses the configuration scheduling protocol parsing and encapsulation engine described above during runtime.

[0074] Suppose that at a certain moment, the terminal controller needs to poll the data from three sensors through the module. The terminal controller does not need to understand the details of the underlying protocol; it only needs to send a simple, standardized JSON command to the processor of the interface module via UART or Socket connection: {"command":"poll_all_sensors"}.

[0075] After receiving the instruction, the processor schedules the protocol parsing and encapsulation engine, and initiates data requests in parallel through three channels. For the Modbus RTU on channel 1, the engine automatically generates a Modbus query frame according to Config1 and the PModbus rules in the protocol library. The raw byte stream Breq1 of the request frame is 01 03 00 00 00 01 84 0A, meaning slave address 1, function code 03, reading one register starting at address 0000, and CRC16 checksum 0A84. This frame is sent to the tension sensor via RS-485 channel 1.

[0076] For the private protocol B of channel 2, the engine generates a request frame AA 55 02 01[CRC16-Hi][CRC16-Lo] according to Config2 and PB rules, and sends it to the tilt sensor through RS-485 channel 2.

[0077] When using ASCII protocol C for channel 3, the engine generates a simple ASCII string request "DATA?" according to the rules, and the frame is sent to the micro-weather station via RS-232 channel 3.

[0078] After the sensor returns response data, the module begins the parsing process. The tension sensor response returns a byte stream Bresp1={01 03 02 06 1A 38 44}. The protocol parsing engine executes Parse(Bresp1,PModbus), verifies the frame structure, and calculates the CRC16 checksum. The calculation result matches 38 44, so it passes. According to the Modbus mapping rules, the raw integer value Vraw1=1562 is extracted from the data field 06 1A.

[0079] The tilt sensor response returns a byte stream Bresp2={AA 55 02 01 00 0F FF F0 C3 1E}. The engine executes Parse(Bresp2,PB), searches for the frame header AA 55, and confirms address byte 02. It extracts the 4-byte data field 000F FF F0 of a fixed length. This is interpreted as two 16-bit signed integers: the X-axis tilt angle Vraw2x=15, i.e., 0x000F, and the Y-axis tilt angle Vraw2y=-16, i.e., 0xFFF0.

[0080] The micro-weather station responds with the ASCII string Bresp3="T:-2.5,H:85.0,W:8.3\r\n". The engine executes Parse(Bresp3,PC), recognizing the terminator \r\n. Following the format "T:%f,H:%f,W:%f", it uses a regular expression or string splitting to extract three floating-point numbers: Vraw3T=-2.5, Vraw3H=85.0, and Vraw3W=8.3.

[0081] The data standardization unit begins its work, converting the parsed raw data into a unified, semantically rich JSON-LD format. The conversion function is Dstd=N(Vraw,T).

[0082] For the tension value Vraw1=1562, according to the sensor manual's conversion formula, tension (kN) = Vraw / 100.0. The type T is "TensionSensor". The output of N(1562,"TensionSensor") is: {"@context": "https: / / schema.org / ... / power-network-context.jsonld","device ID": "Tower127_Tension_01","timestamp": "2025-12-01T08:00:00.000Z","observations":{"parameter":"conductor_tension","value":15.62,"unit":"kN","confidence":0.99}}. The tilt angle value is the original value. The N function processes two numbers, generating an array containing the two observations. For meteorological data, the N function generates normalized objects for temperature, humidity, and wind speed respectively. The final processor combines the normalized data from the three sensors into a single JSON array. The processor sends the assembled JSON data array to the remote monitoring center cloud platform via an HTTP POST request through the terminal's main 4G module. The monitoring center can directly parse and use this data without any adaptation.

[0083] The module constantly monitors the communication status of each channel, and records the communication success rate ηi for each channel i. For example, in 10 minutes Tw, channel 2 communicated with the tilt sensor 20 times, Ntotal=20, with 18 successful communications, Nsuccess=18. η2=(18 / 20)×100%=90%. Based on the set 95% threshold, the module will detect the anomaly of η2<95%, and will mark the tilt angle with "status":"degraded" in the reported JSON data, while also logging it. This allows the maintenance system to issue an early warning, prompting an inspection of the tilt sensor or wiring of tower #127 to prevent data interruption and monitoring blind spots.

[0084] To verify the advantages of this invention over traditional solutions, a comparative experiment was conducted. In traditional solutions, the terminal controller uses hard-coded dedicated drivers for each protocol, resulting in scattered physical wiring interfaces and requiring the writing of three different sets of parsing and encapsulation code. New device integration necessitates firmware modification and recompilation / burning, a process that takes 7 to 15 days and involves approximately 2400 lines of code maintenance. Each new device integration requires a new firmware version. Data formats are three heterogeneous formats, requiring dedicated parsing programs. Upper-layer applications need to write approximately 850 lines of parsing and adaptation code for each protocol, and the data only contains raw numerical values. Regarding communication quality monitoring, there is no real-time monitoring; only communication logs are recorded, making it impossible to assess data reliability. Fault location requires manual checking of each channel's logs, averaging 2 to 4 hours, with no proactive early warnings.

[0085] This invention achieves protocol adaptation through the configuration of protocol rule sets. New device access only requires adding the protocol rule set and updating the device mapping relationship, a process that takes 1 to 2 hours. It requires zero driver code, only configuration files, and the firmware version remains unchanged. Data uses a unified JSON-LD standardized format, allowing upper-layer applications to directly read standardized fields without adaptation. The data contains complete semantic information such as values, units, timestamps, confidence levels, device identifiers, and parameter types. The monitoring system development workload is zero lines of adaptation code. For communication quality monitoring, it provides real-time statistics on communication success rates within a time window, dynamically adjusts confidence levels, adds abnormal status tags, and directly locates faulty channels based on early warning information. On average, early warning information is generated and uploaded every 10 to 20 minutes.

[0086] In the experiment, a fourth device was simulated: a new humidity sensor using the DL / T645 protocol. Traditional solutions require a dedicated interface board, DL / T645 drivers, and firmware reprogramming, taking 3-5 days for firmware development and testing, and requiring 30 minutes of downtime for firmware programming. This invention uses existing RS-485 channel 4, requires no firmware modification, can be configured via the web interface in 5 minutes, and hot configuration requires no downtime.

[0087] This embodiment defines a protocol rule set P through protocol abstraction, unifying Modbus RTU, proprietary binary protocols, and custom ASCII protocols into configurable rules, reducing the new device access cycle from 7-15 days to 1-2 hours. By defining a configuration vector Config through interface virtualization, the parameters of the physical interface channel are decoupled from the protocol rules, allowing the same RS-485 interface to be flexibly configured for different protocol modes without hardware replacement. By defining a data transformation function N through data semantics, heterogeneous raw data is converted into JSON-LD standardized objects containing complete semantic information, reducing upper-layer application development workload by 100%. Communication quality anomalies are identified through communication success rate statistics within a time window, dynamically adjusting data confidence and generating early warning information, improving fault location efficiency by 12 times. Accessing new protocol devices requires no firmware or hardware modification, only web interface configuration, reducing configuration time from 3-5 days to 5 minutes, and system downtime from 30 minutes to zero.

[0088] Example 4 is an embodiment of the present invention, which provides a multi-protocol compatible standardized interface system for an icing monitoring terminal, comprising: a protocol storage unit for storing multiple protocol rule sets, the protocol rule sets including data parsing rules and data encapsulation rules; a hardware interface pool unit for including multiple hardware interface channels for communicating with external devices; a protocol processing engine unit for parsing, verifying, and encapsulating byte stream data according to the protocol rule sets corresponding to the hardware interface channels; a data conversion unit for converting raw data values ​​into standardized data objects according to data conversion rules; a routing mapping unit for storing and managing device mapping relationships, the device mapping relationships associating device addresses with corresponding protocol rule sets and hardware interface channels; a communication quality monitoring unit for monitoring the communication quality of each hardware interface channel and adjusting the data quality identifier of the standardized data objects according to the communication quality; and a configuration management unit for configuring the protocol rule sets and communication parameters corresponding to each hardware interface channel.

[0089] This embodiment also provides an electronic device applicable to a multi-protocol compatible standardized interface method for an icing monitoring terminal, comprising: 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 multi-protocol compatible standardized interface method for an icing monitoring terminal as proposed in the above embodiment.

[0090] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements a multi-protocol compatible standardized interface method for an icing monitoring terminal as proposed in the above embodiments.

[0091] The storage medium proposed in this embodiment and the method for implementing a multi-protocol compatible standardized interface for an icing monitoring terminal 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.

[0092] 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, but in many cases the former is a better implementation method. 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.

[0093] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended 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 multi-protocol compatible standardized interface method for icing monitoring terminals, characterized in that: This includes configuring protocol rule sets for multiple hardware interface channels, each containing data parsing and data encapsulation rules for the corresponding channel; receiving byte stream data sent by external devices through the hardware interface channels, parsing and verifying the byte stream data according to the protocol rule set corresponding to the hardware interface channel to obtain the original data value; converting the original data value into a standardized data object according to data conversion rules, the standardized data object containing the data value, data unit, and data quality identifier, and uploading the standardized data object to the monitoring system; and establishing a device mapping relationship, which associates the device address with the corresponding protocol rule set and hardware interface channel. When a control command for a target device is received from the monitoring system, the system searches for the corresponding protocol rule set and hardware interface channel of the target device according to the device mapping relationship. The control command is then encapsulated into byte stream data according to the found protocol rule set and sent to the target device through the corresponding hardware interface channel. The system also monitors the communication quality of each hardware interface channel and adjusts the data quality identifier of the standardized data object obtained through the corresponding hardware interface channel according to the communication quality.

2. The multi-protocol compatible standardized interface method for an icing monitoring terminal as described in claim 1, characterized in that: The step of parsing and verifying the byte stream data according to the protocol rule set corresponding to the hardware interface channel to obtain the original data value includes: identifying the frame start identifier of the byte stream data according to the data parsing rules in the protocol rule set; extracting device address information and function codes from the byte stream data according to the data parsing rules; determining the length and position of the data field according to the data parsing rules; performing integrity verification on the byte stream data according to the verification algorithm in the protocol rule set; and when the integrity verification passes, extracting the original data value from the data field according to the data mapping rules in the protocol rule set.

3. The multi-protocol compatible standardized interface method for an icing monitoring terminal as described in claim 2, characterized in that: The step of converting the raw data values ​​into standardized data objects according to data conversion rules includes: identifying the sensor type that generated the raw data values; obtaining the corresponding dimension conversion parameters from the data conversion rules according to the sensor type; converting the raw data values ​​into data values ​​in standard units using the dimension conversion parameters; encapsulating the converted data values, the corresponding data units, the acquisition timestamp, and the initial data quality identifier into a standardized data object with a structured format; and adding device identifiers and observation parameter information to the standardized data object.

4. The multi-protocol compatible standardized interface method for an icing monitoring terminal as described in claim 3, characterized in that: The establishment of device mapping relationships includes: establishing a correspondence between device addresses and protocol rule sets, recording the protocol rule set used by each device address; establishing a correspondence between device addresses and hardware interface channels, recording the hardware interface channels connected to each device address; storing the device type and communication parameters corresponding to each device address; generating a device mapping relationship table, which contains the association information of device addresses, protocol rule sets, and hardware interface channels; and providing query and update interfaces for device mapping relationships.

5. A multi-protocol compatible standardized interface method for an icing monitoring terminal as described in claim 4, characterized in that: The monitoring of the communication quality of each hardware interface channel includes: setting a preset time window for each hardware interface channel; recording the number of communication attempts and the number of successful communication responses received for each hardware interface channel within the preset time window; calculating the communication success rate of each hardware interface channel, wherein the communication success rate is the ratio of the number of successful communication attempts to the number of communication attempts; and comparing the communication success rate with a preset threshold to determine the communication quality status of the corresponding hardware interface channel.

6. A multi-protocol compatible standardized interface method for an icing monitoring terminal as described in claim 5, characterized in that: The step of adjusting the data quality identifier of the standardized data object obtained through the corresponding hardware interface channel according to the communication quality includes: determining that the communication quality of the hardware interface channel is abnormal when the communication success rate of the hardware interface channel is lower than the preset threshold; reducing the confidence value corresponding to the data quality identifier in the standardized data object obtained through the hardware interface channel; adding a communication quality abnormality status label to the standardized data object; generating communication quality early warning information, which includes the abnormal hardware interface channel identifier, communication success rate, and time of abnormality occurrence; and uploading the communication quality early warning information to the monitoring system.

7. A multi-protocol compatible standardized interface method for an icing monitoring terminal as described in claim 6, characterized in that: The step of encapsulating the control instructions into byte stream data according to the found protocol rule set includes: determining the frame structure format according to the data encapsulation rules in the protocol rule set; filling the target device address in the control instructions into the address field of the frame structure format; mapping the operation type in the control instructions to the corresponding function code and filling it into the function code field of the frame structure format; filling the control parameters in the control instructions into the data field of the frame structure format; calculating the checksum according to the check algorithm in the protocol rule set and adding it to the frame structure format; and generating complete byte stream data.

8. A multi-protocol compatible standardized interface system for an icing monitoring terminal, employing the multi-protocol compatible standardized interface method for an icing monitoring terminal as described in any one of claims 1 to 7, characterized in that, include: The protocol storage unit stores multiple protocol rule sets, which include data parsing rules and data encapsulation rules; the hardware interface pool unit contains multiple hardware interface channels for communicating with external devices; and the protocol processing engine unit parses, verifies, and encapsulates byte stream data according to the protocol rule sets corresponding to the hardware interface channels. The data conversion unit is used to convert raw data values ​​into standardized data objects according to data conversion rules; the routing mapping unit is used to store and manage device mapping relationships, which associate device addresses with corresponding protocol rule sets and hardware interface channels. The communication quality monitoring unit is used to monitor the communication quality of each hardware interface channel and adjust the data quality identifier of the standardized data object according to the communication quality; the configuration management unit is used to configure the protocol rule set and communication parameters corresponding to each hardware interface channel.

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 multi-protocol compatible standardized interface method for an icing monitoring terminal as described in 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 multi-protocol compatible standardized interface method for an icing monitoring terminal as described in any one of claims 1 to 7.

Images