Cross-protocol operation method and system for internet of things devices in smart park

Abstract

The application relates to the technical field of cross-protocol operation of Internet of Things equipment, and discloses a cross-protocol operation method and system for Internet of Things equipment in a smart park, wherein the method comprises the following steps: acquiring original communication data of the Internet of Things equipment and analyzing the original communication data to obtain a message structure; separating mutually independent control instructions and business data through feature classification; recombining the control instructions and the business data into standard format data after analyzing and encoding the control instructions and the business data; extracting node forwarding records of the standard format data to perform time sequence reconstruction and generate a message forwarding track; performing load difference operation on adjacent nodes to obtain a data amount difference value; and screening out abnormal data. The message forwarding track of the abnormal data is subjected to abnormality detection to locate a fault node, the fault node is analyzed to identify an instruction analysis error node, and finally, a cross-protocol fault node log is generated through link tracking. The method can realize full-link message tracking and accurate fault positioning in cross-protocol operation of the Internet of Things equipment.

Description

Technical Field

[0001] This invention relates to the field of cross-protocol operation technology for IoT devices, and in particular to a method and system for cross-protocol operation of IoT devices in smart parks. Background Technology

[0002] Currently, as the core carrier of urban digital transformation, the level of intelligence in smart parks directly depends on the efficient IoT access capabilities of massive heterogeneous IoT devices. With the exponential growth in the scale of terminal devices such as smart water meters, environmental sensors, and security cameras within the parks, the widespread use of proprietary communication standards by different manufacturers leads to cumbersome device access processes and stringent data exchange barriers. This prevents the formation of a unified device management and collaborative control system, severely hindering the improvement of the overall operational efficiency of the parks.

[0003] In one existing technology, cross-protocol access methods for IoT devices mainly rely on gateways to perform packet-by-packet conversion. The original communication data is completely disassembled at the network layer and then repackaged according to the target protocol format. From the perspective of communication protocol conversion mechanisms, the gateway only executes unidirectional format conversion logic, without recording the forwarding sequence of messages at each node, or the correspondence between the original and converted content. The message body is completely reconstructed during the conversion process, losing globally unique identifiers that can be used for link tracing. Furthermore, the lack of a unified log association mechanism between nodes of different protocols leads to a complete break in the message flow trajectory. Once message loss or response delay occurs, administrators cannot locate the faulty node.

[0004] In summary, existing technologies suffer from low efficiency in locating cross-protocol communication faults during IoT access due to the lack of a unified end-to-end message tracking and identification association mechanism. Summary of the Invention

[0005] This invention provides a method and system for cross-protocol operation of IoT devices in smart parks, so as to realize full-link message tracking and accurate fault location in cross-protocol operation of IoT devices.

[0006] In a first aspect, to address the aforementioned technical problems, the present invention provides a method for cross-protocol operation of IoT devices in smart parks, comprising: The system acquires raw communication data sent by IoT devices, performs feature classification on the raw communication data, and obtains mutually independent control commands and service data. The control commands and the service data are parsed and encoded to obtain a standard command set and a plaintext data stream. The standard command set and the plaintext data stream are then reassembled to obtain standard format data. Obtain the node forwarding records of the standard format data, and reconstruct the time sequence based on the node forwarding records to obtain the message forwarding trajectory; The payload differential operation is performed on adjacent nodes in the message forwarding trajectory to obtain the data volume difference. The standard format data is then filtered based on the data volume difference to obtain abnormal data. Anomaly detection is performed on the message forwarding trajectory corresponding to the abnormal data to identify the faulty node; Obtain the disassembly and assembly records of the faulty node, identify and filter the faulty node based on the disassembly and assembly records, obtain the instruction parsing error node, and perform link tracing to obtain the cross-protocol faulty node log.

[0007] Preferably, the step of performing feature classification on the original communication data to obtain mutually independent control commands and service data includes: The original communication data is parsed to obtain the message structure; Extract the field elements of the message structure, construct a feature vector based on the field elements, and perform decision tree matching on the feature vector to obtain the branch path; The labels are classified according to the branch paths to obtain the classification results; Based on the classification results and preset instruction identifiers, data is extracted from the message structure to obtain independent control instructions and business data.

[0008] Preferably, the step of parsing the original communication data to obtain the message structure includes: Extract the byte sequence of the original communication data, the byte sequence including the message header and the data payload; The message header is matched with a preset private protocol library to obtain the corresponding private protocol; The data payload is structured and mapped according to the private protocol to obtain the message structure.

[0009] Preferably, the step of parsing and encoding the control commands and the service data to obtain a standard command set and a plaintext data stream, and then reassembling the standard command set and the plaintext data stream to obtain standard format data, includes: Extract the control fields of the control instructions and the data fragments of the business data; The control field and the data fragment are parsed according to a preset protocol dictionary to obtain the instruction type identifier and the payload encoding sequence; The instruction type identifier and the payload encoding sequence are encoded and converted to obtain a standard instruction set and a plaintext data stream; The standard instruction set and the plaintext data stream are recombined to obtain standard format data.

[0010] Preferably, the step of obtaining the node forwarding records of the standard format data and reconstructing the message forwarding trajectory based on the node forwarding records includes: Obtain the node forwarding records of the standard format data, parse the node forwarding records to obtain a set of route identifiers and a timestamp sequence; The route identifier set and the timestamp sequence are time-aligned to obtain the link node access sequence; The spatial distribution matrix is ​​obtained by performing coordinate transformation on the access sequence of the link nodes; Feature extraction is performed on the spatial distribution matrix to obtain the message forwarding trajectory.

[0011] Preferably, the step of performing load differential operation on adjacent nodes in the message forwarding trajectory to obtain a data volume difference, and filtering the standard format data based on the data volume difference to obtain abnormal data, includes: The load is calculated for adjacent nodes in the message forwarding trajectory to obtain a load capacity sequence; Perform a differential operation on the load capacity sequence to obtain a redundant byte vector; The redundant byte vector is stripped of protocol overhead to obtain the data volume difference; Standard format data with a difference in data volume greater than a preset inflation threshold are filtered out to obtain abnormal data.

[0012] Preferably, the step of performing anomaly detection on the message forwarding trajectory corresponding to the abnormal data to obtain the fault node includes: Extract the message forwarding trajectory of the abnormal data, and extract the trajectory feature vector of each node in the message forwarding trajectory; Calculate the hyperplane distance from the trajectory feature vector to the preset classification decision boundary; Based on the hyperplane distance and a preset distance threshold, state assignment is performed on the trajectory feature vector to obtain anomaly state labels; Node mapping is performed based on the abnormal status labels to obtain the faulty nodes.

[0013] Preferably, the step of obtaining the disassembly and assembly record of the faulty node, and identifying and filtering the faulty node based on the disassembly and assembly record to obtain the instruction parsing error node, includes: Obtain the disassembly and assembly record of the faulty node, perform feature separation on the disassembly and assembly record, and obtain the protocol header feature and payload encoding sequence; An identifier matching matrix is ​​constructed based on the protocol header features and the payload encoding sequence, and the similarity value between the identifier matching matrix and the preset standard protocol feature library is calculated. Based on the similarity value and a preset similarity threshold, abnormal data is extracted from the identifier matching matrix to obtain the private protocol identifier; Based on the private protocol identifier, the faulty node is marked as a node with instruction parsing error.

[0014] Preferably, the step of performing link tracing to obtain cross-protocol fault node logs includes: Obtain the exception stack information and context data of the instruction parsing error node; Based on the exception stack information and the context data, node extraction is performed to obtain path nodes. Based on the path nodes, a global tracking identifier is generated. Messages are captured based on the global tracking identifier and the path node to obtain the message sequence; The message sequence is subjected to feature extraction and recombination to obtain a message feature vector; Based on the message feature vector and the global tracking identifier, a cross-protocol fault node log containing link tracing information is generated.

