Data acquisition method and fusion terminal of multi-contract stack dynamic loading and cross-stack routing

Abstract

The application provides a data acquisition method and a fusion terminal for dynamic loading of a multi-protocol stack and cross-stack routing, which comprises the following steps: obtaining a channel name and a protocol name of a communication device accessed by the fusion terminal; dynamically loading and instantiating corresponding channel components and protocol components through a registration loader to obtain channel objects and protocol objects; receiving and analyzing an uplink communication frame through the uplink channel objects and the uplink protocol objects to obtain routing information and real-time commands; determining a target downlink protocol object according to the routing information through a central router, and writing the real-time commands and a source protocol stack pointer into a command queue of the target downlink protocol object; processing the real-time commands through the target downlink protocol object and obtaining response data, and returning the response data to an uplink communication device through the uplink protocol objects and the uplink channel objects according to the source protocol stack pointer. The application realizes flexible loading of multiple communication protocols and efficient routing of real-time commands across protocol stacks.

Description

Technical Field

[0001] This application relates to the field of data acquisition and communication technology, specifically to a data acquisition method and fusion terminal for dynamic loading of multi-protocol stacks and cross-stack routing. Background Technology

[0002] In power consumption information acquisition systems, data concentrators need to read electricity meter data through various physical channels such as serial ports, carrier waves, low-power wireless, and Ethernet, according to multiple communication protocols including DL / T 645, DL / T 698.45, and IEC 62056 DLMS / COSEM. Simultaneously, they need to communicate uplink with the master station according to the master station protocol and support transparent forwarding commands such as real-time meter reading issued by the master station. Currently, data concentrators often require field upgrades after deployment for new meter types or protocols. However, in existing data acquisition solutions, communication protocols are tightly coupled with transmission channels and operating systems, resulting in poor system scalability and low resource utilization. Therefore, how to achieve flexible loading of multiple communication protocols and efficient routing of real-time commands across protocol stacks has become a pressing technical problem to be solved in this field. Summary of the Invention

[0003] This application provides a data acquisition method and fusion terminal for dynamic loading of multi-protocol stacks and cross-stack routing, which can improve the efficiency and reliability of multi-protocol data acquisition.

[0004] In a first aspect, embodiments of this application provide a data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing, including: Obtain the configuration information of the converged terminal, which includes the channel name and protocol name bound to each of the multiple communication devices connected to the converged terminal; the communication devices include uplink communication devices and downlink communication devices; The channel component corresponding to the channel name and the protocol component corresponding to the protocol name are dynamically loaded by the registration loader, and the channel component and the protocol component are instantiated respectively to obtain the channel object and the protocol object; wherein, the channel object includes the uplink channel object and the downlink channel object, and the protocol object includes the uplink protocol object and the downlink protocol object; The communication frames sent by the target uplink communication device are received by the uplink channel object bound to the target uplink communication device, and the communication frames are parsed by the uplink protocol object bound to the uplink channel object to obtain routing information and real-time commands. The central router determines the target downlink protocol object based on the routing information and writes the source protocol stack pointer, which carries real-time commands and points to the uplink protocol object, into the command queue of the target downlink protocol object. Real-time commands are processed through the target downlink protocol object, response data is obtained from the downlink channel object bound to the target downlink protocol object, and the response data is sent back to the target uplink communication device via the uplink protocol object and the uplink channel object according to the source protocol stack pointer.

[0005] Secondly, embodiments of this application provide a converged terminal, including a memory and a processor; the memory is used to store a computer program; the processor is used to execute the computer program to implement the steps of the above-described data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing.

[0006] This application's embodiments achieve decoupling of protocols from transmission and operating systems through an abstract channel layer and an abstract protocol layer, enabling the same protocol component to run on any channel component; it achieves on-demand lazy loading and incremental upgrades at the field module level through a registration loader, avoiding full loading and reducing storage and memory usage of resource-constrained terminals; it achieves operating system-independent data transport and protocol processing through a byte scheduler; and it achieves real-time asynchronous command routing and response closed-loop across heterogeneous protocol stacks through a central router and source protocol stack pointers, eliminating the need to hard-code routing logic for each pair of uplink and downlink protocol combinations, thereby improving the scalability, resource utilization, efficiency, and reliability of multi-protocol data acquisition. Attached Figure Description

[0007] Figure 1 A flowchart illustrating a data acquisition method for dynamic loading of multi-revision stacks and cross-stack routing provided in an embodiment of this application; Figure 2 for Figure 1 A flowchart of step S102; Figure 3 for Figure 2 A flowchart of step S202; Figure 4 for Figure 3 A flowchart of step S301; Figure 5 A schematic diagram of the data acquisition device for dynamic loading of multi-protocol stacks and cross-stack routing provided in an embodiment of this application; Figure 6 A schematic diagram of the structure of the converged terminal provided in this application. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0009] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0010] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0011] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0012] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0013] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

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

[0015] This application provides a data acquisition method for dynamic loading of multiple protocol stacks and cross-stack routing, which can be applied to converged terminals. The converged terminal can be a power data concentrator, acquisition terminal, IoT data gateway, industrial data acquisition gateway, etc. At the software level, the converged terminal includes an abstract channel layer, an abstract protocol layer, a byte scheduler, a registration loader, and a central router. The descriptions of each part are as follows: The abstract channel layer is used to define a unified abstract channel interface and shield specific transmission differences. Each physical transmission method is implemented as an independent, loadable channel component. Each channel component implements and conforms to this abstract channel interface. The abstract channel interface includes interface methods such as channel status query, channel opening, channel closing, channel data reading, and channel data writing. This allows the byte scheduler to access the channel object only through the abstract channel interface without being aware of the underlying physical transmission, thus achieving shielding of transmission differences and unified access.

[0016] The abstract protocol layer is used to define a unified protocol stack abstract interface. Each communication protocol is implemented as an independent, loadable protocol component. Each protocol component implements and conforms to this protocol stack abstract interface. Protocol objects only perform read and write operations on the read buffer and write buffer, without directly accessing the transport interface or operating system interface. This protocol stack abstract interface includes interface methods such as protocol status query, protocol open, protocol close, idle status query, protocol processing driver, and copy task dispatch, realizing the decoupling of protocol from transport and protocol from the operating system.

[0017] The byte scheduler is a general-purpose loop processing unit used to move bytes between the read and write buffers of channel objects and protocol objects, and to drive the protocol objects to perform protocol processing. The byte scheduler accesses channel objects through an abstract channel interface and protocol objects through a protocol stack abstract interface. It reads data from the channel object and writes it to the read buffer of the protocol object, drives the protocol object to read data from the read buffer and perform protocol processing, writes the data to be sent to the write buffer, and then writes the data from the write buffer back to the channel object. The byte scheduler makes the channel object and protocol object unaware of each other's specific types, achieving operating system-independent data movement and protocol processing.

[0018] The registry loader is used to dynamically load channel components or specification components by name, obtain the corresponding creation function pointers for the components, and instantiate objects. The registry loader reads the names registered in the configuration source, loads the corresponding channel components or specification components lazily on demand according to preset naming conventions, parses the creation functions exported according to the conventions, and caches the mapping relationship between names and creation function pointers in the mapping table. The registry loader also selects either dynamic link library loading or global static registry loading based on the runtime environment to achieve on-demand lazy loading of operating system-independent components.

