Iot device access method and apparatus, electronic device, and storage medium

Abstract

This application relates to the field of Internet of Things (IoT) technology and discloses a method, apparatus, electronic device, and storage medium for IoT device access. The method includes: extracting message features corresponding to message data reported by the device to be accessed; calculating the confidence level between the message features and protocol fingerprints in a protocol fingerprint database; the protocol fingerprint database includes protocol fingerprints corresponding to multiple communication protocols, with each communication protocol corresponding to one protocol fingerprint; determining whether the maximum confidence level is greater than a preset threshold; if the maximum confidence level is greater than the preset threshold, accessing the device to be accessed based on the communication protocol corresponding to the maximum confidence level; if the maximum confidence level is less than or equal to the preset threshold, creating a corresponding parser instance based on the message features, and accessing the device to be accessed based on the parser instance. This application can improve the flexibility and efficiency of device access.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, specifically to IoT device access methods, devices, electronic devices, and storage media. Background Technology

[0002] With the development of IoT technology, IoT devices are widely connected to cloud platforms. These devices use a wide variety of communication protocols, and new protocols are constantly emerging. Currently, engineers need to manually write parsing scripts, configure templates, and restart services to connect to new protocols. This process is inefficient, affects business continuity, is prone to errors, and has high maintenance costs. Summary of the Invention

[0003] This application provides an IoT device access method, apparatus, electronic device, and storage medium to solve the problems of low access efficiency, impact on business continuity, and high maintenance costs caused by engineers manually writing parsing scripts, configuring templates, and restarting services to access new protocols.

[0004] In a first aspect, this application provides a method for IoT device access, the method comprising:

[0005] Extract message features corresponding to the message data reported by the device to be connected; calculate the confidence level between the message features and the protocol fingerprints in the protocol fingerprint database; the protocol fingerprint database includes protocol fingerprints corresponding to multiple communication protocols, with each communication protocol corresponding to one protocol fingerprint; determine whether the maximum confidence level in the confidence level is greater than a preset threshold; if the maximum confidence level is greater than the preset threshold, then connect the device to be connected according to the communication protocol corresponding to the maximum confidence level; if the maximum confidence level is less than or equal to the preset threshold, then create a corresponding parser instance based on the message features, and connect the device to be connected based on the parser instance.

[0006] This embodiment breaks away from the traditional IoT device access reliance on predefined protocol libraries by employing a layered processing logic that first extracts message features, then performs confidence matching, and finally accesses devices based on different scenarios. Traditional methods require manually writing parsing scripts and restarting services to support new protocols. In contrast, this embodiment uses automated feature extraction and confidence calculation to directly match and access known communication protocols, and dynamically creates parser instances for unknown protocols, completing device access without manual intervention. Message feature extraction provides the core basis for protocol identification, confidence calculation ensures the accuracy of protocol identification through multi-dimensional matching, and the scenario-based access logic enables rapid adaptation to known communication protocols and dynamic compatibility with unknown communication protocols. This fundamentally solves the pain points of poor scalability and high manual costs of traditional methods, significantly improving the flexibility and efficiency of heterogeneous device access.

[0007] In one optional implementation, calculating the confidence level between message features and protocol fingerprints in the protocol fingerprint database includes: determining the corresponding message feature vector based on the message features; determining the corresponding protocol fingerprint vector and feature weights based on the protocol fingerprints; calculating the similarity between the message features and the protocol fingerprints using multiple similarity calculation methods, based on the message feature vector, protocol fingerprint vector, and feature weights, to obtain the similarity corresponding to each similarity calculation method; and determining the confidence level based on the similarity corresponding to each similarity calculation method.

[0008] This embodiment significantly improves the accuracy and reliability of confidence calculation by transforming message features and protocol fingerprints into vector form and employing multi-dimensional similarity calculation combined with feature weights. First, by converting abstract message features and protocol fingerprints into numerical vectors, quantifiable comparison of features is achieved, avoiding the one-sidedness of judging based on a single feature. Second, feature weights are introduced to reflect the differences in importance of different protocol features (e.g., the fixed header feature has a higher weight than the variable data field feature), making the matching process more aligned with the essence of the protocol. Finally, multiple similarity calculation methods are processed in parallel to comprehensively verify the rationality of the matching, ensuring that the confidence result truly reflects the degree of protocol matching and providing a reliable basis for subsequent access decisions.

[0009] In one optional implementation, the confidence level is determined based on the similarity corresponding to each similarity calculation method, including:

[0010] Obtain the weight corresponding to each similarity calculation method; calculate the sum of the products of the similarity and the corresponding weight for each similarity calculation method to obtain the confidence score.

[0011] This embodiment achieves comprehensive optimization of matching results by calculating confidence scores through weighted summation of multiple similarity results, making protocol identification more adaptable and flexible. Different similarity calculation methods have different applicable scenarios, and a single similarity result cannot fully adapt to all protocol types. By configuring adjustable weights for each similarity calculation method, the influence weights of each dimension can be dynamically adjusted according to protocol characteristics. This allows confidence score calculation to be specifically adapted to the core features of different protocols, avoiding misjudgments caused by biases in a single dimension, and further improving the accuracy of protocol identification.

[0012] In one optional implementation, creating a corresponding parser instance based on message characteristics includes:

[0013] Analyze the message format of the message data to obtain the parsing rule description file; create the corresponding parser instance based on the parsing rule description file.

[0014] This embodiment automates the process of analyzing message format to obtain a parsing rule description file and creating corresponding parser instances based on it. This achieves code-free adaptation for unknown protocols, eliminating the reliance on manually written parsing scripts found in traditional methods. The parsing rule description file is the core basis for the parser's operation; its essence is to transform the protocol structure into standardized rules that can be recognized by machines. This embodiment generates the parsing rule description file automatically by analyzing message format, eliminating the need for manual coding by engineers. This avoids the tedious operation and error risks of manual reverse analysis and significantly shortens the adaptation cycle for unknown protocols. Furthermore, the standardized parsing rule description file has good readability and compatibility, providing a unified interface for subsequent dynamic loading of parsers and rule updates, ensuring the standardization and efficiency of parser instance creation.

[0015] In one optional implementation, analyzing the message format of the message data to obtain a parsing rule description file includes: analyzing the message data to obtain an initial message structure; the initial message structure includes fixed fields and their location information, variable fields and their location information; determining key parameters of key fields in the variable fields based on the initial message structure, the key fields including a length field, a data field, and a checksum field, and the key parameters including offset, length, and encoding method; determining field attributes corresponding to each field in the data field based on the key parameters of the key fields, the field attributes including data type, encoding method, meaning, and offset; and determining the parsing rule description file based on the initial message structure, the key parameters of the key fields, and the field attributes corresponding to each field in the data field.

