Unified access method for internet of things devices based on dynamic analysis of heterogeneous protocols

Abstract

The present application relates to the technical field of Internet of Things device access and protocol analysis, and particularly relates to a unified access method for Internet of Things devices based on dynamic analysis of heterogeneous protocols, comprising: collecting physical quantity data and capturing original protocol messages through physically isolated external sensors; fusing the physical quantity data into a joint physical feature sequence by time alignment, performing information entropy preliminary field segmentation on the original message, and verifying and correcting the protocol fields by using the mutation inflection points in the sequence; determining the physical semantics according to the time sequence causal relationship that the physical quantity changes precede the field value changes; mapping the protocol fields to the inferred physical quantities according to the semantics, and checking the physical rationality constraints, and marking the fields that do not meet the constraints; pushing the fields with insufficient confidence or being marked and their auxiliary information to a human-machine interface for confirmation and correction, and storing the results in an analysis experience library; generating a standardized physical model according to the confirmed field semantics mapping, and using the model to analyze subsequent messages to complete the unified access of the devices.

Description

Technical Field

[0001] This invention relates to the field of IoT device access and protocol parsing technology, and in particular to a unified access method for IoT devices based on dynamic parsing of heterogeneous protocols. Background Technology

[0002] In scenarios such as Industrial Internet of Things (IIoT) and smart cities, there are a large number of existing dumb terminal devices, such as old frequency converters, PLCs, and sensors. Although these devices have digital communication interfaces, their communication protocol formats and field semantics are often unavailable due to vendor proprietary information, lost documentation, or equipment discontinuation. To achieve unified access to IoT platforms for such devices, existing technologies typically employ manual protocol reverse engineering methods. This involves engineers analyzing raw message data, combining it with changes in equipment operating conditions, manually identifying field boundaries and inferring field semantics, and then writing customized parsing scripts to complete data uploading to the cloud. In addition, some studies have proposed protocol reverse engineering methods based on statistical features. By analyzing the byte entropy distribution and sequence patterns of protocol messages, these methods automatically identify field boundaries and use the statistical correlation between field values ​​and known data to perform semantic inference.

[0003] However, existing protocol reverse engineering methods based on statistical features can only discover the statistical correlation between protocol field values ​​and external data, making it difficult to distinguish the essential difference between "statistical correlation" and "physical causality." This leads to a risk of fundamental misjudgment in semantic inference. For example, the value of a protocol field may be statistically highly correlated with a temperature value, but this field is actually a timestamp rather than a temperature reading, and statistical correlation alone cannot effectively distinguish between them. This results in insufficient reliability of the parsing results, still requiring extensive manual verification, and preventing truly automated unified access for dumb terminal devices. Summary of the Invention

[0004] To overcome the above shortcomings, this invention provides a unified access method for IoT devices based on dynamic parsing of heterogeneous protocols. It aims to improve the problem that existing protocol reverse engineering methods based on statistical features have difficulty distinguishing between statistical correlation and physical causality, which leads to fundamental misjudgments in the semantic inference of protocol fields.

[0005] This invention provides the following technical solution: a unified access method for IoT devices based on dynamic parsing of heterogeneous protocols, comprising: S1. Collect physical quantity data through external sensors that are physically isolated from the communication link of the target device, and simultaneously listen to and capture the original protocol messages of the target device; S2. Align the physical quantity data with time and fuse them into a joint physical feature sequence; perform preliminary field segmentation on the original protocol message based on information entropy, and use the mutation inflection points in the joint physical feature sequence for verification and correction to obtain the protocol fields; S3. For each of the protocol fields, determine the physical semantics of the protocol field based on the temporal causal relationship between its numerical change and the joint physical feature sequence, where the change of physical quantity precedes the change of field value. S4. Map each of the protocol fields to a presumed physical quantity according to its physical semantics, verify whether it meets the physical rationality constraint, and mark the fields that do not meet the constraint. S5. Push protocol fields with insufficient confidence or those marked, along with their associated auxiliary information, to the human-machine interface for manual confirmation or correction, and store the confirmed semantic mapping relationship of the fields in the parsing experience base. S6. Based on the confirmed field semantic mapping relationship, generate a standardized object model of the target device, and use the object model to parse subsequent protocol messages to complete unified device access.

[0006] The present invention has the following beneficial effects: 1. In this invention, physical causal relationship is introduced as the core driving logic for semantic inference of protocol fields. The judgment basis is that the change of physical quantity precedes the change of protocol field value in time and the change magnitude conforms to the preset physical law. This replaces the inference method that simply relies on statistical correlation in the prior art, solves the problem of semantic misjudgment caused by statistical correlation but not physical causality, and significantly improves the reliability of the parsing results.

[0007] 2. In this invention, a dual-engine field boundary recognition mechanism of information entropy initial segmentation and physical mutation inflection point verification and correction is adopted. The physical quantity mutation inflection point is used as an external verification signal to verify and correct the initial segmentation result at the syntax level, which effectively solves the problem of insufficient accuracy of pure statistical methods in field boundary recognition.

[0008] 3. In this invention, an active physical excitation method is used to trigger changes in the physical quantities of the equipment. The physical semantics are determined by observing the response of the protocol field to the physical excitation. There is no need to wait for the natural operating conditions of the equipment to change. The observation time for semantic inference is shortened from relying on the natural changes in the operation of the equipment to within a few seconds of active testing, which significantly improves the parsing efficiency. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating the unified access method for IoT devices based on dynamic parsing of heterogeneous protocols proposed in this invention. Figure 2 This is a schematic diagram of the physical-syntax joint field segmentation process of the unified access method for IoT devices based on dynamic parsing of heterogeneous protocols proposed in this invention. Figure 3 This is a schematic diagram of the active physical stimulus-driven semantic inference process of the unified access method for IoT devices based on dynamic parsing of heterogeneous protocols proposed in this invention. Detailed Implementation

[0010] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0011] Example 1 In the first embodiment of the present invention, the present invention provides a unified access method for IoT devices based on dynamic parsing of heterogeneous protocols, such as... Figures 1-3 As shown, it includes the following steps: S1. Collect physical quantity data through external sensors that are physically isolated from the target device's communication link, and simultaneously listen to and capture the target device's original protocol messages.

[0012] Furthermore, in S1, the raw protocol messages of the target device are monitored and captured, including: Collect physical quantity data generated during the operation of the target device using external sensors; While collecting data, the original protocol messages output by the target device's communication interface are captured through serial port monitoring or bus monitoring. A unified timestamp label is added to both the physical quantity data and the original protocol message to obtain the timestamped physical quantity data and the timestamped original protocol message.

[0013] Specifically, an external sensor array is deployed at the target equipment site. These external sensors include current sensors, vibration sensors, and temperature sensors. The current sensor uses a clamp-on ammeter, which is non-contactly attached to the target equipment's power supply line. The vibration sensor uses a magnetic accelerometer, which is attached to the target equipment's casing. The temperature sensor uses an infrared temperature probe, aimed at the heat-generating area of ​​the target equipment. None of these external sensors are connected to the target equipment's communication interface; their operation is completely independent of the target equipment's communication functions.

