An iot multi-source protocol component processing method and related device

Abstract

This application discloses a method and related equipment for processing multi-source protocol components in the Internet of Things (IoT). The method includes: acquiring a protocol document; determining standardized document data based on the protocol document; extracting structured information based on the standardized document data; generating a standard protocol parsing class and supporting resources based on the structured information and IoT platform interface specifications to generate a protocol component; and loading and registering the protocol component to form a protocol buffer pool. Embodiments of this application can improve the heterogeneous device access capability and protocol adaptation efficiency of IoT platforms. This application can be widely applied in the field of IoT technology.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things, and in particular to an Internet of Things multi-source protocol component processing method and related equipment. BACKGROUND

[0002] In today's accelerating penetration of digital economy, as the key infrastructure connecting the physical world and the digital space, the Internet of Things is ushering in an explosive period of large-scale development. From the intelligent factory of industrial manufacturing to the smart city of urban governance, from the personalized service of smart home to the precise diagnosis and treatment of smart medical care, the application scenarios of Internet of Things technology are constantly expanding, and the number of connected devices is growing exponentially. According to relevant data statistics, the number of connected devices in the global Internet of Things has exceeded 10 billion, and is still expanding at a double-digit annual growth rate. However, behind this vigorous development, the access demand of a large number of heterogeneous devices is bringing a severe test to the Internet of Things platform, and has become a key bottleneck restricting the high-quality development of the industry.

[0003] Different manufacturers and different types of Internet of Things devices, due to differences in design intention, application scenario and technical standard, adopt communication protocols that show significant diversification characteristics. The mainstream communication protocols on the market include MQTT, Modbus, OPC UA and other general-purpose protocols, and there are also a large number of private custom protocols developed by manufacturers. These protocols have great differences in data transmission format, communication rate, reliability requirements, and adaptation scenarios.

[0004] In the smart factory scenario, the impact of this protocol diversity is particularly prominent. A modern production line usually integrates devices from multiple manufacturers: sensors in the raw material detection link may use the Modbus RTU protocol, PLC controllers in the production process often use the OPC UA protocol for data interaction, robot devices in the packaging link may use proprietary private protocols, and logistics scheduling systems rely on the MQTT protocol for transmission of scheduling instructions. These devices together form an organic whole of the production process, but due to differences in communication protocols, they form a "data island". For example, in the smart factory of an automobile parts manufacturing enterprise, the temperature sensor in the welding workshop and the humidity sensor in the painting workshop use different protocols, which makes it impossible to real-time aggregate and analyze the production environment data, affecting the dynamic optimization of process parameters; in the equipment maintenance link, it is difficult to uniformly collect device fault data of different protocols, making it impossible for the predictive maintenance system to fully obtain device state information, increasing the risk of device downtime.

[0005] The diversity of protocols presents a more complex challenge in smart city construction. Smart cities encompass multiple sectors, including transportation, environmental protection, energy, and security, with a wide variety of connected devices: cameras, traffic light controllers, and ETC devices in the transportation sector; air quality monitors, water quality sensors, and noise detectors in the environmental sector; smart meters, street light controllers, and charging piles in the energy sector; and video surveillance equipment, access control systems, and alarm devices in the security sector. Each type of device may employ different communication protocols. In one city's smart transportation development, the use of different protocols by traffic monitoring equipment in different areas prevented real-time sharing of traffic flow data, leading to delays in cross-regional traffic management instructions and impacting traffic efficiency.

[0006] Beyond smart factories and smart cities, protocol diversity is a common issue in other IoT scenarios. In smart homes, appliances like air conditioners, refrigerators, and televisions come from different brands and use their own proprietary communication protocols, requiring users to control different devices through multiple apps, hindering unified management of the entire house. In smart agriculture, protocol differences between soil moisture sensors, irrigation controllers, and temperature and humidity monitoring devices result in inconsistent data collection from farmland environments, impacting the implementation of automated control functions such as precision irrigation and intelligent ventilation.