[0016] This embodiment achieves precise decomposition of unknown protocol message formats through a hierarchical parsing logic that infers the initial structure, locates key fields, and determines field attributes. This provides comprehensive and accurate foundational data for generating the parsing rule description file. By aligning and comparing multiple message samples, it distinguishes between fixed and variable fields, clarifies the basic framework of the protocol, and avoids confusion between core structures and redundant data during parsing. It accurately locates key fields such as the length field and checksum field and extracts key parameters, solving parsing failures caused by variable protocol message lengths and unknown checksum logic. It deeply analyzes the attributes of each field in the data fields, clarifying details such as data types and encoding methods, ensuring that subsequent data parsing can accurately reconstruct the original business data. The hierarchical parsing logic comprehensively covers the core elements of the protocol structure, ensuring the completeness and accuracy of the generated parsing rule description file, and guaranteeing the efficient operation of the parser instance.

[0017] In one optional implementation, creating a corresponding parser instance based on the parsing rule description file includes: storing the parsing rule description file in a parsing rule base and generating a rule update event; upon detecting a rule update event, retrieving the parsing rule description file from the parsing rule base and creating a corresponding parser instance based on the parsing rule description file; storing the parser instance in a parser cache pool and updating the parser mapping table corresponding to the parser cache pool; the parser mapping table includes a unique identifier of the communication protocol and the parser instance stored in a correspondence relationship.

[0018] This embodiment achieves seamless deployment of parser instances, completely resolving the availability interruption issue caused by service restarts required for protocol updates in traditional methods. First, parsing rule description files are stored in a parsing rule base, enabling centralized management and reuse of rules. Second, rule update events trigger the parser factory to actively pull rules, ensuring new rules are detected promptly. Third, parser instances are dynamically created in memory, eliminating the need for compilation, deployment, and service restarts, thus avoiding device connection drops or data loss due to service interruptions. Finally, the parser mapping table is updated. The entire process ensures the rapid implementation of new protocol parsing capabilities.

[0019] In an optional implementation, the method further includes: when a rule update event is detected, determining the corresponding protocol fingerprint based on the message data reported by the device to be accessed, and storing the protocol fingerprint in a protocol fingerprint database.

[0020] This embodiment achieves self-learning and iterative optimization of protocol recognition capabilities by updating the protocol fingerprint database upon detecting a rule update event. When connecting similar devices subsequently, the communication protocol can be quickly identified directly through confidence matching, eliminating the need for repeated message format analysis and rule generation, thus achieving one-time adaptation and permanent reuse. Simultaneously, the dynamic expansion of the protocol fingerprint database continuously increases the supported protocol types, gradually improving the adaptation coverage of heterogeneous devices and reducing long-term operation and maintenance costs.

[0021] Secondly, this application provides an Internet of Things (IoT) device access device, comprising:

[0022] The first processing module is used to extract the message features corresponding to the message data reported by the device to be connected;

[0023] The second processing module is used to calculate the confidence level between the message features and the protocol fingerprints in the protocol fingerprint database; the protocol fingerprint database includes protocol fingerprints corresponding to multiple communication protocols, with each communication protocol corresponding to one protocol fingerprint.

[0024] The third processing module is used to determine whether the maximum confidence level in the confidence level is greater than a preset threshold.

[0025] The fourth processing module is used to connect to the device to be connected according to the communication protocol corresponding to the maximum confidence level if the maximum confidence level is greater than a preset threshold.

[0026] The fifth processing module is used to create a corresponding parser instance based on the message characteristics if the maximum confidence level is less than or equal to a preset threshold, and then access the device to be accessed based on the parser instance.

[0027] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the Internet of Things device access method of the first aspect or any corresponding embodiment described above.

[0028] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute the IoT device access method described in the first aspect or any corresponding embodiment. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0030] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this application;

[0031] Figure 2 This is a schematic diagram of the specific structure of the Internet of Things (IoT) device access system according to an embodiment of this application;

[0032] Figure 3 This is a schematic diagram of the workflow of an IoT device access system according to an embodiment of this application;

[0033] Figure 4 This is a flowchart of an IoT device access method according to an embodiment of this application;

[0034] Figure 5 This is a schematic diagram illustrating the confidence level calculation process according to an embodiment of this application;

[0035] Figure 6 This is a schematic diagram illustrating the process of obtaining the parsing rule description file according to an embodiment of this application;

[0036] Figure 7 This is a schematic diagram of the protocol hot-loading process according to an embodiment of this application;

[0037] Figure 8 This is a structural block diagram of an IoT device access device according to an embodiment of this application;

[0038] Figure 9 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0041] As one optional application scenario in the embodiments of this application, such as Figure 1 As shown, the IoT device access system may include at least one terminal device and at least one server. Figure 1 The system is illustrated in the example, which includes a computer 101, a mobile terminal 102, and a server 103, and the terminal devices such as the computer 101 and the mobile terminal 102 are connected to the server 103 through a network 110.

[0042] Specifically, the terminal device can be a smartphone, tablet, laptop, PDA, desktop computer, game console, smart TV, smart wearable device, in-vehicle terminal, VR (Virtual Reality) device, AR (Augmented Reality) device, etc. Server 103 can be a standalone physical server, a server cluster, a distributed system, or a cloud server providing cloud services. Network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, corporate intranet, local area network, wide area network, mobile communication network, and combinations thereof.

[0043] As an example, the specific structure of the IoT device access system is as follows: Figure 2 As shown, the IoT device access system consists of: a device connection layer, a data protocol identification engine, a data parsing layer, an AI modeling engine, a device knowledge base, and an AIoT data platform layer.

[0044] The device connection layer is responsible for network communication with the devices to be connected, achieving decoupling from the communication protocol. The protocol adapter of the device connection layer is a set of stateless, horizontally scalable microservices used to interface with different network protocols. All adapters encapsulate the raw message data reported by the devices to be connected into an internal standard message format and send it to a unified data bus.

[0045] The data protocol identification engine is responsible for receiving standard message format data from the data bus, performing standardization processes such as redundancy removal and data cleaning, extracting message features (including key message data such as device metadata and protocol IDs) and sending them to the AI ​​modeling engine. It receives the confidence scores and protocol ID sets corresponding to known protocols returned by the AI ​​modeling engine, and makes access decisions based on the comparison results of the maximum confidence score and the preset threshold.

[0046] The AI ​​modeling engine receives message features output from the data protocol recognition engine, transforms them into message feature vectors, and matches them with the corresponding protocol fingerprint vectors and feature weights stored in the device knowledge base's protocol fingerprint database. It calculates similarity using various similarity calculation methods and combines the corresponding weights to obtain a confidence score, generating a set of existing protocol matching confidence scores and protocol IDs, which is then fed back to the data protocol recognition engine. Simultaneously, it supports unsupervised learning of unknown protocol features to construct device behavior profiles.

[0047] The device knowledge base stores the results output by the AI ​​modeling engine and is functionally divided into a protocol fingerprint library and a parsing rule library. The protocol fingerprint library stores protocol fingerprints (feature templates containing feature vectors, weights, and other information) corresponding to multiple communication protocols, with one protocol fingerprint for each communication protocol. The parsing rule library stores protocol parsing rule description files, providing a basis for the creation of parser instances.