[0014] External sensors are connected to the analog or digital acquisition module of the edge gateway. The edge gateway acquires data from the external sensors at a preset sampling frequency. The preset sampling frequency is set according to the physical quantity change characteristics of the target device, for example, 1000 Hz. The edge gateway synchronously records the acquisition time of each sampling point, generating a physical quantity data stream with timestamps. The communication interface of the target device is connected to the communication monitoring module of the edge gateway via a physical connection method such as an RS232 serial cable, RS485 bus, or CAN bus. The communication monitoring module operates in non-acknowledgment mode, passively receiving the level signals output by the target device's communication interface and converting them into byte sequences without sending any instructions or responses to the target device. The edge gateway synchronously records the reception time of each byte sequence, generating a raw protocol message stream with timestamps. The above physical quantity data acquisition and raw protocol message capture are scheduled and executed by the real-time operating system within the edge gateway. The two acquisition tasks run in parallel threads to ensure the synchronization of the two types of data in time and the independence of the acquisition process.

[0015] The edge gateway appends a unique timestamp tag to both the collected physical quantity data and the captured raw protocol messages. The timestamp tag uses the edge gateway's system clock as the unified time base, with a timestamp accuracy in the millisecond range. The physical quantity data after the timestamp tag is appended is stored as timestamped physical quantity data, with each record containing three fields: timestamp, sensor channel identifier, and physical quantity value. The raw protocol messages after the timestamp tag is appended are stored as timestamped raw protocol messages, with each record containing two fields: timestamp and message byte sequence.

[0016] At this point, step S1 is complete, outputting timestamped physical quantity data and timestamped original protocol messages for step S2 to perform time alignment and joint processing.

[0017] S2. Align the physical quantity data with time and fuse them into a joint physical feature sequence; perform preliminary field segmentation on the original protocol message based on information entropy, and use the mutation inflection points in the joint physical feature sequence for verification and correction to obtain the protocol fields.

[0018] Furthermore, in S2, the physical quantity data is time-aligned and fused into a joint physical feature sequence, including: Based on the timestamps carried by the physical quantity data, multiple physical quantity data are aligned on a unified time axis to obtain time-aligned multiple physical quantity data. Feature extraction is performed on time-aligned multi-channel physical quantity data to obtain the feature sequence of each channel of physical quantity data; Multiple feature sequences are fused at the feature level to generate a joint physical feature sequence; Align the joint physical feature sequence with the timestamp of the original protocol message to obtain a joint physical feature sequence that is synchronized with the time of the original protocol message.

[0019] Furthermore, in S2, the protocol fields are obtained, including: The original protocol message is subjected to a random byte sequence scan based on information entropy, and candidate field boundaries are identified based on changes in entropy value; Detect abrupt inflection points of physical quantities in a joint physical feature sequence that is synchronized with the original protocol message time, and obtain the time corresponding to each inflection point; The candidate field boundary is compared with the time corresponding to the mutation inflection point on the time axis. If the candidate field boundary matches the time corresponding to the mutation inflection point, the boundary is confirmed to be valid. If they do not match, the candidate field boundary is corrected according to the time corresponding to the mutation inflection point to obtain the corrected field boundary. Based on the corrected field boundaries, the original protocol message is segmented to obtain the protocol fields.

[0020] Specifically, the edge gateway reads the timestamped physical quantity data output from step S1. This data contains a sequence of physical quantity values ​​from multiple sensor channels, each carrying a millisecond-level timestamp. The edge gateway uses the timestamps as an index to align the multiple physical quantity data streams on a unified time axis. Specifically, the edge gateway sets a unified time reference sequence, with the time interval matching the sampling period of the physical quantity data, for example, 1 millisecond. For each time point, the edge gateway checks if each physical quantity data stream has a sampled value at that time point. If a sampled value exists for a certain physical quantity data stream at that time point, it is used directly. If no sampled value exists for a certain physical quantity data stream at that time point, linear interpolation is used to calculate the interpolation result using the two most recent sampled values ​​before and after that time point. The linear interpolation calculation method is as follows: Suppose interpolation is required at time point t... and These are the two most recent sampling times before and after t. and Let v be the corresponding sampled values, then the interpolation result v at time t is: ; After interpolation, each physical quantity data has a corresponding value at the same time point, resulting in time-aligned multi-channel physical quantity data.

[0021] The edge gateway performs feature extraction on time-aligned multi-channel physical quantity data. Feature extraction uses a sliding window approach, with a window length of W sampling points (e.g., W = 100) and a step size of S sampling points (e.g., S = 50). For each sliding window, the temporal features of the physical quantity data within the window are extracted, including the mean, standard deviation, peak value, and root mean square value. The mean μ is calculated as follows: ; in This represents the value of the i-th sampling point within the window. Standard deviation. The calculation method is as follows: ; The peak value P is the difference between the maximum and minimum values ​​of the sampled values ​​within the window. ; Root mean square value The calculation method is as follows: ; For each physical quantity data point, features are extracted using the sliding window method described above, resulting in a feature sequence for that physical quantity data point. Each element in the feature sequence corresponds to a sliding window and includes four feature values: mean, standard deviation, peak value, and root mean square value. The timestamp of the feature sequence is taken as the center time of the corresponding sliding window.

[0022] The edge gateway performs feature-level fusion on multiple feature sequences to generate a joint physical feature sequence. The fusion method is vector concatenation. Let the feature vector of the feature sequence of the i-th physical quantity data at time t be... Then the joint physical feature vector at time t is the concatenation result of the feature vectors of all N physical quantity data: ; The joint physical feature sequence is a sequence of joint physical feature vectors arranged in chronological order at all sliding window moments.

[0023] The edge gateway aligns the timestamps of the joint physical feature sequence with the timestamps of the original protocol messages. Using the timestamp of each frame in the original protocol messages as a reference, the edge gateway searches for the feature vector in the joint physical feature sequence that is closest to that timestamp. The alignment is completed when the absolute value of the difference between the timestamp of the joint physical feature sequence and the timestamp of the message field is less than a preset alignment threshold. For example If a value of 5 milliseconds is used, this feature vector is taken as the feature vector synchronized with the time of this message field. If the absolute value of the difference is greater than or equal to the preset alignment threshold, it is marked as the message frame lacking synchronized physical features. After alignment, a joint physical feature sequence synchronized with the original protocol message time is obtained.