[0007] In summary, the protocol diversity issues arising from the massive influx of heterogeneous devices, coupled with the limitations of existing IoT platforms in protocol adaptation, updates, maintenance, and technical architecture, result in insufficient device access flexibility and high maintenance costs, becoming a key bottleneck restricting the large-scale development of the IoT industry. Especially in scenarios with frequent additions of new device types and continuous protocol iterations, traditional solutions are no longer sufficient to meet actual needs. Therefore, it is urgent to explore new technological paths and solutions to overcome existing technological bottlenecks, improve the heterogeneous device access capabilities and protocol adaptation efficiency of IoT platforms, and provide strong support for the high-quality development of the IoT industry. Summary of the Invention

[0008] To address one of the aforementioned problems, the main objective of this application is to propose a method and related equipment for processing multi-source protocol components in the Internet of Things (IoT), aiming to improve the heterogeneous device access capability and protocol adaptation efficiency of the IoT platform.

[0009] To achieve the above objectives, one aspect of this application proposes a method for processing multi-source protocol components in the Internet of Things (IoT), the method comprising: Obtain the protocol document, determine standardized document data based on the protocol document, and extract structured information based on the standardized document data; Based on the structured information and IoT platform interface specifications, standard protocol parsing classes and supporting resources are generated to generate protocol components; Load and register the protocol components to form a protocol buffer pool.

[0010] In some embodiments, determining standardized document data based on the protocol document includes: The text content of the protocol document is extracted, the text content is structured, and it is classified and organized according to preset dimensions to form standardized document data.

[0011] In some embodiments, the extraction of structured information from the standardized document data includes: The standardized document data is input into a large language model to extract key protocol information; Structured information is determined based on the key information of the protocol.

[0012] In some embodiments, the protocol component is loaded via the following method: Based on the protocol component, identify the protocol type and search the protocol buffer pool to see if the protocol type exists. If the protocol type exists in the protocol buffer pool, the protocol type existing in the protocol buffer pool shall be reused; If the protocol type is not present in the protocol buffer pool or the protocol version is updated, load the protocol type.

[0013] In some embodiments, loading the protocol type includes: Create a separate thread to load and initialize the protocol type; If the protocol type is an updated version, the old version protocol is used to process the current request, and the updated version protocol is used to process the next request.

[0014] In some embodiments, the method further includes: During the loading of the protocol component, a read-write lock mechanism is adopted, with read operations executed in parallel and write operations executed independently.

[0015] In some embodiments, the method further includes: Receive network requests from devices and determine the device protocol based on the port and message information of the network requests; The device protocol is matched from the protocol buffer pool, and the network request is processed according to the matched protocol.

[0016] To achieve the above objectives, another aspect of this application provides an IoT multi-source protocol component processing apparatus, the apparatus comprising: The first module is used to acquire the protocol document, determine standardized document data based on the protocol document, and extract structured information based on the standardized document data. The second module is used to generate standard protocol parsing classes and supporting resources based on the structured information and IoT platform interface specifications, so as to generate protocol components; The third module is used to load and register the protocol components to form a protocol buffer pool.

[0017] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the methods described above.

[0018] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0019] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the methods described above.

[0020] The embodiments of this application include at least the following beneficial effects: This application provides a method for processing multi-source protocol components in the Internet of Things (IoT). This method obtains protocol documents, determines standardized document data based on the protocol documents, extracts structured information based on the standardized document data, generates standard protocol parsing classes and supporting resources based on the structured information and IoT platform interface specifications to generate protocol components, loads and registers the protocol components, forms a protocol buffer pool, parses the protocol documents of multi-source protocols and automatically generates protocol components in combination with IoT platform interface specifications, and completes the loading and registration of protocol components without manual adaptation, thereby improving the heterogeneous device access capability and protocol adaptation efficiency of the IoT platform. Attached Figure Description

[0021] Figure 1 This is a flowchart of the IoT multi-source protocol component processing method provided in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the IoT multi-source protocol component processing device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0023] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0024] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0025] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0026] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0027] Protocol Components: Independent functional modules that encapsulate the parsing logic of specific device communication protocols, including core capabilities such as data encoding and decoding, command interaction, and format conversion.

[0028] Atomic hot update: Under the premise of no system restart and no business interruption, the protocol components can be fully loaded, replaced or unloaded. The update process is atomic and avoids intermediate state anomalies.

[0029] Class cache pool: A memory pool that stores parsed protocol component class files. By caching and reusing the files, it avoids repeated loading and parsing, thus improving the efficiency of component startup.

[0030] Protocol document: A file that records the device communication protocol specifications, including core information such as data frame format, field definitions, interaction flow, and error codes.