[0019] The central router provides a common real-time command routing function between multiple independently loaded protocol objects running in different threads. The central router receives routing information parsed from the uplink protocol object, determines the target downlink protocol object based on this information, and writes a source protocol stack pointer carrying the real-time command and a pointer to the uplink protocol object into the command queue of the target downlink protocol object. This allows the target downlink protocol object to send response data back to the uplink protocol object based on the source protocol stack pointer, thus achieving asynchronous real-time command routing and response closure across protocol stacks.

[0020] The converged terminal performs dynamic loading through a registration loader, data transport and protocol processing through a byte scheduler, and cross-stack real-time command routing through a central router.

[0021] The data acquisition method for dynamic loading of multi-representation stacks and cross-stack routing provided in this application embodiment will be described in detail below with reference to the accompanying drawings.

[0022] like Figure 1 As shown in the figure, this application provides a data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing, the method including: S101: Obtain the configuration information of the converged terminal. The configuration information includes the channel name and protocol name bound to each of the multiple communication devices connected to the converged terminal. The communication devices include uplink communication devices and downlink communication devices. S102: Dynamically load the channel component corresponding to the channel name and the protocol component corresponding to the protocol name through the registration loader, and instantiate the channel component and the protocol component respectively to obtain the channel object and the protocol object; wherein, the channel object includes the uplink channel object and the downlink channel object, and the protocol object includes the uplink protocol object and the downlink protocol object; S103: Receive communication frames sent by the target uplink communication device through the uplink channel object bound to the target uplink communication device, and parse the communication frames by the uplink protocol object bound to the uplink channel object to obtain routing information and real-time commands; S104: The central router determines the target downlink protocol object based on the routing information and writes the source protocol stack pointer carrying the real-time command and pointing to the uplink protocol object into the command queue of the target downlink protocol object; S105: Process real-time commands through the target downlink protocol object, obtain response data from the downlink channel object bound to the target downlink protocol object, and transmit the response data back to the target uplink communication device through the uplink protocol object and the uplink channel object according to the source protocol stack pointer.

[0023] The configuration information refers to the information describing the channel names and protocol names bound to each communication device connected to the converged terminal. Communication devices include uplink and downlink communication devices. Uplink communication devices are those that communicate with the converged terminal upstream, such as master stations, cloud platforms, and data centers. Downlink communication devices are those that communicate with the converged terminal downstream, such as electricity meters, sensors, actuators, and smart meters. The channel name refers to the name of the physical or logical transmission channel bound to the communication device, such as serial port, TCP client, TCP server, carrier wave, and low-power wireless. The protocol name refers to the name of the communication protocol bound to the communication device, such as DL / T 645, DL / T 698.45, IEC62056 DLMS / COSEM, power load control protocol, and IEC104 protocol.

[0024] As an example, in step S101, after the converged terminal powers on, it reads configuration information from the configuration source. The configuration source can be a database or configuration file inside the converged terminal. The configuration information includes a device table, which records the binding relationship of each communication device connected to the converged terminal. Each device record includes the device name, channel name, and protocol name, and identifies the communication device as an uplink or downlink communication device. After reading the device table, the converged terminal can obtain the channel name and protocol name bound to each communication device. For example, if the converged terminal is a power data concentrator, its connected uplink communication device is the master station, and its downlink communication device is the electricity meter. The uplink device record in the device table is the device name "Master Station", the channel name "TCPClient", and the protocol name "IEC104"; the downlink device record is the device name "Electricity Meter 1", the channel name "SerialChannel", and the protocol name "DL / T 645". Therefore, the concentrator communicates upstream with the master station through the TCP client channel, using the IEC104 protocol; and communicates downstream with the energy meter through the serial port channel, using the DL / T645 protocol.

[0025] Furthermore, the converged terminal can also obtain communication parameters from the configuration information, such as serial port baud rate, TCP port number, target IP address, meter address, and communication timeout, and pass them as initialization parameters when instantiating the channel component or protocol component. The specific fields and storage format of the configuration information can be set according to actual deployment requirements.

[0026] In this context, the registration loader refers to a software component in the converged terminal used to load channel components or protocol components by name. A channel component is a loadable module that implements a unified abstract channel interface; each physical transmission method is implemented as one channel component. A protocol component is a loadable module that implements a unified protocol stack abstract interface; each communication protocol is implemented as one protocol component. A channel object is an object obtained after instantiating a channel component, and a protocol object is an object obtained after instantiating a protocol component. Uplink channel objects and uplink protocol objects are objects obtained after instantiating the channel components and protocol components corresponding to the uplink communication devices, respectively; downlink channel objects and downlink protocol objects are objects obtained after instantiating the channel components and protocol components corresponding to the downlink communication devices, respectively. Dynamic loading refers to the process of obtaining the creation function pointer corresponding to the component and completing object instantiation during the runtime phase based on the configuration information requirements.

[0027] As an example, in step S102, the converged terminal, based on the channel name and protocol name bound to each device record in the configuration information, determines the channel component corresponding to the channel name and the protocol component corresponding to the protocol name according to a preset naming convention using a registration loader. The converged terminal then uses the registration loader to call the creation interface provided by the channel component to instantiate the channel component, obtaining a channel object, and calls the creation interface provided by the protocol component to instantiate the protocol component, obtaining a protocol object. For example, in the configuration information, an uplink device record is bound to the channel name "TCPClient" and the protocol name "IEC104," and a downlink device record is bound to the channel name "SerialChannel" and the protocol name "DL / T645." The converged terminal, using the registration loader according to the preset naming convention, determines the corresponding TCP client channel component based on the channel name "TCPClient," the corresponding IEC104 protocol component based on the protocol name "IEC104," the corresponding serial port channel component based on the channel name "SerialChannel," and the corresponding DL / T645 protocol component based on the protocol name "DL / T 645." The converged terminal instantiates the aforementioned components by calling the creation interface provided by the registration loader, thereby obtaining the uplink channel object, uplink protocol object, downlink channel object, and downlink protocol object.

[0028] It should be noted that, in this embodiment, a communication device record binds a set of channel names and protocol names, corresponding to the instantiation of a pair of channel objects and protocol objects. Specifically, the uplink channel object and uplink protocol object corresponding to the uplink communication device are paired, and the communication frames received by the uplink channel object are parsed by the uplink protocol object bound to the same device. Similarly, the downlink channel object and downlink protocol object corresponding to the downlink communication device are paired, and the downlink protocol object sends and receives messages via the downlink channel object bound to the same device. The channel objects and protocol objects of different communication devices are independent of each other.

[0029] In this context, the target uplink communication device refers to the uplink communication device currently sending communication frames to the converged terminal. A communication frame is a communication data unit sent from the target uplink communication device to the converged terminal. Routing information refers to information used to determine the target of real-time commands. A real-time command is a command sent by the target uplink communication device requesting real-time forwarding to the downlink communication device, such as a real-time data collection command or a transparent forwarding command.