[0048] The data parsing layer is responsible for executing corresponding operations based on the data protocol identification engine's decision: If the protocol is known (maximum confidence greater than a preset threshold), it directly calls the corresponding parser instance in the parser cache pool. If the protocol is unknown (maximum confidence less than or equal to a preset threshold), it analyzes the message format of the packet data through a dynamic rule generator, generates a parsing rule description file, stores it in the parsing rule library, and triggers a rule update event. After detecting the rule update event, the parser factory retrieves the parsing rule description file from the parsing rule library, dynamically creates the corresponding parser instance through hot-loading technology, stores it in the parser cache pool, and updates the parser mapping table (containing the unique identifier of the communication protocol and the correspondence between the parser instance and the parser instance) corresponding to the parser cache pool. Finally, it completes the standardized parsing of the original packet data through the parser instance and outputs standardized data.

[0049] The AIoT data platform layer is responsible for receiving and storing all standardized data, providing data support for upper-layer applications (data analysis, AI training, visualization, etc.). Simultaneously, upon detecting a rule update event, it triggers a protocol fingerprint update process, determining the corresponding protocol fingerprint based on the message data reported by the device to be connected, and storing it in the protocol fingerprint database to achieve dynamic expansion of the database.

[0050] Figure 3 This is a schematic diagram of the workflow of an IoT device access system according to an embodiment of this application. The workflow of the IoT device access system is as follows: Figure 3 As shown, the first step is device connection and data preprocessing: the raw message data reported by the device to be connected is uniformly encapsulated into an internal standard message format by the protocol adapter of the device connection layer and then sent to the data bus. The data protocol recognition engine receives the standard message format data from the data bus, performs standardization processing such as redundancy removal and data cleaning to obtain a clean message payload, extracts message features (including key message data such as device metadata and protocol ID) and sends them to the AI ​​modeling engine.

[0051] Step 2: Protocol Feature Matching and Confidence Calculation: The AI ​​modeling engine receives the message features output by the data protocol recognition engine and transforms them into message feature vectors. Simultaneously, it pre-filters existing protocols in the protocol fingerprint database of the device knowledge base based on the current device message, quickly eliminating a large number of mismatched protocols using the most significant and computationally cost-efficient features. Then, it calls the protocol fingerprint vectors and feature weights corresponding to the remaining protocols to be matched in the protocol fingerprint database, calculating the similarity between the message feature vector and each protocol fingerprint vector using various similarity calculation methods. Combining the weights corresponding to each similarity calculation method, it calculates the confidence score for each protocol. Finally, it feeds back the confidence score calculation results of all existing protocols and the corresponding protocol ID set to the data protocol recognition engine.

[0052] Step 3: Access Decision and Rule Determination: The data protocol recognition engine compares the maximum confidence score in the set of confidence scores of all existing protocols with a preset threshold. If the maximum confidence score is greater than the preset threshold, the protocol template corresponding to that confidence score is considered a successful match (i.e., identified as a known protocol). If the maximum confidence score is less than or equal to the preset threshold, the protocol match is considered a failure (i.e., identified as an unknown protocol).

[0053] Step 4: Data Parsing and Parser Management

[0054] Known Protocol Parsing: If the data protocol identification engine determines that a known protocol is matched, it immediately queries the parser mapping table corresponding to the parser cache pool, retrieves the parser instance corresponding to the protocol ID from memory, and uses the parser instance to parse the original message data into structured JSON data.

[0055] Unknown Protocol Parsing: If protocol matching fails, a dynamic rule generator is activated. This generator analyzes the message format of the data (including deriving the initial message structure, locating key fields and parameters in variable fields, and parsing the attributes of each field in the data fields), generates a parsing rule description file (YAML format), and stores it in the parsing rule library, triggering a rule update event. Upon detecting this event, the parser factory actively retrieves the newly generated parsing rule description file from the parsing rule library, instantiates the corresponding new parser object using hot-loading technology, stores the unique identifier of the protocol and the mapping between the new parser instance in the parser mapping table, and synchronously updates the parser cache pool. Subsequently, message data reported by the same type of device to be connected will be directly routed by the data protocol identification engine to this newly created parser instance, completing the parsing of the raw message data into structured JSON data.

[0056] Protocol fingerprint database update: When a rule update event is detected, the protocol fingerprint update process is triggered synchronously. The corresponding protocol fingerprint is determined based on the message data reported by the device to be accessed, and it is stored in the protocol fingerprint database to realize the dynamic expansion of the protocol fingerprint database.

[0057] Step 5: Data Aggregation: All parsed structured JSON data is sent to the AIoT data platform layer, where it is uniformly received and stored, providing standardized data support for upper-layer applications (data analysis, AI training, visualization, etc.).

[0058] According to an embodiment of this application, an embodiment of an IoT device access method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0059] This embodiment provides a method for accessing IoT devices, which can be used in the aforementioned mobile terminals, such as mobile phones and tablets. Figure 4 This is a flowchart of an IoT device access method according to an embodiment of this application, such as... Figure 4 As shown, the process includes the following steps:

[0060] Step S201: Extract the message features corresponding to the message data reported by the device to be accessed.

[0061] In this embodiment of the application, extracting the message features corresponding to the message data reported by the device to be accessed specifically includes: S2011: Obtaining the message data reported by the device to be accessed: receiving the original message data reported by the device to be accessed through the network. The original message data may be in the format of binary stream, etc., and covers the complete data content in the device communication process.

[0062] S2012: Standardize the message data reported by the access device: Perform standardization processing such as redundancy removal and data cleaning on the message data to remove invalid interference data (such as redundant bytes generated during transmission and data with disordered format) and obtain standard message data with uniform format and clean data.

[0063] S2013: Extract key message data from standard message data: Filter out key message data with identification value from standard message data, including but not limited to device metadata, protocol identification fields, data length identifiers, core instruction codes, and other content that can reflect the essential characteristics of the protocol.

[0064] S2014: Determine message features based on key message data: Extract features based on key message data to obtain message features. Message features are a set of core attributes that can uniquely characterize the corresponding communication protocol, and may include fixed field features (such as fixed byte sequences in the protocol frame header and trailer), field structure features (such as field arrangement order and nesting relationships), data type features (such as the distribution patterns of numeric and character fields), etc.

[0065] Step S202: Calculate the confidence level between the message features and the protocol fingerprints in the protocol fingerprint database.

[0066] In this embodiment, the protocol fingerprint database includes protocol fingerprints corresponding to multiple communication protocols, with each communication protocol corresponding to one protocol fingerprint. A protocol fingerprint refers to a feature template that has been structured and encapsulated to represent the core features of a communication protocol. It is the core basis for protocol matching and may include the protocol's corresponding feature vector (a numerical vector quantized from the protocol features), feature weights (coefficients representing the importance of different features in protocol identification, such as fixed frame header features having higher weights than variable data field features), and a unique protocol identifier.

[0067] Step S203: Determine whether the maximum confidence level in the confidence level is greater than the preset threshold.