[0031] No coding required: No need to manually write protocol parsing code; automated tools generate ready-to-run protocol components, quickly completing device access adaptation.

[0032] Protocol Loader: Breaking through the limitations of traditional single-source loading, it fully supports multi-source protocol access, including local files, remote URL retrieval, and JAR package import. It features a built-in intelligent recognition mechanism that automatically adapts to the parsing rules of different source protocols. Combined with a cache pool, it avoids resource waste caused by repeated parsing and improves loading response speed.

[0033] The protocol hot-update engine (HotSwap Engine) is built on Java class isolation technology and reflection mechanisms to achieve atomic replacement of protocol components. Through module decoupling design, it ensures uninterrupted service and no data loss during the update process, adapting to the stability requirements of high-concurrency access scenarios.

[0034] Protocol Cache Pool: This pool is specifically designed to cache the bytecode data and structure definition information of loaded protocol classes, establishing an index mapping mechanism. When the same protocol is accessed again, resources are retrieved directly from the cache pool, eliminating the need to repeat the parsing process and significantly improving the efficiency of repeated loading.

[0035] Protocol Generator: Deeply integrates semantic understanding and code generation capabilities from large-scale models, enabling accurate parsing of diverse protocol documents. It automatically extracts core technical parameters and generates directly deployable protocol parsing components, achieving code-free adaptation.

[0036] Protocol Registry: As the core of protocol lifecycle management, it uniformly stores metadata such as the name, version, source, and loading time of loaded protocols. It monitors the protocol's operational status in real time, provides version tracking and status alerts, and supports the orderly management of protocols.

[0037] Device Gateway: Responsible for core functions such as device connection management, automatic protocol matching, and data forwarding and distribution. It has built-in multi-protocol adaptation interfaces, acting as a communication bridge between devices and the platform, ensuring real-time and reliable data transmission.

[0038] The limitations of related technologies are specifically manifested in the following ways: 1. Limited protocol loading channels and low resource efficiency. Traditional IoT platforms often rely on loading protocol components from local files: modules need to be manually packaged, deployed to servers, and integrated. While suitable for small LANs, this is insufficient for large-scale remote / distributed scenarios—such as cross-regional smart city platforms where servers are distributed across multiple locations. Maintenance personnel must deploy each node, resulting in cumbersome and error-prone operations and low protocol update efficiency. Furthermore, the lack of a caching mechanism leads to repeated component loading when multiple devices or devices using the same protocol connect repeatedly, wasting memory and CPU resources and reducing parsing efficiency and concurrency. For example, a logistics tracking platform experienced this issue: during peak periods with thousands of terminals connected, repeated component loading consumed over 40% of memory, tripled data latency, and impacted real-time tracking performance.

[0039] 2. The hot update mechanism is inadequate, lacking stability and continuity. As a key technology for ensuring uninterrupted system upgrades, most IoT platform protocol components still require a restart for updates, making true hot updates difficult to achieve. Some claimed-support solutions also have flaws: data transmission may stop due to parsing interruptions, data may be lost or corrupted, or performance may plummet or even crash under tens of thousands of concurrent devices. The root cause lies in the lack of resource isolation and data consistency guarantees: component switching is prone to chain breaks, and unprocessed data is difficult to save; improper resource allocation under high concurrency leads to queue congestion, causing data loss.

[0040] 3. High barrier to entry for protocol development, and lagging adaptation capabilities behind device iterations. Currently, IoT platform protocol adaptation relies on manual coding, requiring thorough reading of protocol documents, logical design, code writing, and extensive testing. This demands extremely high levels of programming skills and understanding of protocol principles, but such talent is scarce. The manual approach is time-consuming (1-2 weeks for entirely new proprietary protocols), has a high error rate (adapting to 30+ protocols on one platform averages 10 days with a 15% error rate), consumes core resources, and struggles to meet the high-frequency iteration demands of devices.

[0041] 4. Large-scale model technology has not been effectively implemented, and automated adaptation is lacking. Although large-scale models possess the ability to understand protocol documents and generate code, they are not deeply integrated with most platforms: some only extract keywords, some generate code with poor compatibility, and some lack integration mechanisms with the architecture. In complex proprietary protocol scenarios, models are prone to errors due to insufficient understanding of technical terms (the error rate exceeded 30% in one case), failing to overcome the bottleneck of manual development and fundamentally not improving adaptation efficiency.