[0030] As an example, in step S103, the converged terminal receives a communication frame sent by the target uplink communication device through the uplink channel object bound to the target uplink communication device. The uplink protocol object bound to the uplink channel object then parses the communication frame to obtain routing information and real-time commands. Specifically, the converged terminal receives the communication frame sent by the target uplink communication device through the uplink channel object and provides it to the uplink protocol object. The uplink protocol object parses the communication frame according to its bound uplink protocol, extracting routing information and real-time commands from the communication frame. For example, if the target uplink communication device is the master station, and the master station sends a communication frame containing a real-time data collection command, after the converged terminal receives the communication frame through the uplink channel object, the uplink protocol object parses the communication frame to obtain routing information and the real-time data collection command.

[0031] In this context, the central router refers to the software component in the converged terminal used to route real-time commands among multiple independently loaded protocol objects. The target downlink protocol object is the downlink protocol object determined by the central router based on routing information; that is, the downlink protocol object used to process the real-time command. The source protocol stack pointer is an in-process local instance pointer of the uplink protocol object, provided to the central router by the uplink protocol object that parses the communication frame. It is used to send response data back to the uplink protocol object after the target downlink protocol object receives the response data. The command queue is a queue set up in the protocol object to cache commands awaiting processing.

[0032] As an example, in step S104, the converged terminal determines the target downlink protocol object based on routing information through the central router, and writes the source protocol stack pointer carrying the real-time command and pointing to the uplink protocol object into the command queue of the target downlink protocol object. For example, the target uplink communication device is the master station, the downlink communication device is the electricity meter, and the real-time command is a real-time meter reading command for the target electricity meter. The converged terminal determines the target downlink protocol object for processing the real-time meter reading command through the central router based on routing information, and writes the real-time meter reading command and the source protocol stack pointer pointing to the uplink protocol object into the command queue of the target downlink protocol object. The uplink protocol object uses the IEC104 protocol, and the target downlink protocol object uses the DL / T645 protocol. It should be noted that the protocols bound to the uplink protocol object and the downlink protocol object can be the same or different; the central router can route the real-time command and transmit the response back between them based on routing information.

[0033] Response data refers to the data returned by the downlink communication equipment in response to real-time commands. For example, the electricity meter returns measurement data such as electricity consumption readings, voltage and current values ​​in response to real-time meter reading commands.

[0034] As an example, in step S105, the converged terminal processes the real-time command through the target downlink protocol object, obtains response data from the downlink channel object, and sends the response data back to the target uplink communication device via the uplink protocol object and the uplink channel object according to the source protocol stack pointer. Specifically, after retrieving the real-time command, the target downlink protocol object encodes the real-time command according to its bound downlink protocol and sends it to the downlink communication device through the downlink channel object; the target downlink protocol object receives the data returned by the downlink communication device through the downlink channel object, processes the data according to the protocol, and obtains the response data; the target downlink protocol object sends the response data back to the uplink protocol object according to the source protocol stack pointer; the uplink protocol object encapsulates the response data according to the uplink protocol and sends it to the target uplink communication device through the uplink channel object. For example, the target uplink communication device is the master station, the downlink communication device is the electricity meter, and the real-time command is the real-time meter reading command for the target electricity meter. The converged terminal encodes the real-time meter reading command according to the DL / T645 protocol through the target downlink protocol object and sends it to the target energy meter through the downlink channel object. After the target energy meter returns measurement data such as the energy reading, the converged terminal processes the data through the target downlink protocol object to obtain response data. The target downlink protocol object sends the response data back to the uplink protocol object according to the source protocol stack pointer. The uplink protocol object is encapsulated according to the IEC104 protocol and sent to the master station through the uplink channel object to complete the closed-loop processing of the real-time command.

[0035] Using the methods described above, the converged terminal achieves dynamic loading of multiple protocol stacks and real-time command routing across stacks. Since channel components and protocol components are dynamically loaded and instantiated through a registry loader, when adding or modifying communication protocols, only the corresponding component needs to be provided and the configuration information updated, improving the system's flexibility and maintainability. Simultaneously, by using source protocol stack pointers to achieve asynchronous backhaul of response data from the target downlink protocol object to the uplink protocol object, it ensures correct matching of commands and responses from different uplinks in multi-protocol concurrent scenarios, guaranteeing the real-time performance and accuracy of data acquisition.

[0036] In one embodiment, the channel component implements the abstract channel interface, and the protocol component implements the protocol stack abstract interface; the protocol object only performs read and write operations on the read buffer and write buffer, and does not directly access the abstract channel interface, the transport interface or the operating system interface.

[0037] As an example, in the converged terminal, the serial port channel component, TCP client channel component, and carrier channel component all implement an abstract channel interface. This abstract channel interface includes interface methods such as channel status query, channel opening, channel closing, channel data reading, and channel data writing. The DL / T 645 protocol component, IEC 104 protocol component, and DL / T 698.45 protocol component all implement a protocol stack abstract interface. This protocol stack abstract interface includes interface methods such as protocol status query, protocol opening, protocol closing, idle status query, protocol processing driver, and copy task dispatch. After the converged terminal loads and instantiates the above components through the registration loader, the resulting protocol object only performs read and write operations on the read buffer and write buffer. The byte scheduler accesses the channel object through the abstract channel interface and the protocol object through the protocol stack abstract interface. The protocol object does not directly call operating system interfaces such as serial ports, sockets, and timers, nor is it aware of whether the underlying system is a serial port, TCP, or carrier.

[0038] In this embodiment, specific transmission differences are shielded by an abstract channel interface, and a unified protocol component is established through a protocol stack abstract interface. The protocol object only interacts with the read buffer and write buffer. The byte scheduler accesses the channel object through the abstract channel interface and the protocol object through the protocol stack abstract interface, thereby achieving decoupling between the protocol and transmission, and between the protocol and the operating system. This allows the same protocol component to run on any channel component, and the same channel component to serve any protocol component. It also facilitates the reuse of protocol stack code across operating systems and even bare-metal platforms.

[0039] In one embodiment, such as Figure 2 As shown, step S102, which involves dynamically loading the channel component corresponding to the channel name and the specification component corresponding to the specification name through the registration loader, includes: S201: For each name in the channel name and protocol name, query the mapping table maintained by the registry loader to see if there is a creation function pointer corresponding to the name; the mapping table is used to store the correspondence between names and creation function pointers; S202: If the creation function pointer corresponding to the name does not exist in the mapping table, then obtain the creation function pointer corresponding to the name and store the name and the obtained creation function pointer in the mapping table; where, when the name is a channel name, the component corresponding to the name is a channel component; when the name is a specification name, the component corresponding to the name is a specification component. S203: If a creation function pointer corresponding to the name already exists in the mapping table, then the creation function pointer is reused directly.

[0040] The mapping table is a data structure maintained internally by the registry loader to store the correspondence between names and creation function pointers. A creation function pointer is a pointer to a creation function exported by a component according to its conventions. The creation function exported by a component according to its conventions refers to the entry point function exposed by the component, used to create and return the object corresponding to that component. When the name is a channel name, the component corresponding to that name is a channel component; when the name is a specification name, the component corresponding to that name is a specification component.

