Iot device intelligent access method and system based on double-track triggering and virtual-real simulation

Abstract

The application discloses a kind of based on double-track triggering and virtual-real simulation internet of things equipment intelligent access method and system, and intelligent access method includes the following steps: S1, by the double-track mode of active discovery and manual entry obtains device information and protocol document;S2, based on the hybrid similarity algorithm of TF-IDF and semantic embedding combination, the discovery list of the device to be accessed is automatically associated with the communication protocol document;S3, calling multimodal large language model is automatically parsed to the communication protocol document, generates the standardization physical model of the device to be accessed;S4, based on the standardization physical model automatically generates the access code of the device to be accessed;S5, before the real device to be accessed access, the data link pre-test of the access code is completed through the virtual device;S6, through visual guide interface completes the access confirmation and delivery of the device to be accessed;The application can improve the efficiency of device access, while saving labor cost.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a method and system for intelligent access of IoT devices based on dual-track triggering and virtual-real simulation. Background Technology

[0002] With the rapid development of IoT technology, the number of various devices (sensors, controllers, smart terminals, etc.) is exploding. IoT platforms need to connect to a massive number of heterogeneous devices, which often use different communication protocols (MQTT, CoAP, HTTP, Modbus, etc.), data formats, and authentication mechanisms. According to IDC predictions, the number of IoT devices worldwide will exceed 30 billion by 2026. Device connection efficiency has become a key bottleneck for industry development. In current technologies, when connecting devices to an IoT platform, developers need to manually read the communication protocol documents of the corresponding devices and write the corresponding access code. This process usually takes 3-7 days, which is inefficient. Summary of the Invention

[0003] This invention discloses an intelligent access method and system for IoT devices based on dual-track triggering and virtual-real simulation. The dual-track triggering module actively discovers devices to be accessed, and automatically extracts fixed key information from the communication protocol document through a large language model. Based on the key information, a standardized object model is generated, and then the corresponding access code is automatically generated based on the standardized object model. Only a certain amount of manual adjustment is required when the matching confidence is less than a preset threshold. In other cases, the device access can be completed automatically, thus improving access efficiency.

[0004] This invention discloses a smart access method for IoT devices based on dual-track triggering and virtual-real simulation, comprising the following steps: S1. Obtain device information and protocol documents through a dual-track approach of proactive discovery and manual entry. Proactive discovery methods include: using a network scanning engine to probe a specified network segment and generating a device discovery list of devices to be connected; Manual input methods include: users manually uploading the communication protocol document corresponding to each of the devices to be connected; S2. Based on a hybrid similarity algorithm combining TF-IDF and semantic embedding, obtain the matching confidence score between each device to be accessed and the corresponding communication protocol document, and determine whether the matching confidence score is greater than a preset threshold: if yes, proceed to step S3; if no, manually adjust the communication protocol document and re-execute step S2. S3. Call the multimodal large language model to automatically parse the communication protocol document, extract key information from the communication protocol document, and generate a standardized object model of the device to be accessed based on the key information. S4. Automatically generate the access code of the device to be accessed based on the standardized object model; S5. Construct a virtual device instance based on the standardized object model, and perform data link pre-testing of the access code through the virtual device before the actual access device is connected. S6. Complete the access confirmation and delivery of the device to be connected through the visual wizard interface.

[0005] A further improvement of the present invention is that, in step S3, the key information in the communication protocol document includes the communication protocol type, data format definition, authentication mechanism, and command interface information.

[0006] A further improvement of the present invention is that, in step S3, the standardized object model of the device to be accessed includes device attribute definitions, service definitions, and event definitions.

[0007] A further improvement of the present invention is that step S4 specifically includes the following steps: S41. Based on the target programming language and IoT platform technology stack, generate device access code using a large language model based on the standardized object model, and perform automatic compilation on the device access code; S42. Check if there are any compilation errors, missing dependencies, or type mismatches in the automatically compiled device access code: If there are no such problems, directly output the device access code and proceed to step S5; if any of the above problems exist, feed the corresponding problem back to the large language model for intelligent repair, and re-execute steps S41~S42.