[0024] The edge gateway performs a random byte sequence scan of the original protocol messages with timestamps based on information entropy. The scan is performed byte-by-byte, calculating the local information entropy for consecutive byte sequences of the original protocol messages. The information entropy is calculated as follows: For a byte window of length L, the frequency of each byte value b within the window is counted, where b ranges from 0x00 to 0xFF. Let p(b) be the probability of byte value b appearing within the window; then the information entropy H of this window is: ; The edge gateway calculates the information entropy value at each location using a sliding window with a step size of 1 byte, resulting in an information entropy sequence. The change in information entropy value between two adjacent windows is then analyzed. Exceeding the preset entropy change threshold For example Taking 2 bits per byte, a candidate boundary for a field is marked at that position. The magnitude of the information entropy value change. The calculation method is as follows: ; in and These are the information entropy values ​​of two adjacent windows, respectively.

[0025] The edge gateway detects abrupt inflection points in physical quantities within the joint physical feature sequence synchronized with the original protocol messages. Inflection point detection is performed separately for each feature component in the joint physical feature vector. Taking the mean feature component of the current channel as an example, the edge gateway calculates the first-order difference sequence of this feature component. The calculation method is as follows: ; in Let be the eigenvalue at time t. This represents the feature value from the previous time step. When the absolute value of the first-order difference exceeds a preset mutation threshold, the preset mutation threshold is taken as the standard deviation of that feature component. 3 times, that is, 3 If the physical quantity changes abruptly, that moment is marked as the inflection point of the abrupt change. The above detection is performed on all feature components, and the union of the detection results of each component is taken to obtain the moment corresponding to each inflection point of the abrupt change.

[0026] The edge gateway compares the candidate boundaries of fields with the corresponding moments of abrupt change inflection points on the timeline. The comparison process calculates the time difference between the timestamp of the packet field corresponding to each candidate boundary and the moment of each inflection point. If the time difference between the timestamp of a candidate boundary and the moment of an inflection point is less than a preset comparison threshold... ,For example If 10 milliseconds is used, the candidate boundary of the field is confirmed to be valid and the boundary is retained. If the time difference between the timestamp of a candidate boundary of a field and the timestamp of all abrupt change inflection points is greater than or equal to the preset comparison threshold, the candidate boundary of the field is corrected by the position of the message field corresponding to the abrupt change inflection point whose timestamp is closest to that of the candidate boundary of the field, and the corrected field boundary is obtained.

[0027] The edge gateway segments the original protocol message based on the corrected field boundaries. Starting from the beginning of the original protocol message, the byte sequence of the original message is divided into consecutive byte segments according to the corrected field boundaries, and each byte segment is a protocol field. After obtaining the protocol fields, the byte offset position and byte length of each protocol field in the original protocol message are recorded for use in the semantic inference step S3.

[0028] S3. For each protocol field, determine the physical semantics of the protocol field based on the temporal causal relationship between its numerical changes and the joint physical feature sequence, where changes in physical quantities precede changes in field values.

[0029] Furthermore, in S3, the physical semantics of the protocol field are determined, including: A preset external physical stimulus is applied to the target device. The external physical stimulus is achieved through external means that do not depend on the target device's communication interface. Record the changes in the values ​​of each protocol field before and after applying external physical stimulus; The numerical changes of each protocol field are compared with the changes in physical quantities caused by external physical stimuli in a time sequence. If the numerical change of a certain protocol field lags behind the changes in physical quantities caused by external physical stimuli in a time sequence, and the direction of change is consistent with the direction of change of physical quantities, then the physical semantics of the protocol field is determined to be the physical quantity type corresponding to the external physical stimuli. For protocol fields that do not respond to external physical stimuli, switch between applying different types of external physical stimuli until their physical semantics are determined.

[0030] Specifically, the edge gateway or cloud platform applies preset external physical stimuli to the target device. These external physical stimuli are achieved through external means that do not rely on the target device's communication interface. Specifically, electrical stimulation is achieved by connecting a programmable electronic load in series on the target device's power supply line. This programmable electronic load is controlled by the edge gateway's digital output module, switching its resistance value according to a preset timing sequence, thereby causing a step change in the supply current. The magnitude of the load switching is controlled within 10% to 20% of the target device's rated current. Mechanical stimulation is achieved by installing an electromagnetic vibrator on the target device's casing. The electromagnetic vibrator is driven by the edge gateway's analog output module, generating a vibration signal with a preset frequency and amplitude. The vibration amplitude is controlled within the range allowed for normal operation of the target device. Thermal stimulation is achieved by deploying a controllable heating module near the target device. This controllable heating module is controlled by the edge gateway's switching output module, generating a temperature change with a preset temperature rise rate.

[0031] While applying external physical stimuli, the edge gateway continuously collects physical quantity data of the target device through external sensors deployed in step S1, recording the changes in physical quantities caused by the external physical stimuli and their starting times. The starting time of the physical quantity change is the point at which the first difference of the corresponding feature component in the joint physical feature sequence first exceeds a preset response threshold. The preset response threshold is taken as 5 times the standard deviation of the steady-state fluctuation of the feature component.

[0032] The edge gateway extracts the numerical changes of each protocol field output in step S2 before and after the application of external physical stimulus. For each protocol field, the edge gateway extracts the original byte value of the protocol field from multiple protocol message frames before the application of external physical stimulus, and converts the original byte value into an integer value according to a preset byte order. The preset byte order is tried in turn with big-endian and little-endian, and the byte order with the value range closest to the range of common physical quantities after conversion is selected as the byte order of the protocol field. This extracts the numerical changes of the protocol field before the application of external physical stimulus. Numerical sequences within a time period and after application Numerical sequences within a time period Take 5 seconds. Take 30 seconds. Calculate the mean of the numerical sequence before application. and standard deviation And the values ​​at each time point after application relative to The degree of deviation. When the values ​​of K consecutive sampling points deviate after application... All exceeded 3 times When the starting time of the K consecutive sampling points is marked as the starting time of the numerical change of the protocol field, K is set to 5.

[0033] The edge gateway performs a time-series comparison between the numerical changes of each protocol field and the physical quantity changes caused by external physical stimuli. The time-series comparison includes two parts: determining the temporal order and determining the consistency of the change direction. In determining the temporal order, the edge gateway calculates the time difference Δt between the start time of the numerical change in the protocol field and the start time of the physical quantity change caused by the external physical stimulus. The calculation method for the time difference Δt is as follows: ; in This represents the starting time of the numerical change in the protocol field. This represents the initial moment of the change in physical quantity caused by external physical excitation. If the value of the protocol field is greater than the preset lag threshold ΔT (ΔT is 100 milliseconds), it is determined that the change in the value of the protocol field lags behind the change in the physical quantity caused by the external physical stimulus in terms of time sequence.

[0034] In determining the consistency of change direction, the consistency between the change trend of the edge gateway's computational protocol field values ​​after the application of external physical stimuli and the change trend of the physical quantities is considered. The change trend is determined by calculating the slope of the numerical sequence within the time period after the application. The slope k is calculated as follows: ; in Let i be the time of the i-th sampling point within the time interval after the application. Let i be the value of the i-th sampling point. This is the mean of all sampling times within the time period after the application. The mean of all sampled values ​​within the applied time period is given, where m is the total number of sampled values ​​within the applied time period. The slope of the protocol field values... slope of change of physical quantity Same sign, and the absolute value of the ratio If the preset ratio is between 0.1 and 10, the direction of change is determined to be consistent.