[0068] In this embodiment of the application, by traversing all the confidence scores corresponding to the protocol fingerprints, the highest confidence score is selected and compared with a preset threshold to determine whether the communication protocol corresponding to the device to be accessed is a known protocol in the protocol fingerprint database.

[0069] Step S204: If the maximum confidence level is greater than the preset threshold, then the device to be accessed is connected according to the communication protocol corresponding to the maximum confidence level.

[0070] In this embodiment, the preset threshold can be set and modified according to actual needs. The preset threshold is a critical value used to distinguish whether a protocol match is successful or not. Its core function is to filter out communication protocols with sufficiently high matching degrees, avoiding parsing errors caused by low matching degrees. The preset threshold can be flexibly set and modified according to the accuracy requirements of the actual application scenario. For example, in industrial IoT scenarios with high requirements for protocol recognition accuracy, the threshold can be set to 0.85. In scenarios where adaptability is prioritized, the threshold can be appropriately reduced to 0.7 to improve the device access success rate.

[0071] In this embodiment, accessing the device to be accessed based on the communication protocol corresponding to the maximum confidence level specifically includes: if the maximum confidence level is greater than a preset threshold, the communication protocol corresponding to the maximum confidence level is determined as the target protocol of the device to be accessed, and the unique identifier of the target protocol is obtained. The parser mapping table corresponding to the parser cache pool (this mapping table stores the correspondence between the unique identifier of the communication protocol and the parser instance) is queried. Based on the unique identifier of the target protocol, the corresponding parser instance is directly retrieved from the parser cache pool (the parser instance has been pre-created and cached according to the protocol parsing rules, and does not need to be generated repeatedly). The retrieved parser instance parses the standardized message data, transforming the original message data into structured data (such as JSON format data) that can be recognized by the upper-layer application. Simultaneously, a stable communication connection is established between the device to be accessed and the IoT platform, and the parsed structured data is transmitted to the AIoT data platform layer, completing the device access process.

[0072] Step S205: If the maximum confidence level is less than or equal to the preset threshold, then create a corresponding parser instance based on the message characteristics, and access the device to be accessed based on the parser instance.

[0073] In this embodiment of the application, creating a corresponding parser instance based on message characteristics and accessing the device to be accessed based on the parser instance specifically includes:

[0074] The dynamic rule generator is activated to perform in-depth analysis of the message format of the message data. First, the initial message structure is obtained, identifying fixed fields, variable fields, and their location information. Second, key fields within the variable fields, such as the length field, data field, and checksum field, are located, and key parameters such as offset, length, and encoding method are extracted. Then, based on the key parameters, the data type, encoding method, meaning, offset, and other field attributes of each field in the data field are determined. Finally, the initial message structure, key field parameters, and field attributes are integrated to generate a standardized parsing rule description file (such as a YAML format file).

[0075] The parsing rule description file is stored in the parsing rule base, triggering a rule update event. Upon detecting this event, the parser factory retrieves the parsing rule description file from the parsing rule base and dynamically creates the corresponding parser instance using hot-loading technology, completing instantiation without restarting the service. Subsequently, the parser instance is stored in the parser cache pool, and the parser mapping table is updated to establish a mapping between the new protocol's unique identifier and the parser instance.

[0076] Simultaneously, based on the message data and parsing rule description file of the device to be connected, the core features of the new protocol are extracted, encapsulated into a standard protocol fingerprint, and stored in the protocol fingerprint library to realize the dynamic expansion of the protocol fingerprint library so that subsequent similar devices can be quickly connected.

[0077] The newly created parser instance parses the message data, transforming it into structured data. A communication connection is established between the device to be connected and the IoT platform, and the structured data is uploaded to the AIoT data platform layer, completing the connection for devices with unknown protocols. When similar devices subsequently report data, the newly stored protocol fingerprint can be directly matched through protocol identification, allowing for rapid connection by calling the corresponding parser instance.

[0078] This embodiment breaks away from the traditional IoT device access reliance on predefined protocol libraries by employing a layered processing logic that first extracts message features, then performs confidence matching, and finally accesses devices based on different scenarios. Traditional methods require manually writing parsing scripts and restarting services to support new protocols. In contrast, this embodiment uses automated feature extraction and confidence calculation to directly match and access known communication protocols, and dynamically creates parser instances for unknown protocols, completing device access without manual intervention. Message feature extraction provides the core basis for protocol identification, confidence calculation ensures the accuracy of protocol identification through multi-dimensional matching, and the scenario-based access logic enables rapid adaptation to known communication protocols and dynamic compatibility with unknown communication protocols. This fundamentally solves the pain points of poor scalability and high manual costs of traditional methods, significantly improving the flexibility and efficiency of heterogeneous device access.

[0079] In an optional implementation, step S202 calculates the confidence level between the message features and the protocol fingerprints in the protocol fingerprint database, including:

[0080] Step S2021: Determine the corresponding message feature vector based on the message characteristics.

[0081] In this embodiment, message features are a set of core attributes extracted from standardized message data reported by the device to be accessed. Message features may include multiple feature items with protocol identification value, such as port information, fixed header bytes, length field values, and checksum data. The message feature vector is a standardized vector obtained after numerically converting these unstructured message features, used to achieve quantifiable comparison of features. Specifically, for each extracted message feature, it is converted into its corresponding numerical form according to a preset quantization rule, ultimately forming a numerical vector of dimension N, denoted as V=(v_1, v_2, v_3, ..., v_n), where v_1 to v_n correspond to the numerical results of the N message features, respectively. For example, the fixed header byte 0xA0 is converted to the decimal value 160, and the port number 8080 is directly retained in its original value.

[0082] Step S2022: Determine the corresponding protocol fingerprint vector and feature weights based on the protocol fingerprint.

[0083] In this embodiment, each protocol fingerprint stored in the protocol fingerprint library is a structured encapsulation of the core features of the corresponding communication protocol, and its data structure is represented as P={W, F}. Here, F=(f_1, f_2, f_3, ..., f_n) is the protocol fingerprint vector, corresponding to the expected value of each feature item in the protocol fingerprint, i.e., the value that each feature should have in a standard scenario, such as the standard byte value of the Modbus protocol fixed header, the default communication port value, etc. Its dimension is consistent with the message feature vector V to ensure that the two can be matched and calculated. W=(w_1, w_2, w_3, ..., w_n) is the feature weight corresponding to the protocol fingerprint vector, used to characterize the importance of each feature item in the protocol identification process. For example, the protocol fixed header feature has a stronger decisive role in protocol identification, and its weight coefficient can be set to 0.5, while the weight coefficient of some non-core variable features can be set to 0.1. The value range of the weight coefficient is [0, 1], and the sum of all feature weights can be flexibly configured according to actual needs (not necessarily forced to be 1).

[0084] To improve matching efficiency, before executing step S2022, the protocols in the protocol fingerprint database can be pre-filtered to select a subset of protocol fingerprints that match the most significant and computationally cost-efficient features in the message features (such as communication port, core magic number, etc.). The subsequent protocol fingerprint vector and feature weight extraction operations are only performed on this subset, thereby quickly eliminating a large number of obviously mismatched protocols and reducing computational overhead.