[0008] A further improvement of the present invention is that step S5 specifically includes the following steps: S51. Generate virtual device instances based on the standardized object model to simulate the protocol behavior and data reporting of real devices to be accessed; S52. Execute a set of pre-test cases, including coverage connection test, data parsing test, rule engine test and exception handling test, on the device access code using the virtual device instance; S53. After the pre-test case set is completed, if any test in the pre-test case set fails, the corresponding error information is fed back to the large language model in step S4, and steps S41 to S42 are re-executed to optimize the device access code; if all tests in the pre-test case set pass, proceed to step S6.

[0009] A further improvement of the present invention is that the content of the device discovery list includes device fingerprints. In step S2, based on a hybrid similarity algorithm combining TF-IDF and semantic embedding, the discovery list of devices to be accessed is automatically associated with the communication protocol document, specifically including the following steps: S21. Convert both the device fingerprint and the communication protocol document into TF-IDF vectors, and compare the TF-IDF vectors of the two to obtain their TF-IDF similarity; convert both the device fingerprint and the communication protocol document into BERT semantic vectors, and compare the BERT semantic vectors of the two to obtain their BERT semantic similarity. S22. Based on the TF-IDF similarity and the BERT semantic similarity, obtain the matching confidence level (Similarity) between the device to be accessed and the communication protocol document: Similarity = α × TF-IDF_Cosine + (1-α) × BERT_Similarity; Where α is the weight coefficient; TF-IDF_Cosine is the TF-IDF similarity; and BERT_Similarity is the BERT semantic similarity.

[0010] This invention discloses an access system for an IoT device intelligent access method based on dual-track triggering and virtual-real simulation, comprising: A dual-track triggering module is used to acquire the information of the device to be accessed and the communication protocol document in parallel; The intelligent deconstruction module is used to automatically parse the communication protocol document, extract key information from the communication protocol document, and generate a standardized object model of the device to be accessed based on the key information. A closed-loop generation module is used to automatically generate the access code of the device to be accessed based on the standardized object model. The virtual-real simulation module is used to build virtual device instances to pre-verify the access code before connecting to real devices; The wizard delivery module is used to complete the access confirmation and delivery of the device to be accessed.

[0011] A further improvement of the present invention is that the dual-rail triggering module includes: The active discovery submodule is used to probe a specified network segment, identify the devices to be accessed, and generate a corresponding device discovery list; The manual input submodule is used to receive the communication protocol document uploaded by the user; The intelligent matching engine is used to output the matching confidence level between the device to be connected and the communication protocol document.

[0012] A further improvement of the present invention is that the intelligent deconstruction module includes: An AI deep reading engine is used to perform deep reading of the communication protocol document and extract key information using a multimodal large language model; The structured extraction module is used to map the extracted key information into a standardized object model.

[0013] A further improvement of the present invention is that the closed-loop generation module includes: An LLM code generation engine is used to generate access code for the target language based on the standardized object model definition. The compilation verification module is used to perform compilation checks on the access code; An autonomous error correction mechanism is used to feed back the problems detected by the compilation and verification module to the LLM code generation engine for intelligent repair.

[0014] This invention discloses an intelligent access method and system for IoT devices based on dual-track triggering and virtual-real simulation. The dual-track triggering module actively discovers devices to be accessed, and automatically extracts fixed key information from the communication protocol document through a large language model. Based on the key information, a standardized object model is generated, and then the corresponding access code is automatically generated based on the standardized object model. Only a certain amount of manual adjustment is required when the matching confidence is less than a preset threshold. In other cases, the device access can be completed automatically, thus improving access efficiency. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the overall system of the present invention; Figure 2 This is a schematic diagram of the dual-track triggering module of the present invention; Figure 3 This is a schematic diagram of the closed-loop generation module process of the present invention; Figure 4 This is a schematic diagram of the virtual-real simulation module architecture of the present invention; Figure 5 This is a flowchart illustrating the overall process of accessing the present invention. Figure 6 This is a flowchart illustrating an embodiment of the present invention. Detailed Implementation