[0042] 5. Poor system availability hinders scalability. Traditional platform protocol components are tightly coupled with the kernel, requiring restarts for updates, leading to device communication interruptions: factory monitoring malfunctions, security blind spots, and delayed medical diagnoses. Furthermore, the lack of compatibility testing makes new components prone to causing lag and crashes. Insufficient availability increases operational risks and restricts project implementation and scaling.

[0043] In view of this, this application provides a method for processing multi-source protocol components in the Internet of Things (IoT). This method obtains protocol documents, determines standardized document data based on the protocol documents, extracts structured information from the standardized document data, generates standard protocol parsing classes and supporting resources based on the structured information and IoT platform interface specifications to generate protocol components, loads and registers the protocol components, forms a protocol buffer pool, parses the protocol documents of multi-source protocols and automatically generates protocol components in combination with IoT platform interface specifications, and completes the loading and registration of protocol components without manual adaptation, thereby improving the heterogeneous device access capability and protocol adaptation efficiency of the IoT platform.

[0044] The IoT multi-source protocol component processing method provided in this application relates to the field of information technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited thereto. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the IoT multi-source protocol component processing method, but is not limited to the above forms.

[0045] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0046] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0047] Figure 1 This is an optional flowchart of an IoT multi-source protocol component processing method provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S101 to S103.

[0048] Step S101: Obtain the protocol document, determine the standardized document data based on the protocol document, and extract structured information based on the standardized document data; Step S102: Generate standard protocol parsing classes and supporting resources based on structured information and IoT platform interface specifications to generate protocol components; Step S103: Load and register the protocol components to form a protocol buffer pool.

[0049] The system acquires protocol documents from multiple sources uploaded by users, extracts the content of the protocol documents and forms standardized document data in a preset format, and extracts key information of the multiple sources protocols from the standardized document data to form structured information.

[0050] Based on the extracted structured information and combined with the IoT platform interface specifications, a standard protocol parsing class (supporting mainstream development languages ​​such as Java / Python) is automatically generated, including complete functions such as data parsing, format conversion, and validation logic. Simultaneously, a plugin description file (manifest.json), field mapping table, exception handling logic, test cases, and other supporting resources are generated. All files are packaged into a standard JAR file, forming a directly deployable protocol component.

[0051] A custom class loader (CustomClassLoader) is used to load newly generated protocol classes. Through a class loading isolation mechanism, naming or dependency conflicts with main system classes are avoided, ensuring the stability of core system functions. Protocol metadata, including protocol name, version number, source path, loading time, and compatible device type, is submitted to the protocol registry center to complete the formal registration of the protocol and incorporate it into the global management system.

[0052] Once the protocol loader detects a newly generated JAR package, it automatically triggers the loading process, completing component access and registration according to the multi-source protocol loading standard without manual intervention. The system has a built-in simulated message testing interface that automatically generates test messages that conform to the protocol specifications to perform functional verification on the newly loaded protocol components, verify the accuracy of data parsing and format compatibility, and generate a test report; if the test fails, it automatically triggers component rollback to ensure platform stability.

[0053] In some embodiments, determining standardized document data based on the protocol document includes: Step S201: Extract the text content of the protocol document, perform structured processing on the text content, and classify and organize it according to preset dimensions to form standardized document data.

[0054] The system supports users uploading protocol documentation in various formats such as PDF, Word, Excel, and TXT. It has a built-in document parsing engine that automatically extracts text content and removes redundant information (such as headers, footers, and irrelevant illustrations). The extracted text is then structured, categorized by dimensions such as "field definitions, data types, message structure, verification rules, and communication timing," forming standardized document data and providing a clear data source for subsequent parsing.

[0055] In some embodiments, extracting structured information from standardized document data includes: Step S301: Input the standardized document data into the large language model to extract key protocol information; Step S302: Determine the structured information based on the key information of the protocol.

[0056] By calling large language model interfaces (such as GPT-4, Tongyi Qianwen, etc.), structured document data is input into the model, and the prompt project guides the model to accurately understand the protocol technical specifications. Key protocol information is automatically extracted, including but not limited to field names, data length, encoding format, value range, message header structure, verification algorithm, request-response sequence, etc., generating a structured information list to ensure that no critical details are omitted.