[0015] Secondly, the present invention provides a cross-protocol operating system for IoT devices in smart parks, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described above.

[0016] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention extracts the private protocol features and message structure of the original communication data of the interconnection device through the protocol parsing module, uses the decision tree algorithm to classify the message fields by feature, and converts the control instructions and business data into a unified standard format after completely separating them. This solves the problem of complex protocol conversion caused by deep coupling of message instructions and payload in the prior art, eliminates the communication barriers between private protocols of different manufacturers, and provides standard format data with clear structure and parsable fields for subsequent fault location.

[0017] (2) This invention generates a complete message forwarding trajectory by recording the node forwarding records and timestamps of standard format data during cross-network flow, calculates the difference in the amount of pure data after stripping protocol overhead between adjacent nodes and compares it with a preset threshold, and monitors in real time whether the message has abnormal expansion. This solves the problem that the existing technology cannot perceive changes in message form and realizes dynamic visualization monitoring of the entire IoT access link.

[0018] (3) This invention targets abnormal messages that have experienced message inflation, performs abnormal detection on message forwarding trajectories to accurately locate faulty nodes, identifies unidentified private protocol identifiers by analyzing the disassembly and assembly records of nodes, determines the root cause of instruction parsing errors, and generates interaction logs with global tracking identifiers, thus solving the problem of difficult fault location in the prior art and improving the efficiency of troubleshooting IoT access faults. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of a cross-protocol operation method for IoT devices in a smart park provided by the present invention; Figure 2 This is a schematic diagram of the message forwarding trajectory provided by the present invention. Detailed Implementation

[0020] The technical solutions of 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.

[0021] Reference Figure 1 The first embodiment of the present invention provides a method for cross-protocol operation of IoT devices in smart parks, including the following steps: S11, acquire the raw communication data sent by the IoT device, perform feature classification on the raw communication data, and obtain mutually independent control commands and service data; S12, the control instructions and the service data are parsed and encoded to obtain a standard instruction set and a plaintext data stream, and the standard instruction set and the plaintext data stream are reassembled to obtain standard format data; S13, obtain the node forwarding records of the standard format data, and reconstruct the time sequence based on the node forwarding records to obtain the message forwarding trajectory; S14, perform load differential operation on adjacent nodes in the message forwarding trajectory to obtain data volume difference, and filter the standard format data according to the data volume difference to obtain abnormal data; S15, perform anomaly detection on the message forwarding trajectory corresponding to the abnormal data to obtain the fault node; S16, obtain the disassembly and assembly record of the faulty node, identify and filter the faulty node according to the disassembly and assembly record, obtain the instruction parsing error node, and perform link tracing to obtain the cross-protocol faulty node log.

[0022] In step S11, the IoT devices encompass various sensing and control terminals within the park, such as smart water meters, temperature sensors, lighting controllers, and access control terminals. The raw communication data consists of binary data packets natively encapsulated by the devices based on their own proprietary protocols. The data acquisition process is executed in real-time by the hardware message capture module of the park's edge gateway. The acquired raw communication data is reported by the devices in two modes: one is timed proactive reporting, such as smart water meters reporting metering data every 30 minutes; the other is event-triggered reporting, such as access control devices instantly reporting status data when personnel pass through.

[0023] In one implementation, the original communication data is subjected to feature classification to obtain mutually independent control commands and service data, including: The original communication data is parsed to obtain the message structure; Extract the field elements of the message structure, construct a feature vector based on the field elements, and perform decision tree matching on the feature vector to obtain the branch path; The labels are classified according to the branch paths to obtain the classification results; Based on the classification results and preset instruction identifiers, data is extracted from the message structure to obtain independent control instructions and business data.

[0024] In this example, the original communication data is parsed using a protocol to obtain the message structure, including: Extract the byte sequence of the original communication data, the byte sequence including the message header and the data payload; The message header is matched with a preset private protocol library to obtain the corresponding private protocol; The data payload is structured and mapped according to the private protocol to obtain the message structure.

[0025] It should be noted that the raw communication data output by IoT devices is uniformly converted into a continuous hexadecimal byte sequence as the underlying processing carrier. The byte sequence is strictly divided into two independent regions: a fixed-length message header and a variable-length data payload. This division rule is set according to the general encapsulation specification for private messages of IoT devices in smart parks, such as water, lighting, and security systems. The message header stores network control information such as protocol identifiers, routing addresses, and data verification, which is the key basis for identifying the protocol type. The data payload stores business data such as device operating status, metering values, and alarm information, carrying the actual business content of the message. Taking a smart water meter device in a park as an example, the first 12 bytes of the raw communication data byte sequence are fixedly truncated as the message header, and the remaining 48 bytes are designated as the data payload. The boundary between the two regions is fixed and distinguished by byte offsets, which can isolate routing verification control information from business metering data and avoid parsing interference caused by the mixing of the two types of data. Byte sequence extraction uses a hardware message capture module to capture the underlying data packets of the device in real time. After capture, it automatically completes hexadecimal transcoding and storage. The storage precision of a single byte sequence is accurate to a single byte. A millisecond-level timestamp is added synchronously to complete the timing mark. All byte data is without loss or misalignment, providing a complete original data source for subsequent protocol matching.

[0026] It's worth noting that the matching of the message header with the preset private protocol library employs multi-mode string matching for byte-by-byte comparison. The preset private protocol library uses a key-value hash table structure for storage, and each protocol record contains three key pieces of information: a private protocol signature, a header feature byte identifier, and a private protocol mapping rule. The private protocol signature is a unique numerical code that identifies the corresponding private protocol and is used for global indexing of protocol records. The header feature byte identifier is a sequence of feature bytes at a fixed position in the message header for the corresponding private protocol, serving as the matching basis for protocol identification; each private protocol is bound to a unique header feature byte identifier. The private protocol mapping rule defines the offset position, byte length, data type, and conversion rules of each field in the corresponding protocol data payload, used to complete the structured parsing of the payload data. The matching process first extracts the protocol identifier from the message header, then sequentially traverses the header feature byte identifiers stored in the protocol library to complete byte-by-byte verification, and outputs the corresponding private protocol. In this embodiment, the water utility's private protocol signature is represented by the 5th and 6th bytes of the header, which are 68 and 86 in hexadecimal, respectively. A successful match is determined when the corresponding bytes in the header completely match, and the corresponding private protocol is output. If no matching entry is found in the header signature, the message is marked as an unknown protocol message, triggering a protocol library update prompt. Before the protocol library update is completed, the message will not enter the subsequent cross-protocol flow process. After the administrator confirms the protocol signature and completes the protocol library update, the system automatically retrieves the message and re-executes the matching and parsing process. The matching threshold has no ambiguity; only a complete match of the signature bytes can determine the protocol affiliation. This mechanism can filter out a large number of interfering data packets in the park network, reducing the protocol parsing error rate. The time consumed by a single header matching calculation is controlled at the microsecond level, adapting to the real-time processing needs of massive concurrent data reporting from devices in the park.