[0085] Step S2023: Through multiple similarity calculation methods, the similarity between message features and protocol fingerprints is calculated based on message feature vector, protocol fingerprint vector and feature weight, respectively, to obtain the similarity corresponding to each similarity calculation method.

[0086] In the embodiments of this application, the various similarity calculation methods used can be set and modified according to actual needs. As an example, the various similarity calculation methods may include: weighted cosine similarity, Jaccard similarity, and rule matching degree. Taking the various similarity calculation methods including weighted cosine similarity, Jaccard similarity, and rule matching degree as examples, the confidence calculation process is as follows: Figure 5 As shown.

[0087] As an example, weighted cosine similarity calculation: This method measures the directional consistency between the message feature vector and the protocol fingerprint vector, primarily suitable for matching scenarios with numerical features. The calculation formula is: CosineSimilarity=(Σ(v_i*f_i*w_i)) / (sqrt(Σ(v_i²))*sqrt(Σ(f_i²))) where v_i is the value of the i-th message feature vector, f_i is the expected value of the i-th protocol fingerprint vector, and w_i is the feature weight corresponding to the i-th protocol fingerprint vector. The calculation result ranges from [-1, 1]. In practical applications, negative values ​​are discarded and directly mapped to [0, 1]. The closer the value is to 1, the higher the directional consistency and the better the matching degree. Example: If the message feature vector is V=(2,4,1), the protocol fingerprint vector is F=(3,1,2), and the feature weight is W=(0.5,0.3,0.2), then the weighted cosine similarity is approximately 4.6÷17.146≈0.2682.

[0088] As an example, Jaccard similarity calculation: This method is used to handle matching of set features, primarily adapting to features with explicit existence and positional attributes, such as fixed bytes and their offset positions. The calculation formula is: JaccardSimilarity = |A∩B| / |A∪B|. Where set A is the set of fixed bytes and their offset positions found in the current message data, for example, {(0, 0xA0), (5, 0x3F)}, and set B is the set of fixed bytes and their offset positions that must exist as defined in the protocol fingerprint, for example, {(0, 0xA0), (7, 0x1F)}. The calculation result ranges from [0, 1], with the numerator being the number of elements in the intersection of the two sets and the denominator being the number of elements in the union of the two sets. The closer the value is to 1, the higher the overlap between the sets and the more accurate the feature matching. Example: Given set A = {(0, 0xA0), (5, 0x3F)} and set B = {(0, 0xA0), (7, 0x1F)}, the intersection A∩B = {(0, 0xA0)} (1 element) and the union A∪B = {(0, 0xA0), (5, 0x3F), (7, 0x1F)} (3 elements). The Jaccard similarity is 1÷3≈0.33.

[0089] As an example, rule matching degree calculation: This method is used to handle Boolean feature matching, performing binary judgments on rigid features with explicit judgment criteria in the protocol (such as checksum verification, interactive state machine specifications, etc.). Specifically, the message features are verified according to the rules defined in the protocol fingerprint: if the rules are fully met, the rule matching degree is 1; otherwise, it is 0. Example 1 (Checksum Verification): The checksum of the message data is calculated using the CRC16 algorithm specified by the protocol fingerprint. If the calculated result matches the value of the checksum field in the message, the rule matching degree is 1; otherwise, it is 0. Example 2 (Interactive State Machine): If the protocol requires the device to complete authentication before sending service data, and the current device's communication process conforms to this requirement, the rule matching degree is 1; otherwise, it is 0.

[0090] After calculating using the three methods described above, we can obtain the similarity (S_{cosine}) corresponding to the weighted cosine similarity calculation method, the similarity (S_{jaccard}) corresponding to the Jaccard similarity calculation method, and the similarity (S_{rule}) corresponding to the rule matching degree calculation method.

[0091] Step S2024: Determine the confidence level based on the similarity corresponding to each similarity calculation method.

[0092] In this embodiment, due to differences in the feature types and identification focuses of different communication protocols (for example, structurally rigorous industrial protocols rely more on set features and rigid rules, while more flexible custom protocols rely more on numerical features), a single similarity result cannot fully reflect the true degree of protocol matching. Therefore, it is necessary to weight and fuse the similarities corresponding to multiple similarity calculation methods to obtain the final confidence score. This embodiment significantly improves the accuracy and reliability of confidence score calculation by converting message features and protocol fingerprints into vector form and combining feature weights with multi-dimensional similarity calculation. First, the abstract message features and protocol fingerprints are converted into numerical vectors, enabling quantifiable comparison of features and avoiding the one-sidedness of single feature judgment. Second, feature weights are introduced to reflect the differences in the importance of different protocol features (e.g., the fixed header feature has a higher weight than the variable data field feature), making the matching process more in line with the essence of the protocol. Finally, multiple similarity calculation methods are processed in parallel to comprehensively verify the rationality of the matching, ensuring that the confidence score result can truly reflect the degree of protocol matching and provide a reliable basis for subsequent access decisions.

[0093] In an optional implementation, step S2024, determining the confidence level based on the similarity corresponding to each similarity calculation method, includes:

[0094] Obtain the weight corresponding to each similarity calculation method. Calculate the sum of the products of the similarity and the corresponding weight for each similarity calculation method to obtain the confidence score.

[0095] In this embodiment, preset weights (denoted as α, β, and γ, respectively, with values ​​ranging from [0, 1] and α + β + γ = 1) corresponding to each similarity calculation method are obtained. The weights corresponding to each similarity calculation method can be dynamically adjusted according to the protocol type (for example, for protocols with a rigorous structure such as Modbus, α = 0.2, β = 0.4, and γ = 0.4 can be set; for custom protocols, α = 0.6, β = 0.2, and γ = 0.2 can be set). Then, the sum of the products of the similarity and the corresponding weight for each similarity calculation method is calculated to obtain the confidence score. The confidence score ranges from [0, 1], and a higher value indicates a higher degree of matching between the message features and the corresponding protocol fingerprint, and a stronger reliability of protocol identification. This embodiment achieves comprehensive optimization of the matching results by weighted summation of multiple similarity results, making protocol identification more adaptable and flexible. Different similarity calculation methods have different applicable scenarios, and a single similarity result is difficult to fully adapt to all protocol types. By configuring adjustable weights for each similarity calculation method, the influence weights of each dimension can be dynamically adjusted according to the characteristics of the protocol, enabling the confidence calculation to be specifically adapted to the core features of different protocols, avoiding misjudgments caused by single-dimensional bias, and further improving the accuracy of protocol identification.

[0096] In an optional implementation, step 205, creating a corresponding parser instance based on message characteristics, includes:

[0097] Step 2051: Analyze the message format of the message data to obtain the parsing rule description file.

[0098] Step 2052: Create a corresponding parser instance based on the parsing rule description file.