[0057] In some embodiments, the protocol component is loaded using the following method: Step S401: Identify the protocol type based on the protocol component and search the protocol buffer pool to see if the protocol type exists; Step S402: If a protocol type exists in the protocol buffer pool, reuse the protocol type existing in the protocol buffer pool; Step S403: If the protocol buffer pool does not contain a protocol type or the protocol version has been updated, load the protocol type.

[0058] After receiving an access request, the protocol loader automatically identifies the protocol source type (local file, remote server, JAR package) and calls the corresponding parsing adapter. It queries the protocol cache pool. If the class definition of the protocol type already exists and the version is consistent, the cached resources in the protocol cache pool are directly reused without repeated parsing. If the protocol cache pool is not found or the version is updated, the protocol structure parsing process is initiated to generate a standard protocol class definition and synchronously write it to the cache pool archive.

[0059] In some embodiments, the loading protocol type includes: Step S501: Create a separate thread to load and initialize the protocol type; Step S502: If the protocol type is an updated version, process the current request using the old version protocol and then process the next request using the updated version protocol.

[0060] When the protocol registry detects a version update trigger signal, it notifies the hot update engine to initiate the replacement process. The new protocol class is loaded and initialized through an independent thread, ensuring that the initialization process does not affect the current business operation. After the new protocol class is loaded and ready, the device access request is smoothly routed to the new protocol instance through a reference switching mechanism: the old protocol instance keeps the current request processing until completion and is automatically recycled in the next cycle, achieving zero-interruption replacement.

[0061] In some embodiments, the IoT multi-source protocol component processing method further includes: In step S601, during the loading of the protocol component, a read-write lock mechanism is adopted, with read operations executed in parallel and write operations executed independently.

[0062] The entire process of protocol loading and updating adopts a read-write lock mechanism. Read operations (device data parsing) are executed in parallel, while write operations (protocol updates) are executed exclusively, avoiding data corruption or parsing failures caused by concurrent conflicts.

[0063] During hot replacement, the device access gateway maintains the device connection status, and unparsed data is temporarily stored in a buffer queue. Once the new protocol instance is ready, it will be processed first to ensure thread safety and data integrity in scenarios with tens of thousands of devices accessing the network concurrently.

[0064] In some embodiments, the IoT multi-source protocol component processing method further includes: Step S701: Receive the network request from the device and determine the device protocol based on the port and message information of the network request; Step S702: Match the device protocol from the protocol buffer pool and process the network request according to the matched protocol.

[0065] The device access process is as follows: When a device connects to the IoT platform, the device access gateway first receives the network request from the device, determines the device protocol based on the port and message information of the request, finds the corresponding protocol from the protocol cache pool, and routes the request to that protocol for processing.

[0066] Referring to Table 1, which records the performance parameters of the traditional solution and the solution of this application in various indicators, it can be seen from Table 1 that the solution of this application has significant improvements in terms of protocol switching time, new protocol adaptation cycle, amount of manual coding, system availability and supported protocol types.

[0067] Table 1

[0068] Please see Figure 2 This application also provides an IoT multi-source protocol component processing device that can implement the above-described method. The device includes: The first module is used to obtain the protocol document, determine the standardized document data based on the protocol document, and extract structured information based on the standardized document data. The second module is used to generate standard protocol parsing classes and supporting resources based on structured information and IoT platform interface specifications, in order to generate protocol components; The third module is used to load and register protocol components to form a protocol buffer pool.

[0069] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0070] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0071] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0072] Please see Figure 3 , Figure 3 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 301 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 302 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 302 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 302 and is called and executed by the processor 301 using the methods described above in the embodiments of this application. Input / output interface 303 is used to implement information input and output; The communication interface 304 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 305 transmits information between various components of the device (e.g., processor 301, memory 302, input / output interface 303, and communication interface 304); The processor 301, memory 302, input / output interface 303, and communication interface 304 are connected to each other within the device via bus 305.