[0041] As an example, in step S201, the converged terminal queries the mapping table one by one for the channel name and protocol name bound to each device record in the configuration information, using the registration loader, to see if there is a creation function pointer corresponding to that name. For example, if the configuration information includes the channel name "TCPClient" and the protocol name "IEC 104", the converged terminal queries the mapping table one by one to see if there is a creation function pointer corresponding to "TCPClient" and if there is a creation function pointer corresponding to "IEC104".

[0042] As an example, in step S202, if the mapping table does not contain a creation function pointer corresponding to the name, the converged terminal obtains the creation function pointer corresponding to the name through the registration loader and stores the name and the creation function pointer in the mapping table. For example, if the mapping table does not contain a creation function pointer corresponding to the channel name "TCPClient", the converged terminal obtains the creation function pointer corresponding to the channel name "TCPClient" through the registration loader and stores "TCPClient" and the creation function pointer in the mapping table; if the mapping table does not contain a creation function pointer corresponding to the protocol name "IEC 104", the converged terminal obtains the creation function pointer corresponding to the protocol name "IEC 104" through the registration loader and stores "IEC 104" and the creation function pointer in the mapping table.

[0043] As an example, in step S203, if a creation function pointer corresponding to the name already exists in the mapping table, the fusion terminal directly reuses the creation function pointer through the registration loader, without repeatedly obtaining the creation function pointer corresponding to the name. For example, if a creation function pointer corresponding to the specification name "DL / T 645" already exists in the mapping table, the fusion terminal directly reuses the creation function pointer through the registration loader to instantiate the DL / T 645 specification component.

[0044] In this embodiment, a mapping table stores the correspondence between names and creation function pointers. This allows the registration loader to retrieve the creation function pointer corresponding to a name only when it first needs to use the component with that name. Subsequent uses of the same component with the same name directly reuse the cached creation function pointer in the mapping table, eliminating the need for repeated retrieval. Therefore, the converged terminal only loads the channel components and protocol components actually used in the field, avoiding full loading, reducing the storage and memory consumption of resource-constrained converged terminals, and improving component loading efficiency.

[0045] In one embodiment, such as Figure 3 As shown, in step S202, obtaining the creation function pointer corresponding to the name includes: S301: If the fusion terminal is running in the first runtime environment that supports dynamic link libraries, the registration loader loads the component corresponding to the name through the dynamic loading interface, and parses the creation function exported by the component according to the convention to obtain the creation function pointer corresponding to the name; S302: If the converged terminal is running in a second runtime environment that does not support dynamic link libraries, the registry loader queries the global static registry based on the name to obtain the creation function pointer corresponding to the name; wherein, the global static registry is obtained by the component corresponding to the name registering the name and the creation function pointer during the initialization of the converged terminal.

[0046] The primary runtime environment refers to the operating system environment that supports dynamic link libraries, such as Linux or Windows. The dynamic loading interface refers to the interface provided by the operating system for loading dynamic libraries.

[0047] As an example, in step S301, if the converged terminal is running in a first runtime environment that supports dynamic link libraries, the converged terminal loads the component corresponding to the name using the dynamic loading interface through the registry loader, and parses the creation functions exported by the component according to the convention. For example, on a Linux operating system, the converged terminal loads the component file using dlopen through the registry loader, and parses the creation functions exported by the component according to the convention using dlsym to obtain the creation function pointer of the component; on a Windows operating system, the converged terminal loads the component file using LoadLibrary through the registry loader, and parses the creation functions exported by the component according to the convention using GetProcAddress to obtain the creation function pointer of the component. Thus, in a runtime environment that supports dynamic link libraries, the converged terminal can dynamically load components by name through the registry loader and obtain their creation function pointers.

[0048] The second runtime environment refers to an embedded runtime environment that does not support dynamic link libraries, such as RTOS or bare-metal platforms. The global static registry is a data structure formed by each component registering its name and creation function pointer to a global static table during the initialization phase of the converged terminal.

[0049] As an example, in step S302, if the converged terminal is running in a second runtime environment that does not support dynamic link libraries, the converged terminal queries the global static registry by name through the registration loader to obtain the creation function pointer corresponding to the name. For example, on an RTOS or bare-metal platform, during the initialization phase, each channel component and protocol component calls the registration interface to register its own name and creation function pointer to the global static registry; during the runtime phase, the converged terminal queries the global static registry by name through the registration loader to directly obtain the creation function pointer corresponding to the name, without needing to load component files through the dynamic loading interface. Therefore, even in a runtime environment that does not support dynamic link libraries, the converged terminal can still obtain the creation function pointer by name through the global static registry, achieving a component loading capability equivalent to the dynamic link library method.

[0050] In this embodiment, by adapting the component loading method to either a dynamic link library or a global static registry, the registry loader can achieve the equivalent capability of obtaining creation function pointers by name in different runtime environments. Therefore, the protocol stack code can be developed once and reused across different operating systems and even bare-metal platforms, achieving operating system-independent component loading and avoiding modifications to the core logic of the specification layer and byte scheduler due to operating system differences.

[0051] In one embodiment, such as Figure 4As shown, in step S301, if the fusion terminal is running in a first runtime environment that supports dynamic link libraries, the registration loader loads the component corresponding to the name through the dynamic loading interface and parses the creation functions exported by the component according to the convention, including: S401: According to the preset naming convention, the complete path of the component file corresponding to the name is assembled from the library root path, category identifier and name; S402: Load the component file corresponding to the full path through the platform loading interface to obtain the component handle; S403: Through the symbol resolution interface, the creation function exported by the component according to the convention is resolved from the component handle to obtain the creation function pointer corresponding to the name.

[0052] Here, the library root path refers to the root directory where the component files are stored. The category identifier is used to distinguish between channel components and protocol components; for example, the category identifier for a channel component is "channel," and the category identifier for a protocol component is "protocol." The default naming convention refers to the rules for constructing the complete path of the component file from the library root path, the category identifier, and the name.

[0053] As an example, in step S401, the fusion terminal uses the registration loader to assemble the complete path of the component file from the library root path, category identifier, and name according to a preset naming convention. For example, if the library root path is " / opt / fusion / lib", the category identifier is "protocol", and the name is "DL / T 645", then the complete path of the assembled component file is " / opt / fusion / lib / protocol / libDL / T 645.so"; if the category identifier is "channel" and the name is "SerialChannel", then the complete path of the assembled component file is " / opt / fusion / lib / channel / libSerialChannel.so".

[0054] The platform loading interface refers to the interface provided by the operating system for loading component files. The component handle is the handle returned after loading the component file, used for subsequent symbol resolution.

[0055] As an example, in step S402, the converged terminal loads the component file corresponding to the full path through the platform loading interface called by the registration loader, and obtains the component handle. For example, on the Linux operating system, the converged terminal loads the component file through dlopen called by the registration loader, and obtains the component handle; on the Windows operating system, the converged terminal loads the component file through LoadLibrary called by the registration loader, and obtains the component handle.

[0056] The symbol resolution interface refers to the interface that parses and derives symbols from component handles.