[0035] When a protocol field simultaneously satisfies both the timing lag condition and the direction of change consistency condition, the edge gateway determines the physical semantics of that protocol field as the type of physical quantity corresponding to the external physical stimulus. For example, when the external physical stimulus is an electrical stimulus causing a step change in the supply current, the physical semantics of the protocol field responding to this stimulus is determined to be current. When the external physical stimulus is a mechanical stimulus causing a vibration change, the physical semantics of the protocol field responding to this stimulus is determined to be vibration amplitude or vibration frequency. When the external physical stimulus is a thermal stimulus causing a temperature change, the physical semantics of the protocol field responding to this stimulus is determined to be temperature.

[0036] For protocol fields that do not respond to external physical stimuli, i.e., those that do not meet the timing lag condition or the consistency of change direction condition, the edge gateway or cloud platform switches to applying different types of external physical stimuli, trying them sequentially according to a preset stimuli type order. The preset stimuli type order is electrical stimuli, mechanical stimuli, and thermal stimuli. The edge gateway repeats the above record and timing comparison process until the physical semantics of all protocol fields are determined.

[0037] For protocol fields that do not respond after traversing all stimulus types, they are marked as suspected non-physical quantity fields, which may be device status bits, function codes, or check codes. The semantics of such protocol fields are then manually verified by step S5 through a human-machine collaboration approach.

[0038] At this point, step S3 is complete, and the physical semantics corresponding to each protocol field are output for use in step S4 to verify physical rationality.

[0039] S4. Map each protocol field to a presumed physical quantity according to its physical semantics, verify whether it meets the physical rationality constraints, and mark the fields that do not meet the constraints.

[0040] Furthermore, in S4, each protocol field is mapped to a presumed physical quantity according to its physical semantics, and its physical rationality constraints are verified, including: For each protocol field, based on the physical semantics determined by S3, the numerical value of the protocol field is mapped to an estimated physical quantity with physical units. Verify whether the estimated physical quantity meets the preset physical rationality constraints. The preset physical rationality constraints include: the rate of change of the estimated physical quantity does not exceed the physical limit rate corresponding to the physical quantity type, the value of the estimated physical quantity is within the reasonable value range corresponding to the physical quantity type, and multiple estimated physical quantities conform to the preset physical equation relationship. Protocol fields that meet the preset physical rationality constraints are marked as verified, while protocol fields that do not meet the constraints are marked as pending confirmation.

[0041] Specifically, for each protocol field, the edge gateway or cloud platform maps the numerical value of that field to an estimated physical quantity with physical units, based on the physical semantics determined in step S3. The mapping process includes both linear and nonlinear mapping methods. For physical quantity types requiring linear mapping, such as current, voltage, and temperature, the linear relationship of the numerical mapping is as follows: ; in For the estimation of physical quantities, units are in the International System of Units (SI). Here, 'a' represents the original value of the protocol field, 'a' is the scaling factor, and 'b' is the offset. The scaling factor 'a' and the offset 'b' are determined based on the typical range of this physical quantity type and the value range of the protocol field. Specifically, the edge gateway extracts the range of change in the protocol field value before and after applying the external physical stimulus in step S3, as well as the actual range of change of the corresponding physical quantity in the joint physical feature sequence. The values ​​of 'a' and 'b' are determined through least-squares linear fitting. Least-squares linear fitting minimizes the sum of squared residuals between the estimated physical quantity after mapping the protocol field value and the measured physical quantity in the joint physical feature sequence. When the physical stimulus applied in step S3 is an electrical stimulus that causes the current to rise from 0 amperes to 2 amperes, if the original value of the protocol field changes accordingly from 0 to 2000, then the scaling factor 'a' is 0.001, and the offset 'b' is 0. In this case, the estimated physical quantity... The unit is ampere.

[0042] For physical quantities with nonlinear mappings, such as vibration frequencies, the numerical mapping relationship is implemented using a lookup table. The lookup table is established when mechanical excitation is applied in step S3, recording the correspondence between protocol field values ​​and measured vibration frequencies. The edge gateway or cloud platform performs physical rationality verification on the estimated physical quantities obtained from the mapping. Physical rationality verification includes constraint checks in three dimensions.

[0043] The first dimension is the rate of change constraint. The edge gateway calculates the rate of change R of each estimated physical quantity between consecutive message frames. The rate of change R is calculated as follows: ; in The estimated physical quantity value corresponding to the j-th frame message. The estimated physical quantity value corresponding to the (j-1)th frame message. This is the time interval between two message frames. When the physical semantics of the presumed physical quantity is temperature, the preset physical limit rate is... The value is 10 degrees Celsius per second. When the estimated rate of change of a physical quantity R is less than or equal to... When the estimated physical quantity is verified by the rate of change constraint, the RR is greater than 1. At that time, the presumed physical quantity failed the rate of change constraint verification.

[0044] The second dimension is the numerical range constraint. The edge gateway determines whether the value of the estimated physical quantity falls within the reasonable value range corresponding to that physical quantity type. For an estimated physical quantity whose physical meaning is temperature, the reasonable value range is -40 to 150 degrees Celsius. For an estimated physical quantity whose physical meaning is current, the reasonable value range is 0 to 1.5 times the rated current of the target device. For an estimated physical quantity whose physical meaning is vibration amplitude, the reasonable value range is 0 to 20 millimeters per second. When the value of the estimated physical quantity falls within the corresponding reasonable value range, the estimated physical quantity passes the numerical range constraint verification.

[0045] The third dimension is the physical equation constraint. The edge gateway performs a physical equation consistency check between multiple physically related estimated physical quantities. When the physical semantics determined in step S3 include both current and temperature, it checks whether the square of the estimated current and the change in estimated temperature satisfy the heating power equation constraint. The heating power equation constraint is checked by calculating the ratio of the square of the estimated current to the change in estimated temperature. If this ratio remains relatively stable across multiple consecutive frames, with fluctuations not exceeding 20% ​​of the average of the ratio, then the physical equation constraint is satisfied. When the physical semantics determined in step S3 include both voltage and current, it checks whether the product of the estimated voltage and estimated current matches the rated power of the target device. If the deviation between the product and the rated power is within 30%, then the physical equation constraint is satisfied.