[0073] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0074] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0075] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0076] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0077] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0078] The embodiments of this application include at least the following beneficial effects: At the protocol component loading level, this invention breaks through the limitation of traditional solutions that only support local file loading, constructing a multi-source access system that fully supports various access modes such as local file loading, remote cloud push, and JAR package import. This multi-channel adaptation capability can perfectly match the needs of different scenarios, such as centralized deployment of IoT cloud platforms and distributed deployment of edge computing nodes: for IoT systems within small local area networks, protocol components can be quickly loaded via local files; while the JAR package import mode provides a convenient path for customized protocol adaptation, meeting personalized needs in special scenarios. The design of the multi-source access mode significantly improves the flexibility and efficiency of protocol component deployment, solving the industry problem of inconvenient loading in traditional solutions under distributed architectures.

[0079] To address the core pain point of easily interrupted protocol updates, this invention employs an atomic hot update mechanism to achieve zero-interruption operation during protocol switching. The system decomposes various protocol components into independent atomic functional modules, each responsible for specific protocol parsing logic. Modules interact with each other through standardized interfaces. When updating the protocol version or adding a new protocol type, only the target atomic module needs to be replaced individually, without restarting the entire system. Simultaneously, the system has a built-in data cache queue. During module updates, real-time data uploaded by devices is temporarily stored. Once the new module is loaded and compatibility checks are completed, the cached data seamlessly integrates into the new parsing process, ensuring no data loss and uninterrupted service. Real-world testing has verified that this mechanism maintains a 100% data transmission success rate during protocol updates, with no significant fluctuations in system latency, perfectly supporting high-frequency access scenarios with extremely high continuity requirements, such as smart factory production lines and urban traffic monitoring.

[0080] Regarding the efficiency of adapting to new protocols, this invention deeply integrates the document parsing and code generation capabilities of a large-scale model, achieving automated conversion from protocol documents to parsing components, truly achieving code-free adaptation. Users only need to upload protocol documents in PDF, Word, or other formats, and the large-scale model can complete document parsing within minutes, automatically extracting core technical details such as data frame structure, field definitions, verification rules, and communication timing. Based on the interface specifications of the IoT platform, it generates a directly deployable parsing framework and plugins. This changes the traditional adaptation mode of manually analyzing documents and writing code, shortening the adaptation cycle of new protocols from days to weeks to minutes, significantly improving adaptation efficiency.

[0081] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0082] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0083] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0085] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0086] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0087] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0088] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0089] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0090] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0091] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for processing multi-source protocol components in the Internet of Things, characterized in that, The method includes the following steps: Obtain the protocol document, determine standardized document data based on the protocol document, and extract structured information based on the standardized document data; Based on the structured information and IoT platform interface specifications, standard protocol parsing classes and supporting resources are generated to generate protocol components; Load and register the protocol components to form a protocol buffer pool.

2. The method according to claim 1, characterized in that, The step of determining standardized document data based on the protocol document includes: The text content of the protocol document is extracted, the text content is structured, and it is classified and organized according to preset dimensions to form standardized document data.

3. The method according to claim 1, characterized in that, The step of extracting structured information from the standardized document data includes: The standardized document data is input into a large language model to extract key protocol information; Structured information is determined based on the key information of the protocol.

4. The method according to claim 1, characterized in that, The protocol component is loaded using the following method: Based on the protocol component, identify the protocol type and search the protocol buffer pool to see if the protocol type exists. If the protocol type exists in the protocol buffer pool, the protocol type existing in the protocol buffer pool shall be reused; If the protocol type is not present in the protocol buffer pool or the protocol version is updated, load the protocol type.

5. The method according to claim 4, characterized in that, Loading the protocol type includes: Create a separate thread to load and initialize the protocol type; If the protocol type is an updated version, the old version protocol is used to process the current request, and the updated version protocol is used to process the next request.

6. The method according to claim 1, characterized in that, The method further includes: During the loading of the protocol component, a read-write lock mechanism is adopted, with read operations executed in parallel and write operations executed independently.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Receive network requests from devices and determine the device protocol based on the port and message information of the network requests; The device protocol is matched from the protocol buffer pool, and the network request is processed according to the matched protocol.

8. An Internet of Things (IoT) multi-source protocol component processing device, characterized in that, The device includes: The first module is used to acquire the protocol document, determine standardized document data based on the protocol document, and extract structured information based on the standardized document data. The second module is used to generate standard protocol parsing classes and supporting resources based on the structured information and IoT platform interface specifications, so as to generate protocol components; The third module is used to load and register the protocol components to form a protocol buffer pool.

9. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images