[0099] This embodiment automates the process of analyzing message format to obtain a parsing rule description file and creating corresponding parser instances based on it. This achieves code-free adaptation for unknown protocols, eliminating the reliance on manually written parsing scripts found in traditional methods. The parsing rule description file is the core basis for the parser's operation; its essence is to transform the protocol structure into standardized rules that can be recognized by machines. This embodiment generates the parsing rule description file automatically by analyzing message format, eliminating the need for manual coding by engineers. This avoids the tedious operation and error risks of manual reverse analysis and significantly shortens the adaptation cycle for unknown protocols. Furthermore, the standardized parsing rule description file has good readability and compatibility, providing a unified interface for subsequent dynamic loading of parsers and rule updates, ensuring the standardization and efficiency of parser instance creation.

[0100] In one optional implementation, step 2051 analyzes the message format of the message data to obtain a parsing rule description file, including:

[0101] Step a1: Analyze the message data to obtain the initial message structure. In this embodiment, the initial message structure includes fixed fields and their location information, and variable fields and their location information.

[0102] In this embodiment of the application, the core of step a1 is protocol structure inference. A sample set is constructed by analyzing multiple sets of message samples from the same unknown protocol to achieve a preliminary decomposition of the message structure. For example... Figure 6 As shown, specifically, firstly, multiple packet samples of the same type of unknown protocol reported by the device to be accessed are collected. All samples are then aligned byte-wise and compared byte-by-byte to identify the patterns of byte value changes. If the byte value at a certain offset remains unchanged across all samples, this part is determined to be a fixed field (usually corresponding to core identification information such as protocol frame headers and instruction codes), and its start and end offsets are recorded. If the byte value at a certain offset differs across different samples, this part is determined to be a variable field (potentially corresponding to dynamically changing information such as length fields, address fields, data payloads, or checksums), and its location range is recorded. Finally, a preliminary packet structure diagram is output, clearly identifying the specific locations and ranges of fixed and variable fields, providing a foundation for subsequent key field localization.

[0103] Step a2: Determine the key parameters of the key fields in the variable field based on the initial message structure.

[0104] In this embodiment, the key fields include a length field, a data field, and a checksum field, and the key parameters include: offset, length, and encoding method. In this embodiment, step a2 precisely locates the length field and checksum field for the variable fields in the initial message structure through hypothesis testing, and extracts the key parameters, as follows:

[0105] The process involves locating the length field and determining its key parameters. It then iterates through each field in the variable field, assuming a particular field is the length field. Based on the value of this field, it predicts the total message length or data payload length. The validity of this assumption is then verified using all message samples (e.g., if a field value is 10 and the corresponding data payload length in all samples is 10 bytes, then the assumption is valid). If the verification is successful, the field is confirmed as the length field, and its key parameters are recorded: offset (the starting position of the field in the message), length (the number of bytes occupied by the field itself), and encoding method (e.g., big-endian, little-endian, etc.).

[0106] Locate the checksum field and determine its key parameters. The checksum field is typically located at the end of the message. Select a field from the variable fields near the end of the message (e.g., the last 2 or 4 bytes). Use common checksum algorithms such as CRC16, CRC32, Modbus, and XOR to perform checksum calculations on the content from the message header up to this field. Compare the calculation result with the byte value of this field. If they match, this field is determined to be the checksum field, and its key parameters are recorded: offset (field start position), length (number of bytes occupied by the field), and encoding method (checksum algorithm type and byte order).

[0107] Locating the data field and determining its key parameters: After excluding the identified length field, checksum field, and fixed field, the remaining variable field is the data field. The offset in its key parameters is the starting position of the data field, and the length is the total number of bytes occupied by the data field. The encoding method is tentatively set to be the same as the encoding rule of the length field or checksum field (which can be further modified through data parsing later).

[0108] Step a3: Determine the field attributes corresponding to each field in the data domain based on the key parameters of the key domain.

[0109] In this embodiment, field attributes include data type, encoding method, meaning, and offset. Step a3, based on the key parameters of the length field and checksum field, performs refined parsing of the data fields to clarify the specific attributes of each field:

[0110] Extracting the target data payload: Based on the data payload length determined by the length field, the fixed field, length field, and checksum field are stripped from the message to extract the clean data payload portion, which is used as the target object for field parsing.

[0111] Data type inference: Analyze the numerical characteristics and format patterns of each byte segment in the data payload to infer the data type of the corresponding field: If the byte segment value fluctuates within a reasonable integer range, it is determined to be an integer. If the byte segment conforms to the IEEE 754 standard byte arrangement format, it is determined to be a floating-point number. If the byte value corresponds to a printable ASCII or UTF-8 character and usually ends with 0x00, it is determined to be a string. In addition, it can also identify other data types such as Boolean and enumeration.

[0112] Encoding method inference: By combining the encoding methods of the length field and checksum field, as well as the byte arrangement characteristics of the data payload, the encoding method of each field can be inferred. For example, the byte order (big-endian or little-endian) can be verified through the numerical parsing results, and the character encoding format can be confirmed through the character display effect.

[0113] Field meaning and offset determination: Based on the data type, encoding method, and position of the field in the data payload, the meaning of the field is initially inferred (e.g., numeric fields may correspond to sensor data such as temperature and humidity, while string fields may correspond to device identification information). Simultaneously, the starting offset of each field in the data payload (the offset relative to the beginning of the data field) is recorded, ultimately forming the complete attribute information for each field.

[0114] Step a4: Determine the parsing rule description file based on the initial message structure, the key parameters of the key fields, and the field attributes corresponding to each field in the data field.

[0115] In this embodiment, step a4 integrates and optimizes all the aforementioned analysis results in a structured manner to generate a standardized parsing rule description file (YAML format). The specific process is as follows: First, following the syntax of the YAML file, the initial message structure (position information of fixed and variable fields), key parameters of key fields (length field, checksum field, offset of data field, length, encoding method), and attribute information of each field in the data field (data type, encoding method, meaning, offset) are organized into structured data. Then, additional message samples are selected to verify and test the rule file, and the rules are fine-tuned and optimized based on the parsing success rate (e.g., correcting field offsets, adjusting data type judgment criteria, supplementing special encoding rule descriptions, etc.). Finally, a complete and usable parsing rule description file is generated. This file is machine-readable and provides clear and accurate parsing logic for the creation of subsequent parser instances. It is then stored in the parsing rule base to support the access of devices with unknown protocols.

[0116] This embodiment achieves precise decomposition of unknown protocol message formats through a hierarchical parsing logic that infers the initial structure, locates key fields, and determines field attributes. This provides comprehensive and accurate foundational data for generating the parsing rule description file. By aligning and comparing multiple message samples, it distinguishes between fixed and variable fields, clarifies the basic framework of the protocol, and avoids confusion between core structures and redundant data during parsing. It accurately locates key fields such as the length field and checksum field and extracts key parameters, solving parsing failures caused by variable protocol message lengths and unknown checksum logic. It deeply analyzes the attributes of each field in the data fields, clarifying details such as data types and encoding methods, ensuring that subsequent data parsing can accurately reconstruct the original business data. The hierarchical parsing logic comprehensively covers the core elements of the protocol structure, ensuring the completeness and accuracy of the generated parsing rule description file, and guaranteeing the efficient operation of the parser instance.