[0046] The edge gateway marks each protocol field based on the verification results. Protocol fields that pass the rate of change constraint verification, numerical range constraint verification, and physical equation constraint verification are marked as verified. Protocol fields that fail any constraint verification are marked as pending confirmation. For protocol fields marked as pending confirmation, the edge gateway records the specific constraint type and actual deviation value that failed, generating verification anomaly information. Verification anomaly information includes the byte offset position of the protocol field, the physical semantics determined in step S3, the type identifier of the failed constraint, the estimated actual value of the physical quantity, and the constraint threshold. This verification anomaly information is output along with the protocol fields marked as pending confirmation, and is used as auxiliary reference information in step S5 during the human-machine collaboration phase.

[0047] At this point, step S4 is complete, outputting protocol fields marked as verified and those marked as pending confirmation, along with corresponding verification exception information, for use in step S5 for human-machine collaborative processing.

[0048] S5. Push protocol fields with insufficient confidence or those marked, along with their associated auxiliary information, to the human-machine interface for manual confirmation or correction, and store the confirmed semantic mapping relationship of the fields in the parsing experience base.

[0049] Furthermore, in S5, protocol fields with insufficient confidence or those marked, along with their associated auxiliary information, are pushed to the human-machine interface for manual confirmation or correction, including: Obtain protocol fields with semantic inference confidence scores below a preset threshold, as well as protocol fields marked as pending confirmation by S4, and summarize them into a set of protocol fields pending confirmation; For each protocol field in the set of protocol fields to be confirmed, extract its corresponding original protocol message fragment, the physical quantity waveform that is time-synchronized with the protocol field in the joint physical feature sequence, and the current semantics and confidence level inferred by the system to generate associated auxiliary information; The set of protocol fields to be confirmed and the associated auxiliary information corresponding to each protocol field are pushed to the human-computer interaction interface for display. It receives confirmation or correction commands input by humans through a human-computer interaction interface and obtains the semantic mapping relationship of fields after human confirmation.

[0050] Furthermore, in S5, the confirmed field semantic mapping relationships are stored in the parsing experience base, including: From the manually confirmed semantic mapping relationships of the fields, extract the location identifier, physical semantic type, and numerical mapping rules of the protocol fields to generate structured mapping records; The structured mapping record is associated with the device type identifier of the target device to obtain the associated mapping record; The associated mapping records are stored in the parsing experience library, which is used to provide a searchable field semantic mapping reference when connecting similar devices in the future.

[0051] Specifically, the edge gateway or cloud platform aggregates the set of protocol fields to be confirmed. This set includes two categories of protocol fields. The first category consists of protocol fields whose semantic inference confidence level in step S3 is lower than a preset threshold. The confidence level C is calculated by comprehensively considering both the degree of temporal lag and the consistency of the direction of change, and is calculated as follows: ; in This is the time difference between the start time of the change in the protocol field value and the start time of the change in the physical quantity, in seconds. and These represent the slope of change in the protocol field values ​​and the slope of change in the physical quantities, respectively. This is the value after normalizing the absolute value of the slope ratio. The normalization method is to take 1 if the absolute value of the slope ratio is between 0.1 and 10, and 0 otherwise. and These are the weighting coefficients. Take 0.4, The confidence level C is set to 0.6. When the confidence level C is lower than the preset threshold of 0.5, the protocol field is included in the set of protocol fields to be confirmed. The second category consists of protocol fields marked as pending confirmation in step S4. After summarizing the two categories of protocol fields, the edge gateway removes duplicates to obtain a complete set of protocol fields to be confirmed.

[0052] For each protocol field in the set of protocol fields to be confirmed, associated auxiliary information is generated. This associated auxiliary information consists of three parts. The first part is the original protocol message fragment corresponding to the protocol field. Based on the byte offset and byte length of the protocol field recorded in step S2, the edge gateway extracts the hexadecimal representation of several consecutive message frames from the original protocol message captured in step S1, with a minimum of 20 frames extracted. The second part is the physical quantity waveform data synchronized with the protocol field in the joint physical feature sequence. Based on the timestamp of the message frame containing the protocol field, the edge gateway extracts the feature component sequence corresponding to the time period from the joint physical feature sequence generated in step S2 and converts it into a set of plottable waveform data points. The waveform data point set includes two dimensions: time value and physical quantity value. The third part is the current semantics and confidence level inferred by the system, including the physical semantics of the protocol field determined in step S3, the specific value of the confidence level C, and an explanation of the calculation basis for the confidence level. If the protocol field is marked as pending confirmation in step S4, it also includes verification anomaly information. The associated auxiliary information is generated in the form of structured data packets, with one data packet corresponding to each protocol field.

[0053] The set of protocol fields to be confirmed, along with their corresponding auxiliary information, is pushed to the human-computer interaction interface (HCI). Deployed on a cloud platform, the HCI provides access to engineers' terminals via a web service interface. The HCI displays the following: a list of protocol fields to be confirmed, showing the byte offset and length of each field in the original protocol message; the physical semantics and confidence level inferred by the system for that field; a hexadecimal view of the original protocol message fragment, with the corresponding byte highlighted; and a waveform graph of the physical quantity synchronized with the time of that field, plotted with time on the horizontal axis and physical quantity value on the vertical axis, indicating the application time of the external physical stimulus and the start time of the numerical change in that field. The HCI also provides an operation area containing a semantic confirmation button, a semantic correction input box, and a remarks text input box, allowing manual confirmation or correction of the physical semantics of each protocol field.

[0054] The system receives confirmation or correction commands input manually through a human-computer interaction interface. When a user clicks the semantic confirmation button, the system uses the currently inferred physical semantics as the final semantic record. When a user enters a new physical semantic type in the semantic correction input box and clicks confirmation, the system uses the manually entered physical semantics as the final semantic record. Based on the manually confirmed or corrected physical semantics, and combined with the byte offset position and byte length of the protocol field recorded in step S2, the system generates a manually confirmed field semantic mapping relationship. The field semantic mapping relationship includes the starting byte offset of the protocol field in the original protocol message, the byte length of the protocol field, the physical semantic type, and the numerical conversion rules.

[0055] Structured information is extracted from the manually confirmed semantic mapping relationships of the fields. The location identifier of the protocol field is extracted, consisting of a start byte offset and a byte length. The physical semantic type is extracted, which is the manually confirmed physical semantic type. Numerical mapping rules are extracted, including byte order and linear mapping parameters. If the scaling factor and offset of the protocol field have been determined in step S4, they are directly used; otherwise, default mapping parameters are set according to the manually confirmed physical semantic type, for example, a scaling factor of 0.001 and an offset of 0 for the current type. The extracted location identifier, physical semantic type, and numerical mapping rules are combined to generate a structured mapping record.

[0056] The structured mapping record is associated with the device type identifier of the target device. The device type identifier is the model or functional classification identifier of the target device, which is manually entered during the initial deployment and stored in the edge gateway's configuration information. The association method is to add the device type identifier as an additional field to the structured mapping record to obtain the associated mapping record. The fields of the associated mapping record include device type identifier, starting byte offset, byte length, physical semantic type, byte order, scaling factor, and offset.