[0016] like Figures 1-5 As shown, a smart access method for IoT devices based on dual-track triggering and virtual-real simulation includes the following steps: S1. Obtain device information and protocol documents through a dual-track approach of proactive discovery and manual entry. Proactive discovery methods include: using a network scanning engine to probe a specified network segment and generating a device discovery list of devices to be connected; Manual input methods include: users manually uploading the communication protocol document corresponding to each of the devices to be connected; Preferably, in this embodiment, the device discovery list includes the IP address, open port, protocol type, and device fingerprint of the device to be accessed.

[0017] Preferably, in this embodiment, the communication protocol document supports PDF documents (versions 1.0-2.0), Word documents (.docx format), Markdown documents (.md format), Excel spreadsheets (.xlsx format, used for technical parameter tables), and JSON / XML structured files.

[0018] S2. Obtain the matching confidence score between each device to be accessed and the corresponding communication protocol document, and determine whether the matching confidence score is greater than a preset threshold: if yes, proceed to step S3; if no, manually adjust the communication protocol document and re-execute step S2. In this embodiment, the preset threshold is 0.65, which can be adjusted based on the actual situation.

[0019] S3. Call the multimodal large language model to automatically parse the communication protocol document, extract key information from the communication protocol document, and generate a standardized object model of the device to be accessed based on the key information. S4. Automatically generate the access code of the device to be accessed based on the standardized object model; S5. Construct a virtual device instance based on the standardized object model, and perform data link pre-testing of the access code through the virtual device before the actual access device is connected. S6. Complete the access confirmation and delivery of the device to be connected through the visual wizard interface.

[0020] Preferably, in step S3, the key information in the communication protocol document includes the communication protocol type, data format definition, authentication mechanism, and command interface information.

[0021] Preferably, in step S3, the standardized object model of the device to be accessed includes device attribute definitions, service definitions, and event definitions.

[0022] Preferably, step S3 specifically includes the following steps: S31. Use a multimodal large language model to perform in-depth reading of the communication protocol document and extract key information, including communication protocol type, data format definition, authentication mechanism and command interface information; S32. The extracted key information is mapped to a standardized object model, which includes device attribute definitions, service definitions, and event definitions.

[0023] Preferably, step S4 specifically includes the following steps: S41. Based on the target programming language and IoT platform technology stack, generate device access code using a large language model based on the standardized object model, and perform automatic compilation on the device access code; Check if there are any compilation errors, missing dependencies, or type mismatches in the automatically compiled device access code: if there are no such problems, directly output the device access code and proceed to step S5; if any of the above problems exist, feed the corresponding problem back to the large language model for intelligent repair, and re-execute steps S41~S42.

[0024] S431. Directly output the device access code and proceed to step S5; S432. Feedback the above problems to the large language model for intelligent repair, and re-execute steps S41~S42 until the automatically compiled device access code no longer has the above problems. Then, output the device access code and execute step S5.

[0025] Preferably, step S5 specifically includes the following steps: S51. Generate virtual device instances based on the standardized object model to simulate the protocol behavior and data reporting of real devices to be accessed; S52. Execute a set of pre-test cases, including coverage connection test, data parsing test, rule engine test and exception handling test, on the device access code using the virtual device instance; S53. After the pre-test case set is completed, if any test in the pre-test case set fails, the corresponding error information is fed back to the large language model in step S4, and steps S41 to S42 are re-executed to optimize the device access code; if all tests in the pre-test case set pass, proceed to step S6.

[0026] Preferably, in step S3, the multimodal large language model parses the text content, image content, and table structure in the communication protocol document to extract key information from the communication protocol document.

[0027] Preferably, in step S2, the automatic association between the discovery list of devices to be accessed and the communication protocol document based on a hybrid similarity algorithm combining TF-IDF and semantic embedding specifically includes the following steps: S21. Convert both the device fingerprint and the communication protocol document into TF-IDF vectors, and compare the TF-IDF vectors of the two to obtain their TF-IDF similarity; convert both the device fingerprint and the communication protocol document into BERT semantic vectors, and compare the BERT semantic vectors of the two to obtain their BERT semantic similarity. Obtaining the matching confidence level between the device to be accessed and the communication protocol document specifically includes the following steps: S22. Based on the TF-IDF similarity and the BERT semantic similarity, obtain the matching confidence level (Similarity) between the device to be accessed and the communication protocol document: Similarity = α × TF-IDF_Cosine + (1-α) × BERT_Similarity; Where α is the weight coefficient, which has a default value of 0.3 in this embodiment and can be adjusted according to the actual situation; TF-IDF_Cosine is the TF-IDF similarity; BERT_Similarity is the BERT semantic similarity.