[0027] It is worth further explaining that the structured mapping of the data payload relies on the private protocol mapping rules in the currently matched private protocol, and uses offset-based field extraction to complete the conversion of unordered machine code into a standardized key-value pair structure. According to the predefined byte segmentation rules of the private protocol mapping rules, the data fields inside the payload are extracted sequentially according to a fixed offset length. Taking the smart water meter private protocol as an example, the first to fourth bytes are extracted from the 48-byte payload and converted to decimal cumulative water consumption in big-endian order. The fifth byte maps the valve on / off status, with a value of 1 representing the valve open and 0 representing the valve closed. The remaining bytes correspond to business fields such as device number, battery voltage, and fault code. All extracted fields are uniformly encapsulated into a key-value pair set consisting of device identifier, operating status, and business metering value, which is the message structure. This structure strips away the differences in underlying byte encoding, eliminates the barriers between private message formats of different manufacturers, and the output content can be directly supplied to the subsequent decision tree classification module to complete the decoupling processing of instructions and payload. After the structured mapping is completed, the integrity of the fields is checked synchronously. Message structures missing key fields are marked as abnormal messages and stored in the log, ensuring the reliability of the entire data processing process.

[0028] It's important to note that the message structure, using a structured key-value pair format, serves as the sole input for field extraction and feature vector construction. Only numeric fields are extracted, filtering out auxiliary fields such as device names and manufacturer numbers, which are purely textual descriptions. This filtering rule is based on statistical data from IoT devices reporting messages within the park. The data shows that over 98% of control commands and business data in the park are stored using numeric fields; text fields are not used in the classification of commands and business data. After filtering, the feature vector dimension can be reduced by approximately 40%, significantly accelerating classification calculations. Taking the message structure output by a smart water meter as an example, it contains three core numeric fields: cumulative water consumption, valve status, and battery voltage. These three sets of values ​​are extracted sequentially and concatenated according to a preset fixed dimension order to generate a one-dimensional standardized first feature vector. An example vector array is [150, 1, 36]. The feature vector dimension order is globally consistent; the message structures of all types of sensors and gateway devices throughout the park follow the same field sorting rule, avoiding dimension misalignment that could cause decision tree matching failures. The vector construction process simultaneously performs numerical normalization preprocessing. The upper and lower limits of each numerical field are pre-calibrated according to the range of the corresponding device and the business value range, uniformly mapping the original values ​​to the 0 to 1 interval, eliminating classification bias caused by differences in the units of different fields. Taking the feature vector of a smart water meter as an example, the cumulative water consumption value range is calibrated to 0 to 1000, the valve status value is 0 or 1, and the battery voltage value range is calibrated to 0 to 50. After normalization calculations are performed separately, they are concatenated in a fixed dimensional order. The constructed feature vector is accompanied by a unique message index identifier and is bound to the original communication data structure for storage, ensuring that the classification results can be traced back to the original message data. The calculation time for a single vector generation is stable at the microsecond level, which can support the real-time classification processing needs of data reported concurrently by thousands of devices.

[0029] It is worth noting that the feature vector is input into the decision tree model to complete layer-by-layer condition matching to generate a unique branch path. Classification and regression trees are used as the basic inference model. The model is trained offline based on millions of historical device message samples from the park. The training samples cover all categories of private protocol messages from water meters, temperature controllers, lighting, and access control systems. The training process divides the training set and validation set into a 7:3 ratio. The model's classification accuracy has been verified to reach 99.2%, accurately distinguishing multiple message types such as status reporting, data collection, and remote control. The matching process executes condition judgments layer by layer from the root node of the decision tree. Taking the example feature vector [150,1,36], the root node determines whether the water consumption is greater than 100. If the value meets the condition, it enters the left subtree. Internal nodes continue to check whether the valve status value is equal to 1. After a successful match, it continues to traverse downwards. The judgment conditions of each node are fixed to industry-standard equipment business thresholds, without dynamic random parameters. Each time a feature vector passes through a node, the corresponding decision logic is recorded. All node decision records are chained together to form a complete and unique branch path. The path completely records the entire reasoning process of the feature vector within the model, providing a complete reasoning basis for subsequent classification label output. If an abnormal situation of no matching branch occurs during vector traversal, the message is directly marked as an unknown type and archived separately, without entering the subsequent payload separation process.

[0030] It is worth further explaining that the classification results are obtained by relying on the classification labels output by the leaf nodes at the end of the branch path. The classification results are then matched against the system's preset instruction identifiers. If a match is successful, field splitting logic is executed to separate the uncoupled control instructions and business data. Each leaf node at the end of each branch path of the decision tree has a pre-stored fixed classification label, including four standard labels: status reporting, remote control, metering data reporting, and fault alarm. The labels correspond one-to-one with the preset instruction identifiers. When the label output by the leaf node completely matches the preset instruction identifier, it is determined that the message carries both control instructions and business data. This determination logic is based on the training rules of the decision tree model. During model training, message samples that simultaneously contain control instruction fields and business data fields are labeled with the corresponding instruction identifiers. Therefore, a successful label match means that the message contains two independent types of data. Following the smart water meter implementation, the leaf node outputs status reporting tags that match preset instruction identifiers. The system extracts the valve status value 1 as a control instruction and the cumulative water consumption 150 as business data from the original message structure. The two types of data are completely isolated with no field overlap, completely eliminating the deep coupling problem between instructions and payloads inherent in proprietary protocol messages. If the classification result does not match the preset instruction identifier, the message is determined to contain only single business data or pure control instructions, and it is directly transferred to the standardization conversion stage without splitting. After splitting, the system automatically verifies the integrity of both types of data. If either a control instruction or any business data item is missing, the message is marked as abnormal and written to the link preprocessing log, ensuring the data integrity of subsequent standard format data conversion and link trajectory tracking stages, reducing the probability of parsing anomalies during cross-protocol conversion from the source.

[0031] In step S12, the control commands and the service data are parsed and encoded to obtain a standard command set and a plaintext data stream. The standard command set and the plaintext data stream are then reassembled to obtain standard format data, including: Extract the control fields of the control instructions and the data fragments of the business data; The control field and the data fragment are parsed according to a preset protocol dictionary to obtain the instruction type identifier and the payload encoding sequence; The instruction type identifier and the payload encoding sequence are encoded and converted to obtain a standard instruction set and a plaintext data stream; The standard instruction set and the plaintext data stream are recombined to obtain standard format data.

[0032] It should be noted that both control commands and business data are structured byte sequences obtained through protocol parsing. Control commands are internally divided into instruction opcode fields and reserved fields at fixed offset positions, while business data is internally divided into business value fields, placeholder fields, and check fields at fixed offset positions. The extraction of control fields and data fragments uses independent control commands and business data as input objects. The extraction rules are based on the underlying byte encoding specifications of various IoT private protocols within the park, and are executed using a fixed offset truncation method. The truncation operation uses the first byte of the corresponding byte sequence as the offset reference. The starting offset and byte length of each field are uniformly marked by the private protocol mapping rules, with no dynamic adjustment range. The control command internally stores the original byte data of device action control. A fixed-length instruction opcode byte segment is extracted from the zero-offset starting position of the control command byte sequence as the control field. This byte segment directly represents the type of device control action and does not contain reserved fields or check bits. Taking a water meter valve control command as an example, the original control command value is directly used as the control field; the business data carries metering and sensing business values. The business value field is extracted from the business data as a data fragment, corresponding to the cumulative water consumption of the water meter as the data fragment. After extraction, the control fields and data fragments are bound to the original communication data index to form a binary data set, which is then uniformly transmitted to the protocol dictionary parsing module. The original values ​​of the fields are not modified throughout the process, ensuring the authenticity of the underlying data and adapting to the unified extraction logic of heterogeneous devices from multiple manufacturers.