[0057] The associated mapping records are stored in the parsing experience library. The parsing experience library is deployed on a cloud platform and implemented using a relational database. The data tables in the parsing experience library contain the following: device type identifier, starting byte offset, byte length, physical semantic type, byte order, scaling factor, offset, and record update time. When performing storage operations, the edge gateway or cloud platform first checks if a record with the same device type identifier, starting byte offset, and byte length already exists in the parsing experience library. If it exists, the physical semantic type and numerical mapping rules of that record are updated, and the record update time is refreshed. If it does not exist, a new record is inserted. The parsing experience library provides a searchable field semantic mapping reference when subsequently connecting similar devices. When the edge gateway connects to a target device with the same stored device type identifier, it can directly retrieve the corresponding structured mapping record from the parsing experience library, skipping the inference and verification processes in steps S3 and S4, and directly generating a standardized object model.

[0058] When there is no structured mapping record in the parsing experience base that matches the device type identifier of the current target device, i.e., the first deployment scenario, the system automatically performs protocol field semantic inference and physical rationality verification according to the complete process of steps S3 and S4, and stores the manually confirmed field semantic mapping relationship into the parsing experience base.

[0059] At this point, step S5 is complete, and the manually confirmed field semantic mapping relationships have been stored in the parsing experience base for use in step S6 to generate the standardized object model.

[0060] S6. Based on the confirmed field semantic mapping relationship, generate a standardized object model of the target device, and use the object model to parse subsequent protocol messages to complete unified device access.

[0061] Furthermore, in S6, a standardized object model of the target device is generated, including: Obtain the confirmed field semantic mapping relationship, which includes the position of the protocol field in the original protocol message, the physical semantic type corresponding to the protocol field, and the numerical conversion rule; Based on the physical semantic type, determine the corresponding object model attribute identifier, data type, and physical unit; Based on the position of the protocol field in the original protocol message and the numerical conversion rules, determine the data parsing rules for the object model attributes corresponding to the protocol field; By combining object model attribute identifiers, data types, physical units, and data parsing rules, a standardized object model of the target device is generated, and the standardized object model is registered to the Internet of Things platform.

[0062] Furthermore, in S6, the object model is used to parse subsequent protocol messages, including: The standardized object model is distributed to the edge gateway connected to the target device; Continuously capture subsequent protocol messages generated by the target device through monitoring; The edge gateway extracts the values ​​of each protocol field from the subsequently generated protocol messages based on the protocol field positions and value conversion rules recorded in the standardized object model, and converts them into physical quantity data with physical units. The edge gateway encapsulates the converted physical quantity data into a standard IoT data format and reports it to the IoT platform to complete the unified access of the target devices.

[0063] Specifically, the cloud platform obtains the confirmed field semantic mapping relationships. These relationships originate from the structured mapping records in the parsing experience base associated with the device type identifier of the target device. Using the device type identifier of the target device as the query condition, the cloud platform retrieves all matching structured mapping records from the parsing experience base. Each record contains the starting byte offset, byte length, physical semantic type, byte order, scaling factor, and offset of the protocol fields.

[0064] The cloud platform determines the corresponding object model attribute identifier, data type, and physical unit based on the physical semantic type in each structured mapping record. The object model attribute identifier is generated using the attribute naming rules defined by the IoT platform, which are combinations of the device type identifier and the physical semantic type. For example, when the device type identifier is frequency converter and the physical semantic type is current, the object model attribute identifier is frequency converter current. The data type is determined as follows: when the physical semantic type is current, voltage, or temperature, the data type is single-precision floating-point; when the physical semantic type is vibration amplitude, the data type is double-precision floating-point; and when the physical semantic type is device status, the data type is integer. The physical unit is determined as follows: the physical unit for current is ampere, the physical unit for voltage is volt, the physical unit for temperature is degree Celsius, and the physical unit for vibration amplitude is millimeters per second.

[0065] The cloud platform determines the data parsing rules for the object model attributes corresponding to the protocol field based on the starting byte offset, byte length, and numerical conversion rules of the protocol field in the structured mapping record. The data parsing rules include byte position information and numerical conversion functions. Byte position information, including the starting byte offset and byte length, is used to locate the original byte sequence of the protocol field in subsequent protocol messages. The numerical conversion function is constructed based on byte order, scaling factor, and offset. The input of the conversion function is the original byte sequence, and the output is an estimated physical quantity with physical units. The conversion function first converts the original byte sequence to an integer value according to byte order. Then, the estimated physical quantity is calculated based on the proportionality coefficient a and the offset b. The calculation method is as follows: ; The values ​​of a and b are read directly from the structured mapping record.

[0066] The cloud platform combines the object model's attribute identifiers, data types, physical units, and data parsing rules to generate a standardized object model for the target device. The standardized object model uses the object model definition format supported by the IoT platform and is described in JSON format. The standardized object model contains a top-level object, which includes a device type identifier attribute and an array of attribute lists. Each element in the attribute list array corresponds to an object model attribute, and each object model attribute includes an attribute identifier field, a data type field, a physical unit field, and a data parsing rule field. The data parsing rule field includes five subfields: starting byte offset, byte length, byte order, scaling factor, and offset. After generating the standardized object model, the cloud platform calls the IoT platform's object model registration interface to register the standardized object model with the IoT platform and bind it to the device instance of the target device.

[0067] The cloud platform distributes the standardized object model to the edge gateway connected to the target device. The distribution method involves the cloud platform pushing the JSON description text of the standardized object model to the object model management module of the edge gateway via the MQTT protocol. Upon receiving the JSON description text, the edge gateway's object model management module parses it and loads the object model attribute list and corresponding data parsing rules into the edge gateway's protocol parsing engine. The edge gateway continuously captures subsequent protocol messages generated by the target device through a listening method. The listening method is consistent with that described in step S1; the edge gateway's communication listening module operates in a non-acknowledgment mode, passively receiving the level signals output from the target device's communication interface and converting them into byte sequences, without sending any instructions or responses to the target device.

[0068] The edge gateway's protocol parsing engine extracts the values ​​of each protocol field from subsequently generated protocol messages and converts them into physical quantity data with physical units, based on the protocol field positions and value conversion rules recorded in the standardized object model. For each received protocol message frame, the protocol parsing engine processes it according to the following steps: First, it traverses the attribute list in the standardized object model and sequentially obtains the data parsing rules for each object model attribute. Second, based on the starting byte offset and byte length in the data parsing rules, it extracts the corresponding original byte sequence from the protocol message. Third, based on the byte order in the data parsing rules, it converts the original byte sequence into an integer value. When the byte order is big-endian, the most significant byte comes first; when the byte order is little-endian, the least significant byte comes first. The fourth step is to calculate the estimated physical quantity based on the scaling factor 'a' and the offset 'b' in the data parsing rules. This refers to physical quantity data with physical units. The fifth step is to associate the object model attribute identifiers with the physical quantity data to generate attribute-value pairs.