[0057] As an example, in step S403, the converged terminal calls the symbol resolution interface through the registry loader to parse the creation functions exported by the component according to the convention from the component handle, and obtains the creation function pointer corresponding to the name. For example, on the Linux operating system, the converged terminal calls dlsym through the registry loader to parse the creation functions exported by the component according to the convention from the component handle, and obtains the creation function pointer corresponding to the name; on the Windows operating system, the converged terminal calls GetProcAddress through the registry loader to parse the creation functions exported by the component according to the convention from the component handle, and obtains the creation function pointer corresponding to the name.

[0058] In this embodiment, by assembling the complete path of the component file according to the preset name, and obtaining the creation function pointer through the platform loading interface and symbol resolution interface, the registration loader does not need to know the internal implementation details of the component. It can locate the component file and complete the loading and resolution only through the agreed name and exported symbols, thereby decoupling the component from the loader and facilitating the addition or replacement of individual component files.

[0059] In existing technologies, protocol objects typically directly call operating system interfaces such as serial ports, sockets, and timers, which are tightly bound to specific transmission channels and difficult to reuse across operating systems. In this embodiment, the protocol object only performs read and write operations on the read buffer and write buffer, and does not directly access the abstract channel interface, transmission interface, or operating system interface; the byte scheduler accesses the channel object through the abstract channel interface and the protocol object through the protocol stack abstract interface, moving data between the channel object and the protocol object and driving the protocol state machine. Its scheduling loop does not involve specific protocol types or specific transmission types, and the only platform-related sleep call is isolated by platform adaptation macros. The byte scheduling process in the uplink and downlink directions is described below.

[0060] In one embodiment, communication frames sent by the target uplink communication device are received through an uplink channel object bound to the target uplink communication device, and the communication frames are parsed by an uplink protocol object bound to the uplink channel object to obtain routing information and real-time commands, including: The byte scheduler reads data from the uplink channel object and writes it into the read buffer of the uplink protocol object. It then drives the uplink protocol object to read data from the read buffer and perform protocol processing. The uplink protocol object parses the communication frames sent by the target uplink communication device to obtain routing information and real-time commands. Based on the source protocol stack pointer, the response data is transmitted back to the target uplink communication device via the uplink protocol object and the uplink channel object, including: The byte scheduler writes the data in the write buffer of the uplink protocol object to the uplink channel object, which then sends it to the target uplink communication device.

[0061] The byte scheduler is a general-purpose loop processing unit used to move bytes between the read and write buffers of the channel object and the reduction object, and to drive the reduction object to perform protocol processing. The read buffer is a buffer in the reduction object used to temporarily store data read from the channel object.

[0062] As an example, the converged terminal receives communication frames sent by the target uplink communication device through the uplink channel object bound to the target uplink communication device. For example, the target uplink communication device can be a master station, and the communication frame can be a communication frame for a real-time data collection command. The converged terminal reads the raw byte data corresponding to the communication frame from the uplink channel object through the byte scheduler and writes the read raw byte data into the read buffer of the uplink protocol object. The converged terminal drives the uplink protocol object to read data from the read buffer through the byte scheduler. The uplink protocol object performs protocol processing on the data in the read buffer according to its bound uplink protocol, parses out the communication frame sent by the target uplink communication device, and extracts routing information and real-time commands from the communication frame.

[0063] The write buffer refers to the buffer in the protocol object used to temporarily store data to be sent to the channel object.

[0064] As an example, the converged terminal transmits response data back to the target uplink communication device via the uplink protocol object through the uplink channel object. Specifically, the uplink protocol object writes the response data to be transmitted back into the write buffer; the converged terminal writes the data in the write buffer into the uplink channel object through the byte scheduler, and the uplink channel object sends it to the target uplink communication device.

[0065] In this embodiment, the fusion terminal uses a byte scheduler to move bytes between the uplink channel object and the uplink protocol object, so that the uplink channel object and the uplink protocol object are unaware of each other's specific types, thus achieving decoupling between transmission and protocol. At the same time, data interaction is completed through read buffer and write buffer, so that the uplink protocol object does not need to directly access the transmission interface, further achieving decoupling between protocol and transmission.

[0066] In one embodiment, processing real-time commands through a target downlink protocol object and obtaining response data from a downlink channel object bound to the target downlink protocol object includes: The data in the write buffer of the target downlink protocol object is written to the downlink channel object through the byte scheduler, and then sent to the downlink communication device by the downlink channel object. The byte scheduler reads the data returned by the downlink communication device from the downlink channel object and writes it into the read buffer of the target downlink protocol object. This drives the target downlink protocol object to read the data from the read buffer and perform protocol processing to obtain the response data.

[0067] As an example, the converged terminal processes real-time commands through a target downlink protocol object. The target downlink protocol object writes the real-time command data to be sent into a write buffer. The converged terminal, through a byte scheduler, writes the data in the write buffer into a downlink channel object, which then sends it to the downlink communication device. After the downlink communication device returns data, the converged terminal, through a byte scheduler, reads the data returned by the downlink communication device from the downlink channel object and writes it into the read buffer of the target downlink protocol object. This drives the target downlink protocol object to read data from the read buffer and perform protocol processing to obtain response data.

[0068] For example, the downlink communication device can be an electricity meter, the downlink channel object can be a serial port channel object, and the real-time command can be a real-time meter reading command for the target electricity meter. The converged terminal writes the real-time meter reading command data from the write buffer of the target downlink protocol object to the downlink channel object through the byte scheduler, and the downlink channel object sends it to the target electricity meter. After the target electricity meter returns measurement data such as the electricity reading, the converged terminal reads the measurement data from the downlink channel object through the byte scheduler, writes it to the read buffer of the target downlink protocol object, and drives the target downlink protocol object to process the protocol according to the DL / T 645 protocol to obtain the response data.

[0069] In this embodiment, the fusion terminal uses a byte scheduler to move bytes between the downlink channel object and the target downlink protocol object, so that the downlink channel object and the target downlink protocol object are unaware of each other's specific types, thus achieving decoupling between transmission and protocol. At the same time, data interaction is completed through read buffer and write buffer, so that the target downlink protocol object does not need to directly access the transmission interface, further achieving decoupling between protocol and transmission.

[0070] In one embodiment, before writing the data in the write buffer of the uplink protocol object to the uplink channel object via the byte scheduler, the data acquisition method for dynamic loading of the multi-representation stack and cross-stack routing further includes: Using the target downlink protocol object and the source protocol stack pointer, the response return interface of the uplink protocol object is called to return the response data to the uplink protocol object. The response data is encapsulated according to the uplink protocol and written to the write buffer of the uplink protocol object.

[0071] As an example, the converged terminal, through the target downlink protocol object, calls the response feedback interface of the uplink protocol object according to the source protocol stack pointer, and sends the response data back to the uplink protocol object. Specifically, after the target downlink protocol object receives the response data returned by the downlink communication device, it determines the uplink protocol object according to the source protocol stack pointer, and calls the response feedback interface provided by the uplink protocol object, passing the response data as the input parameter of the response feedback interface, thereby sending the response data back to the uplink protocol object. For example, the target uplink communication device is the master station, the downlink communication device is the electricity meter, and the real-time command is the real-time meter reading command for the target electricity meter; after the target downlink protocol object receives the response data such as the electricity reading returned by the target electricity meter, it determines the uplink protocol object according to the source protocol stack pointer, and calls the response feedback interface provided by the uplink protocol object, sending the response data such as the electricity reading back to the uplink protocol object.