[0033] It's worth noting that the pre-built protocol dictionary uses a hash table data structure to pre-store the field mapping relationships of all private protocols in the park. The keys of the hash table are the control field values ​​and data fragment values, and the values ​​are the corresponding instruction type identifiers and payload encoding sequences. The dictionary uses hash addressing to quickly match and parse the control fields and data fragments, outputting the instruction type identifier and payload encoding sequence. For example, when the extracted control fields and data fragments are input into the dictionary for retrieval, the pre-built mapping relationships within the dictionary indicate that the control field value corresponds to a valve opening operation, and the data fragment value corresponds to flow metering data. Parsing is completed by comparing each key-value pair, outputting the instruction type identifier representing valve actions and the payload encoding sequence representing flow metering. The pre-built protocol dictionary supports dynamic expansion; when adding new vendor-specific protocol fields, mapping entries can be added directly without modifying the overall parsing process. The parsing process uses a single-pass traversal retrieval mechanism to avoid performance losses caused by multi-level loops. In scenarios with thousands of concurrent messages, the time taken for a single dictionary match is controlled to the microsecond level. After parsing, the validity of the identifier and sequence is simultaneously verified. If no matching entry is found, it is marked as an unknown field and recorded separately in the protocol exception log.

[0034] It is worth further explaining that the encoding conversion is accomplished using a global hash mapping table, which uniformly converts the parsed instruction type identifiers and payload encoding sequences into a platform-wide standard instruction set and plaintext data stream. The hash mapping table pre-stores the correspondence between various original identifiers and the park's common standard format. Taking a valve control instruction type identifier as an example, it is converted into a platform-wide standard valve opening instruction through hash lookup. The corresponding payload encoding sequence is converted into a readable plaintext data stream according to a preset decimal conversion rule. The conversion operation eliminates encoding differences between different vendor protocols, unifies the expression format of control instructions, and unifies the numerical base of business data, achieving cross-device data format alignment. A numerical verification mechanism is set up during the conversion process. When the plaintext data stream exceeds the device's metering range, it is automatically marked as abnormal. If the standard instruction set lacks key fields, a common placeholder identifier is added. The two types of data after conversion are stored independently, with no byte overlap or data coupling, providing a standardized data foundation for subsequent reassembly and determination.

[0035] Subsequently, the reorganization was completed according to the platform's unified message framework. The standard instruction set was placed in the message header and the plaintext data stream was placed in the message body. The two were layered and encapsulated to generate decoupled standard format data. The instructions and business data inside the message were stored in partitions, and any part of them could be disassembled separately when forwarding across protocols.

[0036] In step S13, the node forwarding records of the standard format data are obtained, and time-series reconstruction is performed based on the node forwarding records to obtain the message forwarding trajectory, including: Obtain the node forwarding records of the standard format data, parse the node forwarding records to obtain a set of route identifiers and a timestamp sequence; The route identifier set and the timestamp sequence are time-aligned to obtain the link node access sequence; The spatial distribution matrix is ​​obtained by performing coordinate transformation on the access sequence of the link nodes; Feature extraction is performed on the spatial distribution matrix to obtain the message forwarding trajectory.

[0037] It should be noted that node forwarding records are automatically generated and cached as standard format data flows through the campus gateway, aggregation switch, and edge nodes. Each record embeds complete routing information carried in the packet appendix header. The parsing operation is performed according to a preset packet field offset table, reading the byte data of the node forwarding record, extracting the node number and corresponding timestamp sequentially from a fixed offset position, stripping redundant fields such as VLAN tags and checksums from the underlying network encapsulation, and eliminating irrelevant data that does not participate in link calculations, reducing data storage and computational pressure. The route identifier set stores the unique device number of all network nodes the message passes through, and the timestamp sequence records the high-precision millisecond-level timestamps of the message arriving at and leaving each node, with example timestamps 1625000 and 1625050. After parsing, the route identifier is bound one-to-one with the corresponding timestamp to form a discrete original dataset, and a global tracking index of standard format data is simultaneously bound to ensure that the trajectory data can be reverse-linked to the original service packets, supporting subsequent fault tracing.

[0038] Subsequently, the routing identifier set and the timestamp sequence are time-aligned to generate an ordered link node access sequence. The time alignment operation first binds each node identifier in the routing identifier set to the corresponding message arrival timestamp in the timestamp sequence, then performs an ascending-order reordering based on the timestamp values. The system uniformly corrects the millisecond-level deviation of each node's local clock. Before generating forwarding records, each network node has completed local clock calibration via the Precision Time Protocol (PTP). The system selects the core switch of the campus as the master clock source. Each node periodically interacts with the master clock source, calculates the path delay and local clock deviation, and dynamically adjusts the local clock frequency based on the calculation results, keeping the time deviation of all network nodes within microseconds. Each node generates a timestamp based on this calibrated unified time base, ensuring that all timestamps are based on the same absolute time base and avoiding time sequence errors. Taking the data in this embodiment as an example, after time sequence correction, it is determined that the message first passes through the first network node and then flows to the second network node, and the complete link node access sequence is obtained by splicing them in chronological order. The alignment logic is globally unique. Forwarding records of data in the same standard format can only generate one ordered sequence, and there is no situation of node time sequence reversal or duplicate records. If the forwarding record has incomplete data such as missing timestamps or blank routing identifiers, it is directly marked as a link abnormal packet and stored in the log, and will no longer participate in subsequent coordinate transformation calculations, thus avoiding invalid data from interfering with trajectory generation.

[0039] It should be noted that the conversion from link node access sequence to node spatial distribution matrix relies on the topology mapping table of the pre-installed equipment to complete the coordinate mapping, transforming abstract digital node identifiers into a quantifiable spatial distribution matrix. The topology mapping table pre-enters the logical positions of all network nodes in the park, with each node number uniquely corresponding to a set of horizontal and vertical two-dimensional coordinates, unaffected by changes in the physical installation location of the equipment. For example, the first network node is matched with logical coordinates (10, 20), and the second network node is matched with logical coordinates (30, 50). The ordered coordinate points are filled into the matrix rows and columns in chronological order, generating a two-row, two-column node spatial distribution matrix. The matrix row numbers correspond to the message transmission sequence, and the column numbers correspond to the horizontal and vertical coordinate values, respectively, fully carrying the spatial distribution characteristics of the message transmission path. The unified quantification format facilitates subsequent batch calculations by the algorithm. The matrix generation process does not add or delete node coordinates, completely preserving the spatial location information of all nodes in the link.

[0040] It is worth further explaining that feature extraction and smooth reconstruction are performed based on the spatial distribution matrix, outputting a message forwarding trajectory that can be used for anomaly detection. Feature extraction uses principal component analysis (PCA) to reduce the matrix dimensionality. The original node spatial distribution matrix is ​​2×N dimensional, where N is the number of link nodes, and each column corresponds to the two-dimensional logical coordinates of a node. The covariance matrix of the matrix is ​​calculated, and its eigenvalues ​​and eigenvectors are extracted. The two principal components with eigenvalue contribution rates greater than 95% are selected to construct a projection matrix. The original 2×N matrix is ​​multiplied by the projection matrix to obtain a 2×2 dimensionality-reduced matrix. The diagonal elements of this matrix are taken as the trajectory eigenvalues ​​after dimensionality reduction, forming a low-dimensional trajectory eigenvector. An example output eigenvector is (5,8). Then, a spline interpolation model is used to smoothly fit the discrete eigenvectors, eliminating trajectory breakpoints caused by discrete coordinate points and generating a continuous, visualized message forwarding trajectory. This trajectory completely restores the entire link transmission path of standard format data from the source device to the platform, fully recording the spatial location and temporal relationship of the message as it passes through each network node, providing a complete quantitative data source for subsequent calculation of data volume differences between adjacent nodes and determination of message expansion. After the trajectory is generated, it is synchronously stored in the link tracing database and bound to a standard format data index to achieve permanent retention of the entire process message transmission path, providing intuitive link evidence for later fault review.