[0069] The edge gateway encapsulates the converted physical quantity data into a standard IoT data format and reports it to the IoT platform. The standard IoT data format is a JSON-formatted MQTT message. The JSON message structure includes a device identifier field, a timestamp field, and attribute data fields. The device identifier field contains the device instance identifier of the target device, the timestamp field contains the reception time of this protocol message frame, and the attribute data field contains all attribute-value pairs generated in step three. The edge gateway publishes this JSON message to the IoT platform's preset data reporting topic via the MQTT protocol. After receiving the message, the IoT platform stores the physical quantity data in the corresponding device instance's object model data record, completing the unified access of the target device.

[0070] At this point, step S6 is complete. The target device, starting from a dumb terminal with a completely unknown protocol format, undergoes physical isolation for data collection, field segmentation, semantic inference, rationality verification, human-machine collaborative confirmation, object model generation, and edge resolution deployment, ultimately achieving standardized data uploading to the cloud and unified access on the IoT platform.

[0071] Example 2 This embodiment applies the above-mentioned unified access method for IoT devices based on dynamic parsing of heterogeneous protocols to an emergency access scenario for an old frequency converter in an industrial field.

[0072] A frequency converter driving a cooling water pump on a factory production line needs to be replaced with an earlier version of the same model as a spare. The protocol message format output by its RS485 communication interface is inconsistent with the current documentation, and the original manufacturer cannot provide protocol specifications in a timely manner. The integration of this frequency converter's operating data into the IoT platform needs to be completed within 4 hours.

[0073] An external sensor array was deployed and data was acquired according to the method in Example 1. A clamp meter was attached to one phase of the inverter's three-phase output cable, with a range of 0 to 50 amperes. A magnetic vibration sensor was attached to the center of the inverter's housing, with a sensitivity of 100 millivolts per gram. An infrared temperature probe was aimed at the inverter's heatsink area, with a temperature measurement range of -20 to 200 degrees Celsius. All of the above sensors were connected to an ARM Cortex-A72 architecture industrial edge computing gateway via an analog acquisition module. The gateway was equipped with two RS485 listening interfaces. The edge gateway was connected to the inverter's RS485 communication port in non-acknowledgment mode.

[0074] The edge gateway performs time alignment, feature fusion, and preliminary field segmentation based on information entropy according to step S2 of Embodiment 1 to obtain 6 candidate protocol fields. Then, it executes active physical excitation according to a preset excitation sequence. During the electrical excitation phase, the edge gateway controls the programmable electronic load to connect a 0.5-ohm resistor in series in the inverter's power supply circuit for 5 seconds, then disconnects it, causing a step drop in the supply current of approximately 1.8 amperes before recovery. Following step S3 of Embodiment 1, timing comparison and consistency determination of change direction are performed. The starting time of the change in protocol field 2 lags behind the inflection point of the current mutation by 450 milliseconds. The change slope has the same sign as the current change slope, and the absolute value of the slope ratio is 0.98, determining that the physical semantics of protocol field 2 is current. During the mechanical excitation phase, the edge gateway controls the electromagnetic vibrator to apply a 50 Hz vibration signal to the inverter casing for 3 seconds. The change in protocol field 4 lags behind the inflection point of the vibration mutation by 320 milliseconds and has the same change direction, determining that the physical semantics of protocol field 4 is vibration amplitude. During the thermal excitation phase, the edge gateway controls the controllable heating module to heat the heat sink area at a temperature rise rate of approximately 3 degrees Celsius per second for 10 seconds. The numerical change of protocol field 3 lags behind the temperature abrupt change inflection point by 1200 milliseconds and the direction of change is consistent, thus determining that the physical semantics of protocol field 3 is temperature.

[0075] The value of protocol field 1 did not change significantly before and after applying all types of physical excitations. Protocol field 5 was a fixed value of 0xA5A5. Protocol field 6 had no obvious response relationship with any physical quantity. All three protocol fields were marked as suspected non-physical quantity fields.

[0076] The physical rationality of protocol fields 2, 3, and 4 was verified according to step S4 of Example 1. Protocol field 2 has an original value range of 0 to 4095, a scaling factor a of 0.01, an offset b of 0, and an estimated current range of 0 to 40.95 amperes. Both the rate of change and the value range meet the corresponding constraints. Protocol field 3 has an original value range of 0 to 1023, a scaling factor a of 0.16, an offset b of -40, and an estimated temperature range of -40 to 125 degrees Celsius. Both the rate of change and the value range meet the corresponding constraints. The ratio of the square of the estimated current to the estimated temperature change fluctuates by 12% of the mean over 20 consecutive frames, satisfying the heating power equation constraint. All three protocol fields are marked as verified successfully.

[0077] Protocol fields 1, 5, and 6 are included in the set of protocol fields to be confirmed. Associated auxiliary information is generated according to the method in step S5 of Example 1 and pushed to the cloud-based human-machine interface. After reviewing the information, the engineer determines that protocol field 1 corresponds to 0x00, 0x01, and 0x02 when the inverter starts, runs, and stops, respectively, and corrects its physical semantics to reflect the device status. Protocol field 5 is confirmed as the frame header. The sum of the values ​​of protocol field 6 and protocol fields 1 to 5 satisfies the CRC16 checksum, and is confirmed as the checksum.

[0078] After engineer confirmation, a structured mapping record is generated and associated with the inverter model A (equipment type identifier), and stored in the parsing experience library. Following step S6 of Example 1, the cloud platform retrieves all structured mapping records from the parsing experience library, generates a standardized object model, and distributes it to the edge gateway. The edge gateway's protocol parsing engine performs real-time parsing of subsequent protocol messages, encapsulates the converted current value, temperature value, vibration amplitude, and equipment status into a JSON-formatted MQTT message, and reports it to the IoT platform, completing unified device access.

[0079] This embodiment verifies that the method can achieve rapid and standardized access to devices with unknown protocols with minimal manual assistance in real industrial emergency scenarios. The parsing results are accurate, and the accumulated parsing experience can be directly reused, significantly reducing the time required for subsequent access of similar devices.