[0072] As an example, the converged terminal encapsulates the response data according to the uplink protocol using the uplink protocol object and writes it to the write buffer of the uplink protocol object. Subsequently, the converged terminal writes the data in the write buffer to the uplink channel object through the byte scheduler, and the uplink channel object sends it to the target uplink communication device. Specifically, after receiving the response data returned by the target downlink protocol object, the uplink protocol object encapsulates the response data according to its bound uplink protocol and writes the encapsulated response data to the write buffer. The converged terminal writes the data in the write buffer to the uplink channel object through the byte scheduler, and the uplink channel object sends it to the target uplink communication device. For example, the target uplink communication device is the master station, and the uplink protocol object adopts the IEC 104 protocol. The uplink protocol object encapsulates the response data according to the IEC 104 protocol and writes it to the write buffer. The byte scheduler writes the data in the write buffer to the uplink channel object, and the uplink channel object sends it to the master station.

[0073] In this embodiment, the asynchronous backhaul of response data from the target downlink protocol object to the uplink protocol object is achieved through the source protocol stack pointer. This eliminates the need for the target downlink protocol object to know the specific type of the uplink protocol object or the specific implementation of the uplink protocol. The uplink protocol object encapsulates the response data according to its bound uplink protocol and writes it into the write buffer. The byte scheduler then sends the data to the target uplink communication device via the uplink channel object, thus achieving cross-protocol stack response backhaul. The backhaul process is independent of the specific protocol and can be reused for any combination of uplink and downlink protocols.

[0074] In one embodiment, the routing information includes the identifier of the target downlink communication device; The central router determines the target downlink protocol object based on routing information, including: The central router locates the target downlink communication device among the downlink communication devices based on the target downlink communication device identifier, and determines the target downlink protocol object carrying the target downlink communication device.

[0075] Among them, the target downlink communication device identifier refers to the identifier used to uniquely identify the target downlink communication device, such as the target electricity meter serial number.

[0076] As an example, the converged terminal uses the central router to locate the target downlink communication device among the downlink communication devices based on the target downlink communication device identifier. For instance, if the target downlink communication device identifier is the target electricity meter serial number, the converged terminal uses the central router to locate the corresponding target electricity meter among the downlink communication devices based on that target electricity meter serial number, thus determining the target downlink protocol object carrying that target electricity meter. This method is suitable for point-to-point commands and can locate a unique target downlink communication device.

[0077] In one embodiment, the routing information includes the target downlink channel name; The central router determines the target downlink protocol object based on routing information, including: The target downlink protocol object carrying the target downlink communication device is determined by matching the target downlink channel name with the target downlink communication device through the central router.

[0078] The target downlink channel name refers to the channel name used in the routing information to match the downlink communication device, that is, the channel name bound to the target downlink communication device, such as serial port, TCP client, TCP server, carrier, low-power wireless, etc.

[0079] As another example, the converged terminal matches the target downlink communication device based on the target downlink channel name through the central router. For instance, if the target downlink channel name is "carrier," the converged terminal matches downlink communication devices using carrier communication through the central router, determining the target downlink protocol object carrying the matched downlink communication device. When the target downlink channel name corresponds to multiple downlink communication devices, the converged terminal determines the target downlink protocol object carrying each of these devices through the central router and writes the real-time command to the command queue of the corresponding target downlink protocol object. This method is suitable for broadcast commands or group commands and can match one or more downlink communication devices under the target downlink channel name.

[0080] In this embodiment, the central router supports addressing by either the target downlink communication device identifier or the target downlink channel name. This allows it to handle both point-to-point commands targeting a specific downlink communication device and broadcast or group commands targeting multiple devices under a certain type of channel name, improving the flexibility of real-time command routing. Therefore, the central router can flexibly determine the target downlink protocol object based on the target downlink communication device identifier or target downlink channel name in the routing information and write the real-time command into the command queue of the corresponding target downlink protocol object.

[0081] In one embodiment, the routing information includes a request identifier; writing a source protocol stack pointer carrying a real-time command and a pointer to an uplink protocol object into the command queue of the target downlink protocol object includes: Write the request identifier, real-time command, and source protocol stack pointer to the command queue of the target downlink protocol object; Based on the source protocol stack pointer, the response data is transmitted back to the target uplink communication device via the uplink protocol object and the uplink channel object, including: Based on the source protocol stack pointer, the target downlink protocol object calls the response feedback interface of the uplink protocol object to send the request identifier and response data back to the uplink protocol object; The uplink protocol object associates and matches the response data with the original request corresponding to the real-time command based on the request identifier.

[0082] The request identifier refers to the identification information used to uniquely identify a real-time command request issued by the target uplink communication device.

[0083] As an example, the converged terminal writes the request identifier, real-time command, and source protocol stack pointer into the command queue of the target downlink protocol object. Specifically, after determining the target downlink protocol object based on routing information, a command object is constructed, which carries the request identifier, real-time command, and source protocol stack pointer. The converged terminal then pushes this command object into the command queue of the target downlink protocol object.

[0084] As an example, the converged terminal calls the response feedback interface of the uplink protocol object through the target downlink protocol object according to the source protocol stack pointer, and sends the request identifier and response data back to the uplink protocol object. Specifically, after the target downlink protocol object obtains the response data, it determines the uplink protocol object according to the source protocol stack pointer, and calls the response feedback interface provided by the uplink protocol object, passing the request identifier and response data as input parameters, thereby sending the request identifier and response data back to the uplink protocol object.

[0085] As an example, the converged terminal uses the uplink protocol object to associate and match the response data with the original request corresponding to the real-time command based on the request identifier. Specifically, after receiving the request identifier and response data returned by the target downlink protocol object, the uplink protocol object searches for the corresponding real-time command request in the recorded original requests based on the request identifier, associates the response data with the original request, and encapsulates it according to the uplink protocol before sending it back to the target uplink communication device via the uplink channel object.

[0086] In this embodiment, the fusion terminal writes the request identifier, real-time command, and source protocol stack pointer together into the command queue of the target downlink protocol object. This allows the target downlink protocol object to obtain all the information required for the return response after retrieving the command without needing to know the specific type of the uplink protocol object or the specific implementation of the uplink protocol. At the same time, writing the request identifier provides a basis for the association and matching of subsequent response data with the original request, which helps to improve the reliability of cross-stack real-time command routing.

[0087] As can be seen from the above, the data acquisition method for dynamic loading of multi-protocol stacks and cross-stack routing provided in this application obtains the configuration information of the fused terminal, and the registration loader dynamically loads and instantiates the channel component and protocol component by name. It uses a mapping table cache to create function pointers to achieve on-demand lazy loading and reuse, and adapts to both dynamic link libraries and global static registry runtime environments, achieving operating system-independent component loading. The byte scheduler moves data between the read / write buffers of the channel object and the protocol object and drives protocol processing, decoupling transmission and protocol. After the uplink protocol parses the communication frame to obtain routing information and real-time commands, ... The central router determines the target downlink protocol object based on the target communication device identifier or target channel name, and writes the real-time command, request identifier, and source protocol stack pointer into its command queue. The target downlink protocol object processes the command in the idle window, and after obtaining the response data, it sends it back via the source protocol stack pointer. The uplink protocol associates the original request with the request identifier and encapsulates it for transmission back. This enables universal asynchronous routing of real-time commands across heterogeneous protocol stacks in multi-protocol concurrent scenarios, which reduces the storage and memory usage of resource-constrained terminals, supports incremental upgrades at the field module level, and improves the system's flexibility, maintainability, scalability, real-time performance, and reliability.