[0117] In an optional implementation, step 2052, creating a corresponding parser instance based on the parsing rule description file, includes: storing the parsing rule description file in a parsing rule base and generating a rule update event. Upon detecting a rule update event, the parsing rule description file is retrieved from the parsing rule base, and a corresponding parser instance is created based on the parsing rule description file. The parser instance is stored in a parser cache pool, and the parser mapping table corresponding to the parser cache pool is updated. The parser mapping table includes unique identifiers of communication protocols and parser instances stored in a correspondence relationship.

[0118] In this embodiment, the parsing rule description file is a standardized YAML file generated based on the analysis of unknown protocol message formats. It contains complete parsing logic, including the initial message structure, key field parameters, and data field attributes. This file is stored in the parsing rule base of the device knowledge base, enabling centralized management and persistent storage of rules. Simultaneously, when the parsing rule base detects a new file being stored or an existing file being updated, it automatically generates a rule update event. This event is used to notify relevant modules to perform subsequent parser instance creation or update operations, ensuring that rule changes are detected in a timely manner.

[0119] In this embodiment, the parser factory monitors rule update events in real time. Upon detecting such an event, it immediately initiates a dynamic loading process: the parser factory actively retrieves the corresponding parsing rule description file from the parsing rule library through a preset interface (retrieving the newly added YAML file for a new protocol, and the updated YAML file for an existing protocol rule update), ensuring that the obtained parsing rules are the latest and most complete. This process requires no manual intervention, is fully automated, and does not affect the normal operation of the current device's access service.

[0120] In this embodiment, after the parser factory obtains the parsing rule description file, it completes the creation or update of the parser instance in memory, specifically in two scenarios:

[0121] New protocol scenario: If the parsing rule corresponds to an unknown protocol not included in the protocol fingerprint library, the parser factory reads the parsing logic in the YAML file and instantiates a brand new parser instance in memory through dynamic configuration technology. This instance has complete data parsing capabilities to adapt to the unknown protocol.

[0122] In scenarios involving updates to existing protocol rules: if the parsing rule is an optimization or correction of an existing protocol parsing rule, the parser factory creates a new version of the parser instance based on the updated rule. The instantiation or update process is entirely completed in memory, eliminating the need for code compilation, service deployment, or service restarts, thus avoiding device connection drops or data loss due to service interruptions.

[0123] In this embodiment, the parser factory stores newly created or updated parser instances in a parser cache pool. The parser cache pool maintains all available parser instances, supporting fast retrieval and reuse of instances. Simultaneously, it updates the parser mapping table corresponding to the parser cache pool. This mapping table stores the correspondence between the unique identifier of the communication protocol and the parser instance in key-value pairs (new protocols correspond to newly generated unique identifiers, and existing protocols correspond to the original unique identifiers).

[0124] To ensure the continuity and integrity of data parsing, the update process first initializes the new version parser instance in memory and confirms its availability before replacing the old version instance associated with the corresponding protocol identifier in the mapping table in one go (if it is a new protocol, the corresponding relationship is added directly). The entire replacement process is executed atomically without intermediate states, avoiding situations where the parser instance is unavailable or data parsing is abnormal.

[0125] In this embodiment, after the parser mapping table is updated, all subsequent received device message data matching the protocol will be automatically directed to the newly created or updated parser instance for processing through the routing mechanism of the protocol identification engine. For devices currently transmitting data, the entire process is completely seamless, preventing connection drops, session interruptions, data loss, or parsing errors. This achieves a smooth transition between parsing rule changes and parser updates, ensuring business continuity.

[0126] This embodiment achieves seamless deployment of parser instances, completely resolving the availability interruption issue caused by service restarts required for protocol updates in traditional methods. First, parsing rule description files are stored in a parsing rule base, enabling centralized management and reuse of rules. Second, rule update events trigger the parser factory to actively pull rules, ensuring new rules are detected promptly. Third, parser instances are dynamically created in memory, eliminating the need for compilation, deployment, and service restarts, thus avoiding device connection drops or data loss due to service interruptions. Finally, the parser mapping table is updated. The entire process ensures the rapid implementation of new protocol parsing capabilities.

[0127] In one optional implementation, the IoT device access method further includes: when a rule update event is detected, determining the corresponding protocol fingerprint based on the message data reported by the device to be accessed, and storing the protocol fingerprint in a protocol fingerprint database.

[0128] In this embodiment, the triggering of the rule update event not only corresponds to the addition or update of the parsing rule, but also simultaneously triggers the protocol fingerprint update process. Specifically, after detecting the rule update event, the system extracts the core features (including fixed domain features, key domain parameters, feature vectors, etc.) corresponding to the packet data reported by the device to be accessed, and combines this with the parsing logic in the parsing rule description file to encapsulate it into a standard protocol fingerprint format (the protocol fingerprint structure is P={W, F}). Subsequently, this protocol fingerprint is stored in the protocol fingerprint library of the device knowledge base, enabling dynamic expansion of the protocol fingerprint library.

[0129] In scenarios involving updates to existing protocol rules, the newly generated protocol fingerprint will replace the old version fingerprint corresponding to that protocol in the protocol fingerprint database, ensuring consistency between the protocol fingerprint and the parsing rules. In scenarios involving new protocols, the new protocol fingerprint will be added to the protocol fingerprint database, transforming the unknown protocol into a known protocol that the system can recognize. When connecting similar devices subsequently, the system can directly match the confidence level of the packet features with the protocol fingerprint and quickly call the corresponding parser instance to complete the connection, eliminating the need for repeated packet format analysis and rule generation, thus improving the connection efficiency for similar devices.

[0130] This embodiment achieves self-learning and iterative optimization of protocol recognition capabilities by updating the protocol fingerprint database upon detecting a rule update event. When connecting similar devices subsequently, the communication protocol can be quickly identified directly through confidence matching, eliminating the need for repeated message format analysis and rule generation, thus achieving one-time adaptation and permanent reuse. Simultaneously, the dynamic expansion of the protocol fingerprint database continuously increases the supported protocol types, gradually improving the adaptation coverage of heterogeneous devices and reducing long-term operation and maintenance costs.

[0131] Protocol hot loading process as follows Figure 7 As shown, its specific execution logic is as follows:

[0132] Process Initiation: Starting with "New Rule File Generation / Update," the process begins when a new parsing rule description file for an unknown protocol is added to the parsing rule base, or when an existing protocol's parsing rules are updated. Issuing Change Notifications: After detecting changes to the rule files, the parsing rule base proactively issues parsing rule change notifications to synchronize the rule update status with the system. Listening for Change Notifications: The parser factory continuously listens for rule change events in the system and triggers the subsequent loading process upon receiving such a notification.