[0080] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A unified access method for IoT devices based on dynamic parsing of heterogeneous protocols, characterized in that, include: S1. Collect physical quantity data through external sensors that are physically isolated from the communication link of the target device, and simultaneously listen to and capture the original protocol messages of the target device; S2. Align the physical quantity data over time and fuse them into a joint physical feature sequence; The original protocol message is subjected to preliminary field segmentation based on information entropy, and the mutation inflection point in the joint physical feature sequence is used for verification and correction to obtain the protocol fields. S3. For each of the protocol fields, determine the physical semantics of the protocol field based on the temporal causal relationship between its numerical change and the joint physical feature sequence, where the change of physical quantity precedes the change of field value. S4. Map each of the protocol fields to a presumed physical quantity according to its physical semantics, verify whether it meets the physical rationality constraint, and mark the fields that do not meet the constraint. S5. Push protocol fields with insufficient confidence or those marked, along with their associated auxiliary information, to the human-machine interface for manual confirmation or correction, and store the confirmed semantic mapping relationship of the fields in the parsing experience base. S6. Based on the confirmed field semantic mapping relationship, generate a standardized object model of the target device, and use the object model to parse subsequent protocol messages to complete unified device access; In step S3, determining the physical semantics of the protocol field includes: A preset external physical stimulus is applied to the target device, and the external physical stimulus is implemented through an external means that does not depend on the communication interface of the target device; Record the changes in the values ​​of each protocol field before and after applying the external physical stimulus; The numerical changes of each protocol field are compared with the changes in physical quantities caused by the external physical stimulus in a time sequence. If the numerical change of a certain protocol field lags behind the changes in physical quantities caused by the external physical stimulus in a time sequence, and the direction of change is consistent with the direction of change of physical quantities, then the physical semantics of the protocol field is determined to be the physical quantity type corresponding to the external physical stimulus. For protocol fields that do not respond to the external physical stimulus, switch to applying different types of external physical stimuli until their physical semantics are determined.

2. The unified access method for IoT devices based on dynamic parsing of heterogeneous protocols according to claim 1, characterized in that, In S1, the original protocol messages of the target device are monitored and captured, including: The external sensors are used to collect physical quantity data generated during the operation of the target device. While collecting data, the original protocol messages output by the communication interface of the target device are captured through serial port monitoring or bus monitoring. A unified timestamp tag is added to both the physical quantity data and the original protocol message to obtain timestamped physical quantity data and timestamped original protocol message.

3. The unified access method for IoT devices based on dynamic parsing of heterogeneous protocols according to claim 1, characterized in that, In step S2, the physical quantity data is time-aligned and fused into a joint physical feature sequence, including: Based on the timestamps carried by the physical quantity data, the multiple physical quantity data are aligned on a unified time axis to obtain time-aligned multiple physical quantity data. Feature extraction is performed on the time-aligned multi-channel physical quantity data to obtain the feature sequence of each channel of physical quantity data; The multiple feature sequences are fused at the feature level to generate the joint physical feature sequence; Align the joint physical feature sequence with the timestamp of the original protocol message to obtain a joint physical feature sequence that is synchronized with the time of the original protocol message.

4. The unified access method for IoT devices based on dynamic parsing of heterogeneous protocols according to claim 3, characterized in that, In step S2, the protocol fields are obtained, including: The original protocol message is subjected to a random byte sequence scan based on information entropy, and candidate field boundaries are identified based on changes in entropy values. Detect abrupt inflection points of physical quantities in a joint physical feature sequence that is time-synchronized with the original protocol message, and obtain the time corresponding to each inflection point; The candidate boundary of the field is compared with the time corresponding to the inflection point of the mutation on the time axis. If the candidate boundary of the field is consistent with the time corresponding to the inflection point of the mutation, the boundary is confirmed to be valid. If they are inconsistent, the candidate boundary of the field is corrected according to the time corresponding to the inflection point of the mutation to obtain the corrected field boundary. Based on the corrected field boundaries, the original protocol message is segmented to obtain the protocol fields.

5. The unified access method for IoT devices based on dynamic parsing of heterogeneous protocols according to claim 1, characterized in that, In step S4, each protocol field is mapped to a presumed physical quantity according to its physical semantics, and its physical rationality is verified, including: For each of the protocol fields, the numerical value of the protocol field is mapped to an estimated physical quantity with physical units according to the physical semantics determined in S3. Verify whether the estimated physical quantity meets the preset physical rationality constraints. The preset physical rationality constraints include: the rate of change of the estimated physical quantity does not exceed the physical limit rate corresponding to the physical quantity type; the value of the estimated physical quantity is within the reasonable value range corresponding to the physical quantity type; and multiple estimated physical quantities conform to the preset physical equation relationship. Protocol fields that meet the preset physical rationality constraints are marked as verified, and protocol fields that do not meet the constraints are marked as pending confirmation.

6. The unified access method for IoT devices based on dynamic parsing of heterogeneous protocols according to claim 1, characterized in that, In step S5, protocol fields with insufficient confidence or those marked, along with their associated auxiliary information, are pushed to the human-machine interface for manual confirmation or correction, including: Obtain protocol fields with semantic inference confidence scores below a preset threshold, as well as protocol fields marked as pending confirmation by S4, and summarize them into a set of protocol fields pending confirmation; For each protocol field in the set of protocol fields to be confirmed, extract its corresponding original protocol message fragment, the physical quantity waveform that is time-synchronized with the protocol field in the joint physical feature sequence, and the current semantics and confidence level inferred by the system to generate associated auxiliary information; The set of protocol fields to be confirmed and the associated auxiliary information corresponding to each protocol field are pushed to the human-computer interaction interface for display. Receive confirmation or correction commands input manually through the human-computer interaction interface, and obtain the semantic mapping relationship of the fields after manual confirmation.

7. The unified access method for IoT devices based on dynamic parsing of heterogeneous protocols according to claim 1, characterized in that, In step S5, the confirmed field semantic mapping relationship is stored in the parsing experience base, including: From the manually confirmed semantic mapping relationships of the fields, extract the location identifier, physical semantic type, and numerical mapping rules of the protocol fields to generate structured mapping records; The structured mapping record is associated with the device type identifier of the target device to obtain the associated mapping record; The associated mapping records are stored in the parsing experience library, which is used to provide a searchable field semantic mapping reference when connecting similar devices in the future.

8. The unified access method for IoT devices based on dynamic parsing of heterogeneous protocols according to claim 1, characterized in that, In step S6, generating a standardized object model of the target device includes: Obtain the confirmed field semantic mapping relationship, which includes the position of the protocol field in the original protocol message, the physical semantic type corresponding to the protocol field, and the numerical conversion rule; Based on the physical semantic type, determine the corresponding object model attribute identifier, data type, and physical unit; Based on the position of the protocol field in the original protocol message and the numerical conversion rule, determine the data parsing rule for the object model attribute corresponding to the protocol field; The object model attribute identifier, data type, physical unit, and data parsing rules are combined to generate a standardized object model of the target device, and the standardized object model is registered to the Internet of Things platform.

9. The unified access method for IoT devices based on dynamic parsing of heterogeneous protocols according to claim 1, characterized in that, In step S6, subsequent protocol messages are parsed using the object model, including: The standardized object model is distributed to the edge gateway connected to the target device; The protocol messages subsequently generated by the target device are continuously captured through monitoring. The edge gateway extracts the values ​​of each protocol field from the subsequently generated protocol messages based on the protocol field positions and value conversion rules recorded in the standardized object model, and converts them into physical quantity data with physical units. The edge gateway encapsulates the converted physical quantity data into a standard IoT data format and reports it to the IoT platform, thus completing the unified access of the target device.

Images