[0028] This invention discloses an access system for an IoT device intelligent access method based on dual-track triggering and virtual-real simulation, comprising: A dual-track triggering module is used to acquire the information of the device to be accessed and the communication protocol document in parallel; The intelligent deconstruction module is used to automatically parse the communication protocol document, extract key information from the communication protocol document, and generate a standardized object model of the device to be accessed based on the key information. A closed-loop generation module is used to automatically generate the access code of the device to be accessed based on the standardized object model. The virtual-real simulation module is used to build virtual device instances to pre-verify the access code before connecting to real devices; The wizard delivery module is used to complete the access confirmation and delivery of the device to be accessed.

[0029] Preferably, the dual-rail triggering module includes: The active discovery submodule is used to probe a specified network segment, identify the devices to be accessed, and generate a corresponding device discovery list; The manual input submodule is used to receive the communication protocol document uploaded by the user; The intelligent matching engine is used to output the matching confidence level between the device to be connected and the communication protocol document.

[0030] Preferably, in this embodiment, as Figure 1 As shown, the proactive discovery submodule is configured with: 1. Network scanning engine, which is based on the nmap open-source network scanning engine or an equivalent implementation, and is deployed as a background scanning service; supports TCP / UDP port scanning, and the scanning range supports specifying IP ranges (CIDR format, such as 192.168.1.0 / 24); concurrent scanning control: the default number of concurrent threads is 10; 2. Protocol identification strategy, as shown in the table below.

[0031] 3. Device fingerprint extraction; Generate a device fingerprint hash using protocol features and banner information; Fingerprint format: {protocol type}{vendor identifier}{device type}_{version number}; Example: MQTT_Huawei_Sensor_v3.1.1.

[0032] 4. Output of the equipment discovery list; Preferably, in this embodiment, as Figure 1 As shown, the manual data entry submodule is configured as follows: 1. Supported document formats: PDF documents (versions 1.0-2.0), Word documents (.docx format), Markdown documents (.md format), Excel spreadsheets (.xlsx format, used for technical parameter tables), JSON / XML structured files; 2. Document preprocessing workflow: Format verification: Verify file integrity and MIME type; Text extraction: PDF parsing (text extraction or OCR recognition), Word / XML parsing; Encoding unification: Convert to UTF-8 encoding; 3. Metadata Import Interface: Supports importing device metadata in JSON format; supports importing device description files in XML format; provides a REST API for batch import. Preferably, the intelligent destructuring module includes: An AI deep reading engine is used to perform deep reading of the communication protocol document and extract key information using a multimodal large language model; The structured extraction module is used to map the extracted key information into a standardized object model.

[0033] Preferably, in this embodiment, the AI ​​deep reading engine is configured as follows: 1. Multimodal processing capability: Supports direct parsing of text content (extracting from PDF / Word / Markdown); Supports image content parsing (protocol block diagrams, timing diagrams, etc.); Supports table structure parsing (parameter tables, data format definitions, etc.); 2. Configuration of multimodal large language model: Supports mainstream business models: GPT-4, Claude 3 series; Supports open-source models: Qwen, LLaMA, ChatGLM, etc. Supports private deployment models; Prompt Engineering: Designing dedicated protocol parsing prompt templates to guide the model in accurately extracting key information; 3. Protocol parsing content:

[0034] Preferably, the closed-loop generation module includes: An LLM code generation engine is used to generate access code for the target language based on the standardized object model definition. The compilation verification module is used to perform compilation checks on the access code; An autonomous error correction mechanism is used to feed back the problems detected by the compilation and verification module to the LLM code generation engine for intelligent repair.