[0041] Reference Figure 2 This diagram illustrates the complete flow of standard format data between network nodes. The horizontal axis (logical X-axis) and vertical axis (logical Y-axis) in the diagram represent the logical locations of all network device nodes obtained through a topology mapping table. Red nodes represent specific network devices through which standard format data passes, and blue lines represent the transmission paths of the standard format data. This invention successfully reconstructs the path associations before and after cross-protocol conversion by constructing message forwarding trajectories, making the data transmission process transparent and visible, solving the problem of link breakage, and providing a physical and logical mapping basis for accurate location of faulty nodes.

[0042] In step S14, payload differential calculation is performed on adjacent nodes in the message forwarding trajectory to obtain data volume difference. Based on the data volume difference, the standard format data is filtered to obtain abnormal data, including: The load is calculated for adjacent nodes in the message forwarding trajectory to obtain a load capacity sequence; Perform a differential operation on the load capacity sequence to obtain a redundant byte vector; The redundant byte vector is stripped of protocol overhead to obtain the data volume difference; Standard format data with a difference in data volume greater than a preset inflation threshold are filtered out to obtain abnormal data.

[0043] It should be noted that the calculation of the payload capacity sequence uses the original parameters of the packets of each pair of adjacent nodes within the message forwarding trajectory as input. The extracted parameters include two core indicators: the total packet length of a single node and the network encapsulation level. These two types of parameters are directly read from the node transmission logs bound to the trajectory. Taking any pair of adjacent nodes within the trajectory as an example, the packet length of the preceding network node is 1500 bytes and the encapsulation level is 3, while the packet length of the following network node is 1650 bytes and the encapsulation level is 4. The payload evaluation first performs normalization processing on the two parameters separately, with the packet length having a normalization upper limit of 2000 bytes and the encapsulation level having a normalization upper limit of 5. After uniformly mapping to the value range of 0 to 1, the two parameters are then weighted and summed to obtain a comprehensive score. The weighting coefficients are determined through experimental statistical calibration. The calibration process collected 5000 sets of normal cross-protocol conversion message data for each of the three mainstream protocols (Ethernet, LoRa, and NB-IoT) within the park. Pearson correlation analysis was used to calculate the correlation coefficients between message length, encapsulation level, and actual service payload capacity. The correlation coefficients for message length and encapsulation level were found to be 0.82 and 0.18 respectively. After rounding, the weights for message length and encapsulation level were set to 0.8 and 0.2 respectively. This weighting ratio can control the payload capacity calculation error within 1.5%, adapting to the payload assessment requirements of multi-protocol mixed transmission scenarios. The comprehensive score was multiplied by a conversion factor of 900 bytes / unit score, and then superimposed with the calibrated 772-byte baseline payload value to finally obtain the payload capacity value per byte. The calculation showed that the comprehensive score for the first network node was 0.72, corresponding to a payload characteristic value of 1420 bytes; the comprehensive score for the second network node was 0.82, corresponding to a payload characteristic value of 1510 bytes. These were arranged sequentially according to the node transmission time sequence to form a payload capacity sequence. The calculation process extracts only the payload data related to the message body business, and removes irrelevant data packets such as heartbeat packets and gateway keep-alive frames to ensure that the sequence values ​​only reflect the volume changes of the target standard format data. At the same time, the sequence is uniquely indexed and bound to the message forwarding trajectory to achieve a one-to-one correspondence between payload data and transmission links.

[0044] It is worth noting that the redundant byte vector is obtained by performing a first-order difference operation on the payload capacity sequence. The difference operation is used to quantify the incremental fluctuation of message volume between adjacent nodes and accurately capture the byte increase or decrease changes when the message is forwarded across protocols. The difference logic is to subtract the payload capacity of the preceding node from the payload capacity of the subsequent node. For the example sequence [1420, 1510], the calculation is performed to obtain a difference of 90, generating a one-dimensional redundant byte distribution vector

[90] . The operation adopts a segmented sliding difference mechanism. If the message forwarding trajectory contains N link nodes, N-1 sets of redundant byte vectors are generated to completely cover the payload fluctuation of all adjacent nodes in the entire link. The difference operation maintains the numerical unit as bytes throughout, and there is no logical defect of mixing data of different units for calculation. If the difference result is negative, it means that byte compression occurred when the message passed through the node. It is directly marked as a normal transmission sample, skips the subsequent overhead stripping process, and only retains the vector with a difference result greater than 0 to enter the next step of processing, reducing the invalid operation overhead.

[0045] It's worth further explaining that the protocol overhead stripping operation is used to remove the fixed encapsulation bytes inherent in the network protocol, eliminating the byte increment interference caused by normal protocol encapsulation, and obtaining the data volume difference after stripping. During underlying network forwarding, standard protocol overhead such as VLAN tags, tunnel headers, and checksum fields are automatically added. This byte increase is a normal transmission loss in the industry and cannot be used as a basis for judging message inflation. The system has a built-in protocol feature matching library that can automatically identify the communication protocol used by the current link, match the corresponding protocol fixed overhead byte value, and directly deduct it from the redundant byte vector value. In the example, the original redundant byte vector value is 90. After stripping 30 bytes of various protocol fixed overheads, the final data volume difference is 60 bytes. The stripping logic distinguishes between low-power IoT protocols and broadband Ethernet protocols. The fixed overheads of the two types of protocols are stored separately to avoid calculation errors caused by uniform deduction. After stripping, the details of the deducted overhead bytes are synchronously recorded and stored in the link log, facilitating subsequent differentiation between normal encapsulation increments and abnormal inflation increments.

[0046] Subsequently, the difference in data volume after stripping is compared and filtered against a preset expansion threshold. Standard format data with a difference exceeding the preset expansion threshold is identified as abnormal data; standard format data with a difference less than or equal to the preset expansion threshold is considered to have normal packet volume fluctuations and is directly transferred to the regular link storage process without initiating a fault location process. The expansion threshold in this solution is fixed at 50 bytes, determined through experimental statistical calibration. The calibration process collected non-protocol overhead byte increment data from 10,000 sets of normal cross-protocol conversion packets within the park. The maximum increment value under the 95% confidence interval was found to be 48 bytes, which was rounded down and set to 50 bytes. This threshold can control the false alarm rate within 2% while ensuring that over 98% of abnormal data can be effectively detected. Taking a calculated data volume difference of 60 bytes as an example, 60 is greater than the preset threshold of 50, and the corresponding standard format data is classified as abnormal data, triggering SVM abnormal node detection; if the data volume difference is less than or equal to 50 bytes, the packet volume change is considered to be normal fluctuations and is directly transferred to the regular link storage process without initiating a fault location process. After screening, abnormal data are marked with anomaly tags and bound to the corresponding message forwarding trajectory, data volume difference, and out-of-limit node number to form a complete abnormal data packet, providing a complete quantitative basis for subsequent fault node location.

[0047] In step S15, anomaly detection is performed on the message forwarding trajectory corresponding to the abnormal data to obtain the fault node, including: Extract the message forwarding trajectory of the abnormal data, and extract the trajectory feature vector of each node in the message forwarding trajectory; Calculate the hyperplane distance from the trajectory feature vector to the preset classification decision boundary; Based on the hyperplane distance and a preset distance threshold, state assignment is performed on the trajectory feature vector to obtain anomaly state labels; Node mapping is performed based on the abnormal status labels to obtain the faulty nodes.