[0088] To facilitate better implementation of the above-described data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing, this application also provides a corresponding data acquisition device for dynamic loading of multi-reduction stacks and cross-stack routing. The meanings of the terms used are the same as in the above-described data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing; for specific implementation details, please refer to the descriptions in the above method embodiments.

[0089] Please refer to Figure 5 , Figure 5 This is a schematic diagram of a data acquisition device for dynamic loading of multi-protocol stacks and cross-stack routing provided in an embodiment of this application, as shown below. Figure 5 As shown, the data acquisition device for dynamic loading and cross-stack routing of multi-protocol stacks may include a configuration acquisition module 501, a dynamic loading module 502, a communication frame parsing module 503, a routing forwarding module 504, and a response feedback module 505, wherein... The configuration acquisition module 501 is used to acquire the configuration information of the converged terminal. The configuration information includes the channel name and protocol name bound to each of the multiple communication devices connected to the converged terminal; the communication devices include uplink communication devices and downlink communication devices. The dynamic loading module 502 is used to dynamically load the channel component corresponding to the channel name and the protocol component corresponding to the protocol name through the registration loader, and instantiate the channel component and the protocol component respectively to obtain the channel object and the protocol object; wherein, the channel object includes the uplink channel object and the downlink channel object, and the protocol object includes the uplink protocol object and the downlink protocol object; The communication frame parsing module 503 is used to receive communication frames sent by the target uplink communication device through the uplink channel object bound to the target uplink communication device, and to parse the communication frames by the uplink protocol object bound to the uplink channel object to obtain routing information and real-time commands. The routing and forwarding module 504 is used to determine the target downlink protocol object through the central router based on the routing information, and write the source protocol stack pointer carrying the real-time command and pointing to the uplink protocol object into the command queue of the target downlink protocol object; The response feedback module 505 is used to process real-time commands through the target downlink protocol object, obtain response data from the downlink channel object bound to the target downlink protocol object, and send the response data back to the target uplink communication device through the uplink protocol object and the uplink channel object according to the source protocol stack pointer.

[0090] Optionally, in one embodiment, the dynamic loading module 502 is further configured to: for each name in the channel name and protocol name, query whether there is a creation function pointer corresponding to the name in the mapping table maintained by the registration loader; if there is no creation function pointer corresponding to the name in the mapping table, obtain the creation function pointer corresponding to the name and store the name and the obtained creation function pointer in the mapping table; if there is already a creation function pointer corresponding to the name in the mapping table, directly reuse the creation function pointer.

[0091] Optionally, in one embodiment, the dynamic loading module 502 is further configured to: if the fusion terminal is running in a first runtime environment that supports dynamic link libraries, load the component corresponding to the name through the dynamic loading interface via the registry loader, and parse the creation function exported by the component according to the agreement to obtain the creation function pointer corresponding to the name; if the fusion terminal is running in a second runtime environment that does not support dynamic link libraries, query the global static registry according to the name via the registry loader to obtain the creation function pointer corresponding to the name.

[0092] Optionally, in one embodiment, the dynamic loading module 502 is further configured to: construct the complete path of the component file corresponding to the name from the library root path, category identifier and name according to a preset naming convention; load the component file corresponding to the complete path through the platform loading interface to obtain the component handle; and parse the creation function exported by the component according to the convention from the component handle through the symbol resolution interface to obtain the creation function pointer corresponding to the name.

[0093] Optionally, in one embodiment, the communication frame parsing module 503 is further configured to: read data from the uplink channel object and write it into the read buffer of the uplink protocol object through the byte scheduler, drive the uplink protocol object to read data from the read buffer and perform protocol processing, and have the uplink protocol object parse the communication frame sent by the target uplink communication device to obtain routing information and real-time commands.

[0094] Optionally, in one embodiment, the response feedback module 505 is further configured to: call the response feedback interface of the uplink protocol object according to the source protocol stack pointer through the target downlink protocol object, and send the response data back to the uplink protocol object; encapsulate the response data according to the uplink protocol through the uplink protocol object and write it into the write buffer of the uplink protocol object; and write the data in the write buffer of the uplink protocol object to the uplink channel object through the byte scheduler, and send it to the target uplink communication device by the uplink channel object.

[0095] Optionally, in one embodiment, the routing and forwarding module 504 is further configured to: search for the target downlink communication device among the downlink communication devices by means of the central router according to the target downlink communication device identifier, and determine the target downlink protocol object carrying the target downlink communication device.

[0096] Optionally, in one embodiment, the routing and forwarding module 504 is further configured to: write the request identifier, real-time command, and source protocol stack pointer into the command queue of the target downlink protocol object; the response feedback module 505 is further configured to: call the response feedback interface of the uplink protocol object according to the source protocol stack pointer through the target downlink protocol object, and send the request identifier and response data back to the uplink protocol object; and associate and match the response data with the original request corresponding to the real-time command through the uplink protocol object according to the request identifier.

[0097] As can be seen from the above, the data acquisition device for dynamic loading and cross-stack routing of multiple protocol stacks provided in this application obtains the configuration information of the fusion terminal through the configuration acquisition module 501; through the dynamic loading module 502, the registration loader dynamically loads and instantiates the channel component and protocol component by name, and uses the mapping table cache to create function pointers to achieve on-demand lazy loading and reuse, and adapts to both dynamic link library and global static registry runtime environments to achieve operating system-independent component loading; through the communication frame parsing module 503, the byte scheduler moves data between the read and write buffers of the channel object and the protocol object and drives protocol processing, decoupling transmission and protocol, and the uplink protocol object parses the communication frame to obtain routing information and real-time commands; through the routing forwarding module... Block 504 determines the target downlink protocol object by the central router based on the target downlink communication device identifier or the target downlink channel name, and writes the real-time command, request identifier, and source protocol stack pointer into its command queue. The target downlink protocol object processes the command when idle through the response return module 505. After obtaining the response data, it calls the response return interface of the uplink protocol object to return the data according to the source protocol stack pointer. The uplink protocol object associates the original request with the request identifier and encapsulates the return data. This enables general asynchronous routing of real-time commands across heterogeneous protocol stacks in multi-protocol concurrent scenarios, which reduces the storage and memory usage of resource-constrained terminals, supports incremental upgrades at the field module level, and improves the system's flexibility, maintainability, scalability, real-time performance, and reliability.

[0098] It should be noted that the specific limitations of the data acquisition device for dynamic loading of multi-reduction stacks and cross-stack routing can be found in the limitations of the data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing mentioned above, and will not be repeated here. Each module in the aforementioned data acquisition device for dynamic loading of multi-reduction stacks and cross-stack routing can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independent of the processor of the converged terminal, or stored in software in the memory of the converged terminal, so that the processor can call and execute the corresponding operations of each module.