[0035] In this embodiment, the target languages ​​supported by the LLM code generation engine include: Python (mainstream IoT SDKs: paho-mqtt, aiocoap, etc.); Java (Spring IoT, Eclipse Californium, etc.); Go (eclipse / paho.mqtt.golang, go-coap, etc.); JavaScript / TypeScript (Node.js IoT SDK).

[0036] In this embodiment, the code generated by the LLM code generation engine is as follows:

[0037] In this embodiment, the autonomous error correction mechanism adopts an iterative mechanism of "generation-compilation-detection-repair", specifically including: 1. Error Classification and Handling Strategies:

[0038] 2. Compilation and verification configuration: Python: Use py_compile for syntax checking and pylint for code analysis; Java: Compiles with javac and uses Checkstyle for code style checks; Go: Compile using `go build`, and perform code analysis using `golangci-lint`; 3. Maximum number of iterations: The default setting is 5 times. Once the limit is reached, the current best result will be output and marked.

[0039] Preferably, in this embodiment, the closed-loop generation module further includes a code quality assessment module, which can analyze various indicators of the access code. The analysis indicators include: lines of code (LOC), cyclomatic complexity (McCabeComplexity), duplicate code rate, comment coverage, and security vulnerability scanning.

[0040] Preferably, the virtual-real simulation module includes a virtual device builder, a data simulation engine, and a link pre-testing framework.

[0041] The virtual device builder has the following functions: 1. Digital twin instance generation: Virtual device classes are dynamically generated based on the object model definition. Inherit the communication behavior characteristics of real devices; Supports instantiation of multiple virtual devices at runtime; 2. Protocol Stack Simulation: MQTT virtual client: Supports CONNECT, PUBLISH, SUBSCRIBE, and DISCONNECT; CoAP virtual client: supports GET, POST, PUT, DELETE, and OBSERVE; HTTP Virtual Client: Supports RESTful API calls; Simulate the protocol behavior of real devices, including reconnection mechanisms and heartbeat keep-alive; 3. Authentication process simulation: Equipment certification (X.509 certificate); Token authentication (DeviceSecret, DeviceToken); One-time password authentication (OTP).

[0042] The data simulation engine includes: 1. Data generation strategy, as shown in the table below:

[0043] 2. Reporting control frequency: Supports fixed frequency (e.g., 1Hz, 0.1Hz); supports event triggering (e.g., reporting when status changes); supports batch reporting (e.g., summarizing once per minute).

[0044] Preferably, the wizard delivery module in this embodiment realizes the confirmation and delivery of device access results through a visual wizard interface. Users do not need to write any code throughout the process, truly achieving zero-code, one-click access. It includes: a configuration summary generator, a one-click confirmation mechanism, AI intelligent verification, and an SDK packaging and publishing device.

[0045] The configuration summary generator is used for visual preview, and its displayed content includes: a list of devices, a tree structure of object model definitions, data format examples, and a test report summary.

[0046] AI-powered intelligent verification includes the following verification content: 1. Configure conflict detection; 2. Scan for security vulnerabilities; 3. Output risk warnings.

[0047] The SDK packager and publisher packages and publishes the access code for the devices to be integrated. The published content specifically includes: 1. Source code package (.zip format); 2. Compilation artifacts (if applicable); 3. requirements.txt / pom.xml / go.mod; 4. Deployment documentation (README.md); 5. API interface documentation.

[0048] Example 1: MQTT protocol temperature sensor access; Scene description:

[0049] A factory needs to connect a batch of temperature sensors that use the MQTT protocol. The device IP range is 192.168.1.0 / 24, and the protocol document is in PDF format.