[0048] It should be noted that the trajectory feature vector extraction uses the message forwarding trajectory bound to the identified abnormal data as the data source. The extraction dimensions cover three core quantitative indicators during node operation: real-time throughput, message processing latency, and number of concurrent connections. The indicator data are all collected synchronously from node forwarding logs and traffic monitoring snapshots, with units of KB / s, ms, and number of connections, respectively. Taking a network node in the link as an example, the throughput is 800KB / s, the processing latency is 50ms, and the number of concurrent connections is 5 during the message flow period. These three sets of values ​​are concatenated according to a fixed time sequence dimension to generate a three-dimensional trajectory feature vector [800, 50, 5]. The order of the trajectory feature vector dimensions is globally unified. All gateways, switches, and edge forwarding nodes follow the same field arrangement rules to avoid dimension misalignment that could lead to model calculation failure. The extraction process filters out invalid monitoring data during the node's idle period and only extracts valid indicators within the time window of standard format data passing through the node. After the vector is generated, it is bound to the node number and the unique index of the abnormal data to ensure that the feature vector can be back-linked to the link trajectory and the original message, providing standardized data for the input of the support vector machine model.

[0049] Subsequently, the hyperplane distance is calculated using a support vector machine (SVM) classification model trained offline. The model training process is as follows: 500,000 historical normal link operation samples and 50,000 message inflation failure samples were collected from the park and divided into training and validation sets in a 7:3 ratio. A radial basis function (RBF) was used as the kernel function, with a penalty coefficient C=10 and a kernel parameter gamma=0.1. Five-fold cross-validation was used for model optimization, and the final model achieved a precision of 98.7% and a recall of 97.2% on the validation set. The classification decision boundary was generated by fitting the SVMs from the training set, which can distinguish between the normal working state and the abnormal handling state of a node. The three-dimensional trajectory feature vector corresponding to a single node was input into the model, and the vertical distance from the vector coordinate point to the classification hyperplane was calculated in the multi-dimensional feature space. This distance quantifies the severity of the node's operating indicators deviating from the standard operating conditions. The example feature vector yielded a hyperplane distance of 15. The distance value is a dimensionless scalar, and there are no logical defects in the mixed operation of vectors and scalars throughout the calculation process. All dimensional features participate in the distance calculation simultaneously, ensuring that no abnormal information in any dimension of throughput, latency, or concurrent connections is missed. The feature vectors of all nodes within the same link are used to calculate the distance in sequence. Each distance result is recorded synchronously with the corresponding node identifier, forming a dataset in which nodes and their degree of deviation are matched one-to-one.

[0050] It is worth further explaining that after comparing the hyperplane distance with a preset distance threshold, abnormal status labels are assigned. The distance threshold is fixed at 10, which was determined through experimental statistical calibration. The calibration process statistically analyzed the hyperplane distance data of 5000 normal nodes and 500 abnormal nodes. When the distance is greater than 10, the accuracy of abnormal node identification reaches 99.2%, hence the threshold of 10. If the hyperplane distance corresponding to the feature vector is greater than 10, the node's operating state is determined to deviate from the normal range, and an abnormal status label with a value of 1 is assigned. If the distance is less than or equal to 10, a normal label with a value of 0 is assigned, and the node is not included in the fault node screening range. In the example, the hyperplane distance 15 is greater than the threshold 10, and the feature vector corresponding to this node is labeled with the abnormal label 1. The label assignment logic does not have an ambiguous judgment range; there are only two label types: normal and abnormal. After assignment, the label, hyperplane distance, and node feature vector are packaged and stored in an abnormal temporary cache, and simultaneously written to the link monitoring log, completely preserving the quantitative basis for node abnormality determination, facilitating subsequent root cause review of faults.

[0051] Two topology mappings are performed based on node data carrying abnormal status tags to deduce the final faulty node. The first mapping extracts the topology coordinates corresponding to nodes with abnormal tags. The node number is matched with the two-dimensional coordinates using the topology mapping table built into the trajectory. In this example, the abnormal node corresponds to horizontal coordinate 20 and vertical coordinate 30. The node number here is a logical sequence identifier within a single message forwarding trajectory, used only to represent the sequential order of nodes the message passes through. It is only valid within the calculation scope of this link and does not possess global uniqueness. The second mapping traverses and matches the two-dimensional coordinates with the global network topology matrix. The matrix stores the correspondence between the coordinates and physical device numbers of all forwarding devices in the campus. Coordinate retrieval is performed through spatial mapping, outputting a unique corresponding physical device number. The physical device number is a globally unique code for the physical forwarding device in the campus network, corresponding to the actual hardware devices such as gateways, backbone switches, and edge nodes, and is bound to complete information such as the device's physical installation location, operation logs, and maintenance records. In this embodiment, the core switch with the corresponding physical device number is identified as the faulty node, which is the source of this message bloat phenomenon. The mapping process avoids the problem of confusion between logical node numbers and physical devices. The two mappings accurately distinguish logical link nodes from on-site physical network devices, avoiding fault location errors caused by non-unique logical numbers. After mapping, the physical device number, coordinates, anomaly label, hyperplane distance, and anomaly data index are encapsulated into a fault dataset. The physical device number is used as the retrieval primary key to retrieve the disassembly and assembly records of the corresponding node. The complete fault dataset retains the quantitative basis for fault determination, which is used for subsequent root cause analysis and operation and maintenance review, completing the accurate location of faulty nodes and significantly reducing the time spent by park operation and maintenance personnel in troubleshooting.

[0052] In step S16, the disassembly and assembly record of the faulty node is obtained, and the faulty node is identified and filtered according to the disassembly and assembly record to obtain instruction parsing error nodes, including: Obtain the disassembly and assembly record of the faulty node, perform feature separation on the disassembly and assembly record, and obtain the protocol header feature and payload encoding sequence; An identifier matching matrix is ​​constructed based on the protocol header features and the payload encoding sequence, and the similarity value between the identifier matching matrix and the preset standard protocol feature library is calculated. Based on the similarity value and a preset similarity threshold, abnormal data is extracted from the identifier matching matrix to obtain the private protocol identifier; Based on the private protocol identifier, the faulty node is marked as a node with instruction parsing error.

[0053] It should be noted that the fault node disassembly and reassembly records are automatically and persistently stored when the node processes messages. These records comprehensively preserve all byte logs of the disassembly and reassembly processes during cross-protocol conversion. Each disassembly and reassembly record is stored in a fixed structured format. The record header area sequentially stores three types of auxiliary information: timestamp, port number, and forwarding cache status. The record body area stores two types of message conversion parameters—protocol header features and payload encoding sequence—in a fixed field order. Feature separation is performed according to preset field definition rules. For the located fault node, a dedicated disassembly and reassembly record is extracted according to the time window corresponding to the abnormal data, filtering out message processing logs from irrelevant time periods. The values ​​of the corresponding fields in the record body are directly read, without reading the auxiliary fields in the record header, thus completing the extraction of the two types of key comparison data. In this example, the protocol header feature value 6 and the payload encoding sequence value 8090 are extracted. These two types of features are bound one-to-one to the physical device number and abnormal data index of the fault node, ensuring that subsequent similarity calculation results can be traced back to the original conversion log. Feature separation does not modify the feature values ​​corresponding to the original bytes throughout the process, fully preserving the original identifier information of the private protocol message and preventing feature tampering from causing matching deviations.