[0133] Loading New Rule Files: The parser factory proactively requests the parsing rule base to retrieve the latest parsing rule description files, ensuring complete and valid parsing logic. Creating / Updating Parser Instances: Based on the newly retrieved rule files, the parser factory creates (corresponding to new protocols) or updates (corresponding to existing protocol rule iterations) parser instances in memory. This process does not require service restarts and is completed dynamically in memory. Storing Instances and Updating Mappings: The newly generated parser instances are stored in the parser cache pool, and the parser mapping table corresponding to the parser cache pool is atomically updated to establish a unique correspondence between the protocol identifier and the new parser instance. Data Packet Parsing and Routing: When a new data packet arrives at the system, it is determined whether its corresponding protocol matches the new parser instance. If it matches, the new parser instance is directly called to complete the protocol data parsing. If it does not match, the existing parser instance continues to process the data. Process End: After completing the parsing of the data packet, this protocol hot-loading process ends.

[0134] This embodiment also provides an IoT device access device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated. This embodiment provides an IoT device access device, such as... Figure 8 As shown, it includes:

[0135] The first processing module 301 is used to extract the message features corresponding to the message data reported by the device to be accessed.

[0136] The second processing module 302 is used to calculate the confidence level between the message features and the protocol fingerprints in the protocol fingerprint database. The protocol fingerprint database includes protocol fingerprints corresponding to multiple communication protocols, with one protocol fingerprint for each communication protocol.

[0137] The third processing module 303 is used to determine whether the maximum confidence level in the confidence level is greater than a preset threshold.

[0138] The fourth processing module 304 is used to connect to the device to be connected according to the communication protocol corresponding to the maximum confidence level if the maximum confidence level is greater than a preset threshold.

[0139] The fifth processing module 305 is used to create a corresponding parser instance based on the message characteristics if the maximum confidence level is less than or equal to a preset threshold, and then access the device to be accessed based on the parser instance.

[0140] The IoT device access apparatus provided in this application embodiment can execute the IoT device access method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0141] Figure 9 This is a schematic diagram of an electronic device provided in an embodiment of this application. See below for details. Figure 9 This diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from memory 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of the electronic device. The processor 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404. Typically, the following devices may be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory 408 including, for example, magnetic tape, hard disks, etc.; and communication devices 409. Communication devices 409 allow the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although... Figure 9 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0142] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from memory 408, or installed from ROM 402. When the computer program is executed by processor 401, it performs the functions defined in the IoT device access method of embodiments of this application. Figure 9 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0143] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the IoT device access method shown in the above embodiments is implemented.

[0144] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer.

[0145] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for connecting IoT devices, characterized in that, The method includes: Extract the message characteristics corresponding to the message data reported by the device to be connected; Calculate the confidence level between the message features and the protocol fingerprints in the protocol fingerprint database; the protocol fingerprint database includes protocol fingerprints corresponding to multiple communication protocols, with each communication protocol corresponding to one protocol fingerprint. Determine whether the maximum confidence level in the confidence level is greater than a preset threshold; If the maximum confidence level is greater than the preset threshold, then the device to be accessed is connected according to the communication protocol corresponding to the maximum confidence level; If the maximum confidence level is less than or equal to the preset threshold, a corresponding parser instance is created based on the message characteristics, and the device to be accessed is accessed based on the parser instance; The step of creating a corresponding parser instance based on the message characteristics includes: The message format of the message data is analyzed by a dynamic rule generator to obtain a parsing rule description file; The parsing rule description file is stored in the parsing rule base, and a rule update event is generated; When the rule update event is detected, the parser factory is triggered to actively retrieve the parsing rule description file from the parsing rule library and create a corresponding parser instance in memory based on the parsing rule description file; The parser instance is stored in the parser cache pool, and the parser mapping table corresponding to the parser cache pool is updated; the parser mapping table includes the unique identifier of the communication protocol and the parser instance stored in a correspondence relationship; When the rule update event is detected, the corresponding protocol fingerprint is determined based on the message data reported by the device to be accessed, and the protocol fingerprint is stored in the protocol fingerprint database.

2. The method according to claim 1, characterized in that, The calculation of the confidence level between the message features and the protocol fingerprints in the protocol fingerprint database includes: Determine the corresponding message feature vector based on the message characteristics; Determine the corresponding protocol fingerprint vector and feature weights based on the protocol fingerprint; By using multiple similarity calculation methods, the similarity between the message features and the protocol fingerprint is calculated based on the message feature vector, the protocol fingerprint vector, and the feature weight, respectively, to obtain the similarity corresponding to each similarity calculation method; The confidence level is determined based on the similarity corresponding to each similarity calculation method.

3. The method according to claim 2, characterized in that, The step of determining the confidence level based on the similarity corresponding to each similarity calculation method includes: Obtain the weight corresponding to each similarity calculation method; The confidence level is obtained by summing the products of the similarity and the corresponding weight for each similarity calculation method.

4. The method according to claim 1, characterized in that, The analysis of the message format of the message data yields a parsing rule description file, including: The message data is analyzed to obtain an initial message structure; the initial message structure includes fixed fields and the location information of the fixed fields, and variable fields and the location information of the variable fields. Based on the initial message structure, the key parameters of the key fields in the variable field are determined. The key fields include a length field, a data field, and a checksum field. The key parameters include: offset, length, and encoding method. Based on the key parameters of the key domain, determine the field attributes corresponding to each field in the data domain. The field attributes include data type, encoding method, meaning, and offset. The parsing rule description file is determined based on the initial message structure, the key parameters of the key fields, and the field attributes corresponding to each field in the data fields.

5. An Internet of Things (IoT) device access device, characterized in that, The device includes: The first processing module is used to extract the message features corresponding to the message data reported by the device to be connected; The second processing module is used to calculate the confidence level between the message features and the protocol fingerprints in the protocol fingerprint database; the protocol fingerprint database includes protocol fingerprints corresponding to multiple communication protocols, with each communication protocol corresponding to one protocol fingerprint. The third processing module is used to determine whether the maximum confidence level in the confidence level is greater than a preset threshold. The fourth processing module is used to access the device to be accessed according to the communication protocol corresponding to the maximum confidence level if the maximum confidence level is greater than the preset threshold. The fifth processing module is used to create a corresponding parser instance based on the message characteristics if the maximum confidence level is less than or equal to the preset threshold, and then access the device to be accessed based on the parser instance. The fifth processing module is specifically used to analyze the message format of the message data through a dynamic rule generator to obtain a parsing rule description file; The parsing rule description file is stored in the parsing rule base, and a rule update event is generated; When the rule update event is detected, the parser factory is triggered to actively retrieve the parsing rule description file from the parsing rule library and create a corresponding parser instance in memory based on the parsing rule description file; The parser instance is stored in the parser cache pool, and the parser mapping table corresponding to the parser cache pool is updated; the parser mapping table includes the unique identifier of the communication protocol and the parser instance stored in a correspondence relationship; The fifth processing module is further configured to, when the rule update event is detected, determine the corresponding protocol fingerprint based on the message data reported by the device to be accessed, and store the protocol fingerprint in the protocol fingerprint database.

6. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the steps of the IoT device access method according to any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the steps of the Internet of Things device access method according to any one of claims 1 to 4.

Images