[0050] Implementation steps: S1, dual-track triggering, including active discovery and manual entry. Proactive discovery includes the following steps: The system calls nmap to scan the 192.168.1.0 / 24 network segment, with the following configuration parameters: scan timeout of 30 seconds and 10 concurrent threads. It discovers 5 devices with port 1883 open (the default MQTT port). An MQTT CONNECT message is sent to each device, and the server's response banner is captured. The banner recognition result is "MQTT / 3.1.1" + server identifier. A device discovery list is generated, including IP address, port, protocol type, and device fingerprint. Manual entry: Users upload "Temperature Sensor Communication Protocol V2.1.pdf" as the communication protocol document; S2. The system performs PDF parsing, extracting approximately 5000 words of text content. The document content includes: communication protocol section, data format section, and command definition section. Based on a hybrid similarity algorithm combining TF-IDF and semantic embedding, the system extracts PDF keywords: "temperature sensor", "MQTT protocol", and "Topic definition". It also extracts device fingerprint keywords: "MQTT" and "1883 port". The communication protocol document is calculated to have a TF-IDF similarity of 0.78, a BERT semantic similarity of 0.92, and a matching confidence of approximately 0.87. Since these values ​​are greater than the preset threshold in this embodiment, the automatic association is successful. S3. Utilize a multimodal large language model (such as GPT-4 Vision) to analyze the PDF content and identify key information, including: - Broker address: tcp: / / 192.168.1.100:1883; - ClientID format: sensor_{device_id}; − Report Topic: / factory / {floor} / sensor / {id} / telemetry; − Downstream Topic: / factory / {floor} / sensor / {id} / command; - QoS level: 1 (at least once); - Data format: JSON, including temperature (float), humidity (float), and timestamp (ISO8601). And based on the above key information, a standardized object model is constructed; S4. Generate device access code based on the standardized object model, with Python as the target language. After generating the device access code, compile and verify the code and perform self-correction, and conduct a quality assessment of the code. S5. Construct a virtual device instance, including the following steps: Five virtual temperature sensors were instantiated based on the object model; The virtual client connects to the MQTT Broker; Simulated certification process (no real device certificate required); Then, data simulation and data link pre-testing were performed; S6. Complete the access confirmation and delivery of the device to be connected through the visual wizard interface.

[0051] The above-described Example 1 took a total of 18 minutes; required only 2 manual interventions (uploading PDF, access confirmation); required 0 lines of manual code; and had a 100% success rate for first-time access (5 out of 5 devices).

[0052] Example 2: CoAP protocol smart lighting controller access (scenario with incomplete communication protocol documentation);

[0053] Scene description: The smart park project uses intelligent lighting controllers that connect to the CoAP protocol. The equipment has been deployed, but the documentation is missing, with only a partial technical parameter Excel sheet available.

[0054] Implementation steps: S1: Dual-track triggering, including proactive discovery and manual entry. Active discovery: nmap scan revealed 3 devices with port 5683 open (the default port for CoAP); Send a CoAP CON probe message and capture the response; Response feature analysis: The device type is identified as "lighting controller"; Device fingerprint: CoAP_Unknown_Controller_v1.0; Manual entry: Users can only provide the "Intelligent Lighting System Technical Parameter Table.xlsx" as a communication protocol file. The content of this file includes: device model, IP address, port number, and some register addresses; it does not have a complete protocol document, only a parameter table. S2. The system calculates the matching confidence based on the keywords "lighting", "CoAP", and "5683". The matching confidence is 0.72, which is lower than the preset threshold set in this embodiment. At this time, the system indicates that manual confirmation is required to manually adjust the communication protocol document. In implementation two, the communication protocol document can be analyzed using a multimodal large language model to assist in adjustments and to construct a complete communication mechanism; after adjustments, continue to execute steps S3 to S6; In step S4, Java SDK code is generated (target framework: Eclipse Californium). The first compilation fails, indicating a missing CoapClient class reference. LLM automatically repairs this by adding the Californium dependency. After the repair, the second compilation succeeds. In step S5, the virtual device simulates the CoAP Observe mechanism to test bidirectional control (the platform issues commands and the device actively reports), and the test is successful. In step S6, the wizard delivery is completed, and three devices are connected with one click. Users can adjust the brightness and color temperature through the operation and maintenance interface.

[0055] Example 3: HTTP Protocol Industrial Gateway Access (Abnormal Handling Scenario);