[0054] The protocol header features and payload encoding sequences jointly construct a two-dimensional identifier matching matrix. Using the cosine similarity formula, a multi-dimensional comparison with the standard protocol feature library is performed, outputting a quantified similarity value. The standard protocol feature library pre-stores standardized header and payload encoding features of all compatible devices in the park, covering mainstream standardized IoT protocols and adapted vendor proprietary protocols. The extracted header features and payload encoding sequences are used as row vectors in the matrix, and each set of protocol features in the standard library is used as a column vector. These are cross-filled to form the identifier matching matrix, with the matrix dimensions dynamically adapted to the number of protocol features. The spatial overlap between the matrix vectors is calculated using the cosine similarity formula:

[0055] Where A is the row vector of the identifier matching matrix to be matched, containing two dimensions: the extracted protocol header features and the payload encoding sequence; B is the column vector in the standard protocol feature library, corresponding to the header features and payload encoding features of a certain standard protocol. This calculation method uniformly adopts multi-dimensional vector operations, eliminating the logical loophole of directly comparing scalars and vectors. The closer the similarity value is to 1, the higher the matching degree between the current message features and the known standard protocol; the lower the value, the more likely the message contains unrecognized private protocol features.

[0056] It is worth noting that the similarity value is compared with a preset similarity threshold. If the similarity is lower than the threshold, the abnormal field is extracted to obtain the unknown private protocol identifier; if the similarity is higher than the threshold, the node is determined to be able to parse the message normally, and the private identifier extraction process is skipped without marking a parsing failure. The preset similarity threshold is fixed at 0.85, which was determined through experimental statistical calibration. 500 sets of normally parsed samples each of mainstream standardized IoT protocols and adapted vendor private protocols from compatible devices within the park were collected. Cosine similarity was used to calculate the matching score of each sample with the standard protocol feature library. The lowest similarity value under the 95% confidence interval was 0.85. This threshold can control the protocol misidentification rate to within 1%, while ensuring an effective detection rate of over 98% for unidentified protocols. If the similarity of the example is 0.45, which is significantly less than 0.85, it is determined that the protocol header features and payload encoding sequences used by the faulty node when processing messages from disassembled and reassembled records do not belong to any compatible protocol in the database. Therefore, the protocol header features and payload encoding sequences corresponding to the row vectors in the identifier matching matrix are extracted as unidentified private protocol identifiers. If the similarity is greater than or equal to 0.85, it is determined that the node can parse the message normally, and the private identifier extraction process is skipped without marking a parsing failure. The extracted private protocol identifiers are synchronously stored in the abnormal protocol database for future expansion of the standard protocol feature library and continuous optimization of the node's protocol compatibility.

[0057] Finally, based on the extracted unidentified private protocol identifier, the faulty node was qualitatively labeled and identified as a node with instruction parsing errors. Since there was no matching entry for this private protocol identifier in the node's local protocol library, the node's built-in protocol parsing rules lacked the corresponding conversion logic. This resulted in the inability to correctly distinguish between control instructions and business data during message disassembly and reassembly, leading to byte mismatches and data redundancy during cross-protocol conversion, ultimately triggering the message bloat problem detected earlier. The system attached a unique parsing error label to the faulty node and bound it with the private protocol identifier code, similarity value, identifier matching matrix, and disassembly / reassembly record index, packaging it to generate a complete fault root cause dataset. This judgment logic, based on the detection of unidentified private protocol identifiers, can pinpoint the type of protocol parsing anomaly fault, clearly distinguishing it from network congestion and hardware failures. This avoids maintenance personnel confusing the cause of the fault, directly pinpointing compatibility defects based on private protocol identifiers, significantly simplifying the troubleshooting process for cross-protocol faults in smart park IoT networks, and improving overall maintenance efficiency.

[0058] In one implementation, link tracing is performed to obtain cross-protocol fault node logs, including: Obtain the exception stack information and context data of the instruction parsing error node; Based on the exception stack information and the context data, node extraction is performed to obtain path nodes. Based on the path nodes, a global tracking identifier is generated. Messages are captured based on the global tracking identifier and the path node to obtain the message sequence; The message sequence is subjected to feature extraction and recombination to obtain a message feature vector; Based on the message feature vector and the global tracking identifier, a cross-protocol fault node log containing link tracing information is generated.

[0059] It should be noted that the exception stack information and context data are captured from the local cache of the instruction parsing error node. The data collection scope is strictly limited to the time window in which the exception data occurred, and the device's regular operation logs are filtered to reduce redundant data. The exception stack information records the details of the underlying program error when the node parses the private protocol, including underlying error parameters such as the memory out-of-bounds address and the protocol parsing function call chain. In this example, the memory out-of-bounds error address 89012 was extracted. The context data synchronously captures the device port number, millisecond-level timestamp, message receiving buffer status, and other supporting information at the time of the fault. The example port parameter is 8080. Both types of data are bound to the fault node number and the unidentified private protocol identifier for storage, completely restoring the hardware and software operating state at the moment the instruction parsing error occurred. All original data is not trimmed or tampered with, and the original underlying error records are completely preserved, providing complete traceability material for subsequent link path extraction.

[0060] Subsequently, the system traverses the forwarding records within the context data, sequentially extracting path nodes such as gateway nodes and aggregation nodes along the entire message transmission path. For example, it extracts two sets of node identifiers for gateway nodes and aggregation nodes. Then, it integrates the node number, fault timestamp, and private protocol identifier as hash input parameters, and generates a global tracking identifier through SHA-256 hashing. Since the input parameters include three unique factors—node number, fault timestamp, and private protocol identifier—the probability of hash collisions is negligible, ensuring the uniqueness of the global tracking identifier within the park. Any abnormal cross-protocol message link within the park corresponds to only one set of tracking identifiers, eliminating duplicate conflicts. The identifier is synchronously associated with all path node data, enabling a single index to retrieve all node information for the entire transmission link, providing a unified retrieval key for cross-protocol message timing calibration.

[0061] It is worth further explanation that the system uses global tracking identifiers as search criteria to traverse the local packet caches of path nodes and capture all original cross-protocol packets generated during the forwarding and conversion process of each node. Due to minute millisecond-level deviations in the local clocks of each network node within the campus, the PTP protocol is uniformly used to correct the timestamps on each packet, aligning offset packets to the same absolute time base and eliminating timing discrepancies. In the example, packets with a 5-millisecond difference are time-calibrated and reordered according to the order of packet reception to form an ordered, time-aligned packet sequence. The capture process only retrieves packets related to the currently faulty link; data reported by irrelevant devices is directly filtered, reducing the computational load of packet retrieval and calibration and ensuring real-time processing performance in the log generation stage.

[0062] Finally, feature extraction is performed on the message sequence, uniformly capturing three core parameters: source address length, destination address length, and payload type identifier. Discrete values ​​are concatenated in time sequence to form a message feature vector. An example combined vector is [32, 128, 6], corresponding to a source address length of 32 bytes, a destination address length of 128 bytes, and a payload type identifier of 6 bytes, respectively. Subsequently, following a preset log template, the global tracking identifier is used as the log retrieval index. The message feature vector, the physical device number of the instruction parsing error node, the time-series message sequence, the private protocol identifier, and the exception stack data are uniformly encapsulated. The resulting cross-protocol fault node log fully records the entire chain evolution of the message from the source device to the fault node, the root cause of the protocol conversion anomaly, and various quantitative judgment indicators. The log is stored in the park's operation and maintenance database. Operation and maintenance personnel can retrieve all data for the entire fault link with a single click using the global tracking identifier, enabling rapid review of cross-protocol parsing faults and significantly reducing the cost of fault location and handling in the park's IoT network.