[0099] This application embodiment also provides a converged terminal 600, including a memory 601 and a processor 602. The memory 601 is used to store computer programs. The processor 602 is used to implement the steps of the above-described data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing when executing the computer program.

[0100] Optionally, the converged terminal also includes a communication interface for communicating with uplink and downlink communication devices.

[0101] Optionally, the converged terminal can be a power data concentrator, a data acquisition terminal, an IoT data gateway, or an industrial data acquisition gateway.

[0102] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing.

[0103] This application also provides a computer program product, which includes a computer program that, when run on a processor, implements the steps of the above-described data acquisition method for dynamic loading of multi-restriction stacks and cross-stack routing.

[0104] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0105] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0106] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

[0107] It should be noted that when the above embodiments of this application are applied to specific products or technologies, and user-related data is involved, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A data acquisition method for dynamic loading and cross-stack routing of multi-reduction stacks, characterized in that, include: Obtain the configuration information of the converged terminal, which includes the channel name and protocol name bound to each of the multiple communication devices connected to the converged terminal; the communication devices include uplink communication devices and downlink communication devices; The channel component corresponding to the channel name and the protocol component corresponding to the protocol name are dynamically loaded by the registration loader, and the channel component and the protocol component are instantiated respectively to obtain a channel object and a protocol object; wherein, the channel object includes an uplink channel object and a downlink channel object, and the protocol object includes an uplink protocol object and a downlink protocol object; The communication frames sent by the target uplink communication device are received by the uplink channel object bound to the target uplink communication device, and the communication frames are parsed by the uplink protocol object bound to the uplink channel object to obtain routing information and real-time commands. The central router determines the target downlink protocol object based on the routing information and writes the source protocol stack pointer carrying the real-time command and pointing to the uplink protocol object into the command queue of the target downlink protocol object; The real-time command is processed by the target downlink protocol object, response data is obtained from the downlink channel object bound to the target downlink protocol object, and the response data is transmitted back to the target uplink communication device via the uplink protocol object and the uplink channel object according to the source protocol stack pointer.

2. The data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing according to claim 1, characterized in that, The step of dynamically loading the channel component corresponding to the channel name and the protocol component corresponding to the protocol name through the registration loader includes: For each of the channel name and the protocol name, query the mapping table maintained by the registration loader to see if there is a creation function pointer corresponding to the name; wherein, the mapping table is used to store the correspondence between names and creation function pointers; If the mapping table does not contain a creation function pointer corresponding to the name, then the creation function pointer corresponding to the name is obtained, and the name and the obtained creation function pointer are stored in the mapping table; wherein, when the name is a channel name, the component corresponding to the name is a channel component; when the name is a specification name, the component corresponding to the name is a specification component; If a creation function pointer corresponding to the name already exists in the mapping table, then the creation function pointer is reused directly.

3. The data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing according to claim 2, characterized in that, The step of obtaining the creation function pointer corresponding to the name includes: If the fusion terminal is running in a first runtime environment that supports dynamic link libraries, the registration loader loads the component corresponding to the name through the dynamic loading interface, and parses the creation function exported by the component according to the agreement to obtain the creation function pointer corresponding to the name; If the fusion terminal is running in a second runtime environment that does not support dynamic link libraries, the registry loader queries the global static registry based on the name to obtain the creation function pointer corresponding to the name; wherein, the global static registry is obtained by the component corresponding to the name registering the name and the creation function pointer when the fusion terminal is initialized.

4. The data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing according to claim 3, characterized in that, If the fusion terminal is running in a first runtime environment that supports dynamic link libraries, the registration loader loads the component corresponding to the name through the dynamic loading interface and parses the creation functions exported by the component according to the agreement, including: According to the preset naming convention, the complete path of the component file corresponding to the name is assembled from the library root path, the category identifier and the name; The component file corresponding to the complete path is loaded through the platform loading interface to obtain the component handle; The symbol resolution interface is used to parse the creation function exported by the component according to the convention from the component handle, and obtain the creation function pointer corresponding to the name.

5. The data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing according to claim 1, characterized in that, The process involves receiving communication frames sent by the target uplink communication device through an uplink channel object bound to the target uplink communication device, and parsing the communication frames by an uplink protocol object bound to the uplink channel object to obtain routing information and real-time commands, including: The byte scheduler reads data from the uplink channel object and writes it into the read buffer of the uplink protocol object. The uplink protocol object is then driven to read data from the read buffer and perform protocol processing. The uplink protocol object parses the communication frames sent by the target uplink communication device to obtain routing information and real-time commands. The step of transmitting the response data back to the target uplink communication device via the uplink protocol object and the uplink channel object according to the source protocol stack pointer includes: The byte scheduler writes the data in the write buffer of the uplink protocol object to the uplink channel object, and the uplink channel object sends it to the target uplink communication device.

6. The data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing according to claim 1, characterized in that, The process of processing the real-time command through the target downlink protocol object and obtaining response data from the downlink channel object bound to the target downlink protocol object includes: The data in the write buffer of the target downlink protocol object is written to the downlink channel object by the byte scheduler, and then sent by the downlink channel object to the downlink communication device bound to the downlink channel object. The byte scheduler reads the data returned by the downlink communication device from the downlink channel object and writes it into the read buffer of the target downlink protocol object, driving the target downlink protocol object to read data from the read buffer and perform protocol processing to obtain the response data.

7. The data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing according to claim 5, characterized in that, Before writing the data in the write buffer of the uplink protocol object to the uplink channel object through the byte scheduler, the data acquisition method for dynamic loading of the multi-protocol stack and cross-stack routing further includes: Using the target downlink protocol object, and based on the source protocol stack pointer, the response feedback interface of the uplink protocol object is called to send the response data back to the uplink protocol object; The response data is encapsulated according to the uplink protocol and written to the write buffer of the uplink protocol object.

8. The data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing according to claim 1, characterized in that, The routing information includes the identifier of the target downlink communication device; the step of determining the target downlink protocol object through the central router based on the routing information includes: The central router searches for the target downlink communication device among the downlink communication devices according to the target downlink communication device identifier, and determines the target downlink protocol object carrying the target downlink communication device.

9. The data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing according to claim 1, characterized in that, The routing information includes a request identifier; The step of writing the command queue carrying the real-time command and the source protocol stack pointer pointing to the uplink protocol object into the target downlink protocol object includes: Write the request identifier, the real-time command, and the source protocol stack pointer into the command queue of the target downlink protocol object; The step of transmitting the response data back to the target uplink communication device via the uplink protocol object and the uplink channel object includes: The target downlink protocol object calls the response feedback interface of the uplink protocol object according to the source protocol stack pointer, and sends the request identifier and the response data back to the uplink protocol object; The uplink protocol object associates and matches the response data with the original request corresponding to the real-time command based on the request identifier.

10. A converged terminal, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the data acquisition method for dynamic loading of multi-reduction stacks and cross-stack routing as described in any one of claims 1 to 9 when executing the computer program.

Images