[0056] Scene description: A manufacturing company's industrial gateway connected to the HTTP protocol has complex device data formats, including multiple data types and nested structures. The initial code generation contained logical errors. In this example, steps S1 to S3 are similar to those in the first embodiment. During step S4, access code is generated using Go as the target language. After generating the device access code, a logical error is found during compilation and verification. Specifically, executing the command `golangci-lint run gateway_client.go` generates a report showing the following error in the code: Line 45: Array out-of-bounds risk - accessing data.values[5] may exceed the slice length; Line 67: Null pointer risk - accessing .length when status.error_msg may be null; Line 89: JSON parsing risk - using result directly without checking the err return value; At this point, the access code is corrected using the autonomous error correction mechanism of the large language model. The repair strategy is as follows: Add array length check: if idx <len(data.values); Add a null pointer check: if status.error_msg != nil; Add error checking: if err != nil { return err}; After the repair is completed, a second check is performed on the device access code. If the problem is found to have been fixed, then proceed to step S5. During step S5, the data link pre-test of the access code is completed through the virtual device. The specific test process is as follows: Test Scenario 1: The "pressure" field is missing; - Expected outcome: The SDK should process correctly and output a warning log. - Actual result: Passed, output WARN: missing field pressure; Test Scenario 2: Nested objects are nested too deeply; - Expected outcome: Correctly resolve to the maximum depth; - Actual result: Passed, maximum parsing depth set to 5; Test Scenario 3: Incorrect data type; • Expected response: The temperature field should receive the string "abc"; • In practice: The SDK correctly reports errors and does not crash; Verification Report: Exception handling test: 3 out of 3 passed; Missing field handling: Passed; Nesting depth control: via type error handling: via.

[0057] After the test is passed, proceed to step S6 for confirmation and delivery.

[0058] In Example 3, a self-correcting mechanism for the code automatically repaired several potential defects, preventing errors from occurring after subsequent device access.

[0059] This invention has the following advantages: 1. Solving the problem of disconnect between discovery and parsing: By using a dual-track parallel access method and parsing of a large language model, intelligent linkage between device active discovery and protocol document parsing is achieved, eliminating the manual matching step, speeding up access efficiency, and saving labor costs; 2. Solve the problem of automatic understanding of unstructured documents: Utilize AI large language model technology to automatically parse unstructured protocol documents and extract standardized object models; 3. Solve code generation reliability issues: Build a closed loop of generation-compilation-verification-optimization to achieve self-correction of code; 4. Solve the problem of pre-testing and verification: Complete data link pre-testing before actual device access to reduce access risks.

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

Claims

1. A method for intelligent access of IoT devices based on dual-track triggering and virtual-real simulation, characterized in that, Includes the following steps: S1. Obtain device information and protocol documents through a dual-track approach of proactive discovery and manual entry. Proactive discovery methods include: using a network scanning engine to probe a specified network segment and generating a device discovery list of devices to be connected; Manual input methods include: users manually uploading the communication protocol document corresponding to each of the devices to be connected; S2. Based on a hybrid similarity algorithm combining TF-IDF and semantic embedding, obtain the matching confidence score between each device to be accessed and the corresponding communication protocol document, and determine whether the matching confidence score is greater than a preset threshold: if yes, proceed to step S3; if no, manually adjust the communication protocol document and re-execute step S2. S3. Call the multimodal large language model to automatically parse the communication protocol document, extract key information from the communication protocol document, and generate a standardized object model of the device to be accessed based on the key information. S4. Automatically generate the access code of the device to be accessed based on the standardized object model; S5. Construct a virtual device instance based on the standardized object model, and perform data link pre-testing of the access code through the virtual device before the actual access device is connected. S6. Complete the access confirmation and delivery of the device to be connected through the visual wizard interface.

2. The IoT device intelligent access method based on dual-track triggering and virtual-real simulation as described in claim 1, characterized in that, In step S3, the key information in the communication protocol document includes the communication protocol type, data format definition, authentication mechanism, and command interface information.

3. The IoT device intelligent access method based on dual-track triggering and virtual-real simulation as described in claim 1, characterized in that, In step S3, the standardized object model of the device to be accessed includes device attribute definitions, service definitions, and event definitions.