[0063] The preset log template is a predefined structured format specification that is defined before log generation. It contains seven fields in the following order: global tracking identifier, physical device number of the instruction parsing error node, message feature vector, time-series message sequence, unidentified private protocol identifier, exception stack data, and log generation timestamp. Specifically, the global tracking identifier is a string, the fault node information is a numeric type, the message feature vector is an array, the time-series message sequence is an array, the unidentified private protocol identifier is a numeric type, the exception stack data is a string, and the log generation timestamp is a numeric type. During log generation, the corresponding data is filled in sequentially according to the template fields to form a standardized cross-protocol fault node log.

[0064] In summary, this invention discloses a cross-protocol operation method for IoT devices in smart parks, comprising: acquiring raw communication data sent by IoT devices; classifying the raw communication data by features to obtain mutually independent control commands and service data; parsing and encoding the control commands and service data to obtain a standard command set and a plaintext data stream; reassembling the standard command set and the plaintext data stream to obtain standard format data; acquiring node forwarding records of the standard format data; performing time-series reconstruction based on the node forwarding records to obtain a message forwarding trajectory; performing load differential operation on adjacent nodes in the message forwarding trajectory to obtain a data volume difference; filtering the standard format data based on the data volume difference to obtain abnormal data; performing anomaly detection on the message forwarding trajectory corresponding to the abnormal data to obtain faulty nodes; acquiring disassembly and reassembly records of the faulty nodes; identifying and filtering the faulty nodes based on the disassembly and reassembly records to obtain command parsing error nodes; and performing link tracing to obtain a cross-protocol faulty node log. This invention accurately locates private protocol parsing faults by decoupling private protocol messages, tracking the entire link trajectory, and identifying abnormal nodes, enabling stable cross-protocol interaction of various IoT devices in smart parks and significantly improving fault diagnosis efficiency.

[0065] The second embodiment of the present invention provides a cross-protocol operating system for IoT devices in smart parks, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the method described above.

[0066] It should be noted that the IoT device cross-protocol operating system for smart parks provided in this embodiment of the invention is used to execute all the process steps of the IoT device cross-protocol operation method for smart parks in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0067] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0068] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A method for cross-protocol operation of IoT devices in a smart park, characterized in that, include: The system acquires raw communication data sent by IoT devices, performs feature classification on the raw communication data, and obtains mutually independent control commands and service data. The control commands and the service data are parsed and encoded to obtain a standard command set and a plaintext data stream. The standard command set and the plaintext data stream are then reassembled to obtain standard format data. Obtain the node forwarding records of the standard format data, and reconstruct the time sequence based on the node forwarding records to obtain the message forwarding trajectory; The payload differential operation is performed on adjacent nodes in the message forwarding trajectory to obtain the data volume difference. The standard format data is then filtered based on the data volume difference to obtain abnormal data. Anomaly detection is performed on the message forwarding trajectory corresponding to the abnormal data to identify the faulty node; Obtain the disassembly and assembly records of the faulty node, identify and filter the faulty node based on the disassembly and assembly records, obtain the instruction parsing error node, and perform link tracing to obtain the cross-protocol faulty node log.

2. The method for cross-protocol operation of IoT devices in smart parks according to claim 1, characterized in that, The step of performing feature classification on the original communication data to obtain mutually independent control commands and service data includes: The original communication data is parsed to obtain the message structure; Extract the field elements of the message structure, construct a feature vector based on the field elements, and perform decision tree matching on the feature vector to obtain the branch path; The labels are classified according to the branch paths to obtain the classification results; Based on the classification results and preset instruction identifiers, data is extracted from the message structure to obtain independent control instructions and business data.

3. The method for cross-protocol operation of IoT devices in smart parks according to claim 2, characterized in that, The process of parsing the original communication data to obtain the message structure includes: Extract the byte sequence of the original communication data, the byte sequence including the message header and the data payload; The message header is matched with a preset private protocol library to obtain the corresponding private protocol; The data payload is structured and mapped according to the private protocol to obtain the message structure.

4. The method for cross-protocol operation of IoT devices in smart parks according to claim 1, characterized in that, The process involves parsing and encoding the control commands and the service data to obtain a standard command set and a plaintext data stream, and then reassembling the standard command set and the plaintext data stream to obtain standard format data, including: Extract the control fields of the control instructions and the data fragments of the business data; The control field and the data fragment are parsed according to a preset protocol dictionary to obtain the instruction type identifier and the payload encoding sequence; The instruction type identifier and the payload encoding sequence are encoded and converted to obtain a standard instruction set and a plaintext data stream; The standard instruction set and the plaintext data stream are recombined to obtain standard format data.

5. The method for cross-protocol operation of IoT devices in smart parks according to claim 1, characterized in that, The node forwarding records for acquiring the standard format data are used to reconstruct the message forwarding trajectory based on the node forwarding records, including: Obtain the node forwarding records of the standard format data, parse the node forwarding records to obtain a set of route identifiers and a timestamp sequence; The route identifier set and the timestamp sequence are time-aligned to obtain the link node access sequence; The spatial distribution matrix is ​​obtained by performing coordinate transformation on the access sequence of the link nodes; Feature extraction is performed on the spatial distribution matrix to obtain the message forwarding trajectory.

6. The method for cross-protocol operation of IoT devices in smart parks according to claim 1, characterized in that, The process involves performing load differential calculations on adjacent nodes in the message forwarding trajectory to obtain data volume differences. Based on these differences, the standard format data is then filtered to identify anomalous data, including: The load is calculated for adjacent nodes in the message forwarding trajectory to obtain a load capacity sequence; Perform a differential operation on the load capacity sequence to obtain a redundant byte vector; The redundant byte vector is stripped of protocol overhead to obtain the data volume difference; Standard format data with a difference in data volume greater than a preset inflation threshold are filtered out to obtain abnormal data.

7. The method for cross-protocol operation of IoT devices in smart parks according to claim 1, characterized in that, The step of performing anomaly detection on the message forwarding trajectory corresponding to the abnormal data to obtain the fault node includes: Extract the message forwarding trajectory of the abnormal data, and extract the trajectory feature vector of each node in the message forwarding trajectory; Calculate the distance from the trajectory feature vector to the hyperplane of the preset classification decision boundary; Based on the hyperplane distance and a preset distance threshold, state assignment is performed on the trajectory feature vector to obtain anomaly state labels; Node mapping is performed based on the abnormal status labels to obtain the faulty nodes.

8. The method for cross-protocol operation of IoT devices in smart parks according to claim 1, characterized in that, The process of obtaining the disassembly and assembly records of the faulty node, identifying and filtering the faulty node based on the disassembly and assembly records, and obtaining instruction parsing error nodes includes: Obtain the disassembly and assembly record of the faulty node, perform feature separation on the disassembly and assembly record, and obtain the protocol header feature and payload encoding sequence; An identifier matching matrix is ​​constructed based on the protocol header features and the payload encoding sequence, and the similarity value between the identifier matching matrix and the preset standard protocol feature library is calculated. Based on the similarity value and a preset similarity threshold, abnormal data is extracted from the identifier matching matrix to obtain the private protocol identifier; Based on the private protocol identifier, the faulty node is marked as a node with instruction parsing error.

9. The method for cross-protocol operation of IoT devices in smart parks according to claim 1, characterized in that, The link tracing process obtains cross-protocol fault node logs, including: Obtain the exception stack information and context data of the instruction parsing error node; Based on the exception stack information and the context data, node extraction is performed to obtain path nodes; Map the path nodes to generate a global tracking identifier; Messages are captured based on the global tracking identifier and the path node to obtain the message sequence; The message sequence is subjected to feature extraction and recombination to obtain a message feature vector; Based on the message feature vector and the global tracking identifier, a cross-protocol fault node log containing link tracing information is generated.

10. A cross-protocol operating system for IoT devices in smart parks, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method according to any one of claims 1 to 9.

Images