4. The IoT device intelligent access method based on dual-track triggering and virtual-real simulation as described in claim 1, characterized in that, Step S4 specifically includes the following steps: S41. Based on the target programming language and IoT platform technology stack, generate device access code using a large language model based on the standardized object model, and perform automatic compilation on the device access code; S42. Check if there are any compilation errors, missing dependencies, or type mismatches in the automatically compiled device access code: If there are no such problems, directly output the device access code and proceed to step S5; if there are such problems, feed the corresponding problems back to the large language model for intelligent repair, and re-execute steps S41~S42.

5. The IoT device intelligent access method based on dual-track triggering and virtual-real simulation as described in claim 4, characterized in that, Step S5 specifically includes the following steps: S51. Generate virtual device instances based on the standardized object model to simulate the protocol behavior and data reporting of real devices to be accessed; S52. Execute a set of pre-test cases, including coverage connection test, data parsing test, rule engine test and exception handling test, on the device access code using the virtual device instance; S53. After the pre-test case set is completed, if any test in the pre-test case set fails, the corresponding error information is fed back to the large language model in step S4, and steps S41 to S42 are re-executed to optimize the device access code; if all tests in the pre-test case set pass, proceed to step S6.

6. The IoT device intelligent access method based on dual-track triggering and virtual-real simulation as described in claim 1, characterized in that, The device discovery list includes device fingerprints. In step S2, based on a hybrid similarity algorithm combining TF-IDF and semantic embedding, the discovery list of devices to be accessed is automatically associated with the communication protocol document. This specifically includes the following steps: S21. Convert both the device fingerprint and the communication protocol document into TF-IDF vectors, and compare the TF-IDF vectors of the two to obtain their TF-IDF similarity; convert both the device fingerprint and the communication protocol document into BERT semantic vectors, and compare the BERT semantic vectors of the two to obtain their BERT semantic similarity. S22. Based on the TF-IDF similarity and the BERT semantic similarity, obtain the matching confidence level (Similarity) between the device to be accessed and the communication protocol document: Similarity = α × TF-IDF_Cosine + (1-α) × BERT_Similarity; Where α is the weight coefficient; TF-IDF_Cosine is the TF-IDF similarity; and BERT_Similarity is the BERT semantic similarity.

7. An access system for an IoT device intelligent access method based on dual-track triggering and virtual-real simulation as described in claim 1, characterized in that, include: A dual-track triggering module is used to acquire the information of the device to be accessed and the communication protocol document in parallel; The intelligent deconstruction module is used to automatically parse the communication protocol document, extract key information from the communication protocol document, and generate a standardized object model of the device to be accessed based on the key information. A closed-loop generation module is used to automatically generate the access code of the device to be accessed based on the standardized object model. The virtual-real simulation module is used to build virtual device instances to pre-verify the access code before connecting to real devices; The wizard delivery module is used to complete the access confirmation and delivery of the device to be accessed.

8. The access system of the IoT device intelligent access method based on dual-track triggering and virtual-real simulation as described in claim 7, characterized in that, The dual-rail triggering module includes: The active discovery submodule is used to probe a specified network segment, identify the devices to be accessed, and generate a corresponding device discovery list; The manual input submodule is used to receive the communication protocol document uploaded by the user; The intelligent matching engine is used to output the matching confidence level between the device to be connected and the communication protocol document.

9. The access system of the IoT device intelligent access method based on dual-track triggering and virtual-real simulation as described in claim 7, characterized in that, The intelligent deconstruction module includes: An AI deep reading engine is used to perform deep reading of the communication protocol document and extract key information using a multimodal large language model; The structured extraction module is used to map the extracted key information into a standardized object model.

10. The access system of the IoT device intelligent access method based on dual-track triggering and virtual-real simulation as described in claim 7, characterized in that, The closed-loop generation module includes: An LLM code generation engine is used to generate access code for the target language based on the standardized object model definition. The compilation verification module is used to perform compilation checks on the access code; An autonomous error correction mechanism is used to feed back the problems detected by the compilation and verification module to the LLM code generation engine for intelligent repair.

Images