Extensible drive collection framework system and development method

Abstract

This invention provides a scalable driver acquisition framework system and development method, comprising: a driver framework loading module M1, a data acquisition point and driver parameter configuration module M2, a data acquisition process and thread scheduler M3, a driver read / write framework module M4, and a custom data protocol parsing module M5. This invention provides a scalable driver acquisition framework that can expand the driver's data acquisition capabilities by combining a single framework with a small number of custom protocol data parsing programs. It enables real-time data acquisition from various hardware devices such as serial ports, Ethernet ports, CAN buses, and HDMI within a single framework, significantly reducing development and testing workload and solving the problem of high-speed acquisition of multi-source heterogeneous real-time industrial data in the Industrial Internet.

Description

Technical Field

[0001] This invention relates to the field of data acquisition, and more specifically, to a scalable driver-driven acquisition framework system and its development method. Background Technology

[0002] Patent document CN109413180B discloses a data acquisition method, system, device, and storage medium. This method, based on a Netty framework-based data acquisition device, proposes a method to improve data acquisition efficiency by caching data acquired in multiple acquisition commands to an independent buffer each time. The method includes: after a client establishes a connection with the data acquisition device through its server port, a first acquisition command is sent to the client, enabling the client to acquire first data from a first terminal device according to the first acquisition command and store the first data in the buffer; a connection is established with the server through the client port of the data acquisition device, receiving a second acquisition command from the server, acquiring second data from a second terminal device according to the second acquisition command, and storing the second data in the buffer; a connection is established with a third terminal device through the serial port of the data acquisition device, sending a third acquisition command to the third terminal device to acquire third data from the third terminal device and storing the third data in the buffer, thus simultaneously satisfying the acquisition requirements of multiple methods.

[0003] The main shortcoming of this patent document is:

[0004] (1) The patent document can only collect device data of the same protocol type, such as Modbus in its design, and cannot collect data of different devices that require different communication protocols at the same time, so its method has insufficient scalability. In contrast, the data acquisition framework in this invention is scalable and can collect multiple types of device drivers at the same time through dynamic loading technology.

[0005] (2) Using the third-party Netty network framework requires additional configuration. However, the built-in general-purpose driver read / write framework in this invention implements the relevant capabilities without requiring configuration.

[0006] (3) The patent literature uses a single-process sequential sampling method. However, the present invention achieves higher efficiency by using a configurable multi-process, multi-thread scheduling scheme to achieve parallel high-speed sampling. Summary of the Invention

[0007] In view of the shortcomings of the prior art, the purpose of this invention is to provide a scalable driver acquisition framework system and development method.

[0008] According to the present invention, a scalable driver acquisition framework system includes:

[0009] Driver framework loading module M1: Driver framework shell wrapper, responsible for loading the unified driver read / write framework module M4;

[0010] Data acquisition point and driver parameter configuration module M2: responsible for configuring the data acquisition points and driver parameters in the Cvdriver module M1 loaded by the driver framework;

[0011] Data acquisition process and thread scheduler M3: responsible for starting multiple driver processes according to driver configuration, generating multiple driver sub-threads according to each driver requirement, and scheduling these processes and threads;

[0012] M4 Driver Read / Write Framework Module: The driver framework module is responsible for completing common operations of data acquisition drivers;

[0013] Custom Data Protocol Parsing Module M5: Custom data protocol parsing source code is written according to the required extended driver data protocol.

[0014] Preferably, after the driver framework loading module M1 starts, it reads the directory name where the current module is located. The directory name where the module is placed is the same as the name of the corresponding driver implementation. Then, it loads the corresponding custom data protocol parsing module in the executable directory according to the driver directory name.

[0015] Preferably, the data acquisition process and thread scheduler M3 are responsible for reading the driver configuration file from the directory after being called. Each time a driver is extended, a configuration file needs to be added to this directory. Each file records the necessary information of the driver. The data acquisition process and thread scheduler M3 starts the acquisition process for each driver, supporting the configuration of multiple similar devices under one driver.

[0016] Preferably, the driver read / write framework module M4 reads the data acquisition point information table in the driver configuration file, and constructs a list of devices and data blocks. It provides the driver with communication interfaces for interacting with devices and updating data block data, and calls the device and data block scanning interface, self-organizing block interface, and control distribution interface written in the driver.

[0017] Preferably, the custom data protocol parsing module M5 is custom-written according to the extended driver data protocol as needed. Each extended driver data protocol parser is required to include at least the read data information format and the read response data information format, so as to parse data from the read data stream and determine whether the message link is normal.

[0018] The development method of the scalable driver acquisition framework system provided by the present invention includes:

[0019] Step S1: Write the source code for the following modules: driver framework loading module M1, data acquisition point and driver parameter configuration module M2, data acquisition process and thread scheduler M3, and driver read / write framework module M4.

[0020] Step S2: Write the source code for the custom data protocol parsing module M5;

[0021] Step S3: Compile the modules from Step S1 to generate Cvdriver.exe and Cvdrivercommon.dll. Compile the custom data protocol A.dll that needs to be extended in Step S2. Store the general driver read / write framework file Cvdrivercommon.dll in the \executable directory. Also store the driver definition data protocol parsing module M5 that needs to be extended. A \drivers directory is also generated under the \executable directory. Create a directory named \A under each type of extended driver. Copy Cvdriver.exe and rename it to \executable\drivers\A\A.exe.

[0022] Step S4: After compilation and deployment, when the data acquisition and control application module P1 needs to acquire data, it sends a command to drive the extensible driver acquisition framework system to start running. The framework checks how many types of extended drivers are currently configured. For each type of extended driver, it starts a process X.exe. The framework loads the general driver read / write framework Cvdrivercommon.dll to load the general driver read / write function, and then loads the custom data protocol parsing libraries A.dll, B.dll, ... N.dll to implement the parsing capability of the corresponding driver protocol. It reads the data acquisition point configuration information according to the driver configuration file, and determines whether multi-threaded acquisition needs to be started according to the driver configuration information. If so, it generates a multi-threaded acquisition task according to the configuration to start acquiring data. The driver collects and merges the acquired data and then sends it to the data acquisition and control application module P1.

[0023] Preferably, step S1 includes the following steps:

[0024] Step S1.1: Write the code for the driver framework loading module M1;

[0025] Step S1.2: Write the code for the driver read / write framework module M4;

[0026] Step S1.3: Write the code for the data acquisition process and thread scheduler M3;

[0027] Step S1.4: Write the code for the data acquisition point and drive parameter configuration module M2.

[0028] Preferably, step S2 includes the following steps:

[0029] Step S2.1: Write the code for the custom data protocol parsing module M5;

[0030] Step S2.2: For protocols that require extended support, write custom data protocol parsing source code.

[0031] Preferably, step S3 includes the following steps:

[0032] Step S3.1: Compile the code of the driver framework loading module M1 in step S1 to generate the driver framework loader program Cvdriver.exe; compile the unified driver read and write framework module M4 to generate the unified driver read and write framework library Cvdrivercommon.dll; compile the source code of the extended custom data protocol parser A to generate the custom data protocol parser library A.dll that needs to be extended.

[0033] Step S3.2: The software installer generates a directory structure, where the \executable directory is the working directory of this driver framework. Under it, there is a \config directory for storing configuration files, and a \i18N directory for storing multi-language extension files. The general driver read / write framework library file cvdrivercommon.dll and the extended custom data protocol parsing library A.dll are stored as files in the \executable directory. For each type of driver extension, a file named driver.dll is added. There is also a \drivers directory under the \executable directory, under which a directory will be created for each type of driver. The corresponding protocol driver main program will be stored in the driver directory.

[0034] Step S3.3: Installer deploys the compiled driver framework: The installer reads the driver configuration file. Based on the driver type A that needs to be extended, the installer copies Cvdriver.exe to the corresponding / drivier / A directory and renames it to A.exe. The installer copies Cvdrivercommon.dll to the common library directory \executable and A.dll to the common library directory \executable. The installer activates the / drivier / A.exe program, which reads the Cvdrivercommon.dll module and the A.dll module.

[0035] Preferably, step S4 includes the following steps:

[0036] Step S4.1: After the compilation and deployment are completed, when the data acquisition and control application module P1 needs to acquire data, a command is sent to drive the extensible driver acquisition framework system to start running and begin reading the driver configuration file;

[0037] Step S4.2: After the driver starts, the general driver read and write framework Cvdrivercommon.dll is loaded to implement the general driver read and write function by calling the interface function defined in step S1. Then, the custom data protocol parsing libraries A.dll, B.dll, ... N.dll are loaded to realize the parsing capability of the corresponding driver protocol.

[0038] Step S4.3: The driver reads the data acquisition point configuration information according to the driver configuration file, determines whether multi-threaded acquisition needs to be started based on the driver configuration information, and if so, generates a multi-threaded acquisition task to start acquiring data according to the configuration. The acquisition cycles of different threads are staggered through thread scheduling, and different threads are bound to different CPU cores of a multi-core computer to run. Different scheduling cycles are set for different processes according to the data acquisition efficiency of different devices. The driver collects, merges, and compresses the acquired data before sending it to the data acquisition control application module P1.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] 1. This invention provides an extensible driver acquisition framework, which can expand the driver's data acquisition capabilities by combining a framework with a small number of custom protocol data parsing programs. It can realize real-time data acquisition from different types of hardware devices such as serial ports, Ethernet ports, CAN buses, and HDMI under a single framework.

[0041] 2. The driver acquisition framework of this invention can be extended in two ways, multi-threaded and multi-process, according to the performance of the device and the requirements of the configuration file, so as to improve the data reading performance and greatly improve the rapid extraction of industrial data.

[0042] 3. In this invention, the driver acquisition framework encapsulates the connection of various physical interface devices, the reading of data blocks, and the parsing of standard data protocols. It is only necessary to implement the parsing of custom data protocols to access any data format. Compared with the traditional development mode of one driver for one device, it can greatly reduce the workload of development and testing, and solve the problem of high-speed acquisition of multi-source heterogeneous real-time industrial data in the industrial Internet. Attached Figure Description

[0043] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0044] Figure 1 This is a framework diagram of the present invention.

[0045] Figure 2 This is a diagram of the program directory.

[0046] Figure 3This is a flowchart illustrating the compilation, installation, and startup process of the program for this invention.

[0047] Figure 4 This is a flowchart illustrating the operation of the present invention. Detailed Implementation

[0048] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the scope of protection of the present invention.

[0049] This invention provides an extensible driver-driven acquisition framework system, comprising:

[0050] Driver framework loading module M1: Driver framework shell wrapper, responsible for loading the unified driver read / write framework module M4;

[0051] Data acquisition point and driver parameter configuration module M2: responsible for configuring the data acquisition points and driver parameters in the Cvdriver module M1 loaded by the driver framework;

[0052] Data acquisition process and thread scheduler M3: responsible for starting multiple driver processes according to driver configuration, generating multiple driver sub-threads according to each driver requirement, and scheduling these processes and threads;

[0053] M4 Driver Read / Write Framework Module: The driver framework module is responsible for completing common operations of data acquisition drivers;

[0054] Custom Data Protocol Parsing Module M5: Custom data protocol parsing source code is written according to the required extended driver data protocol.

[0055] This invention also provides a development method for an extensible driver-driven acquisition framework system, comprising:

[0056] Step S1: Write the source code for the necessary modules in this invention, such as... Figure 1 As shown, it is necessary to write a driver framework loading module M1, which is a driver framework shell wrapper responsible for loading the unified driver read / write framework module M4; write the driver read / write framework module M4, which is a driver framework module responsible for completing the common operations of the data acquisition driver; and write a data acquisition process and thread scheduler M3, which is responsible for starting multiple driver processes according to the driver configuration, generating multiple driver sub-threads according to each driver requirement, and scheduling these processes and threads. Step S1 includes the following steps:

[0057] Step S1.1: Write the code to load the Cvdriver module M1 in the driver framework. This module is a wrapper for the driver framework and is responsible for loading the unified driver read / write framework Cvdrivercommon module M4. After the driver framework loads the Cvdriver module M1 and starts, it reads the directory name where the current module is located. Typically, the directory name where this module is placed is the same as the name of the corresponding implementation driver. Then, based on the driver directory name, it loads the corresponding custom data protocol parsing module in the executable directory. For example, the Modbus driver will load the Modbus.dll module.

[0058] Step S1.2: Develop the driver read / write framework module Cvdrivercommon M4. This module is the driver framework module responsible for completing common operations of the data acquisition driver. This module reads the data acquisition point information table from the driver configuration file, assembles a list of devices and data blocks, provides the driver with communication interfaces for interacting with devices, updating data block data, etc., and calls the device and data block scanning interfaces, self-organizing block interfaces, and control distribution interfaces written in the driver. It needs to implement task groups, devices, data blocks, and tag points, respectively, using classes CTaskGroup, CDevice, CDataBlock, and the structure TagAddrID.

[0059] The Cvdrivercommon module M4 of the driver read / write framework needs to record the information of each TagID, device name, data block name, and address offset for subsequent data collection. In the design, this is recorded using m_mapTagID2Addr.

[0060] Additionally, it is necessary to implement interfaces for obtaining data block information, obtaining device information, obtaining user data, obtaining user data pointers, and updating data block data.

[0061] Step S1.3: Write the data acquisition process and thread scheduler M3. This module is responsible for starting multiple driver processes according to the driver configuration, generating multiple driver sub-threads according to each driver requirement, and scheduling these processes and threads.

[0062] When this module is invoked, it reads the driver configuration files from the config\drivers directory. Each time a driver is extended, a configuration file needs to be added to this directory. For example, if the Modbus and SNAP7 drivers are extended, two driver configuration files, Modbus.xml and SNAP7.xml, need to be added to this directory. Each file records the necessary information of the driver, such as the driver port, connection type, IP, master / slave configuration, driver parameters, etc.

[0063] The M3 data acquisition process and thread scheduler starts an acquisition process for each driver. The M3 scheduler supports configuring multiple similar devices under a single driver, improving acquisition efficiency through acquisition process scheduling. For the same driver, different task numbers can also be configured to start different acquisition threads, further enhancing acquisition efficiency.

[0064] Step S2: Develop a custom data protocol parsing module M5. This module is customized to support the driver data protocol as needed. For example, if the driver needs to be extended to support the Modbus industrial protocol, then a custom data protocol parsing source program for the Modbus protocol needs to be developed. Step S2 includes the following steps:

[0065] Step S2.1: Write a custom data protocol parsing module M5. This module is customized according to the required extended driver data protocol. Each extended driver data protocol parser must at least include read data information format and read response data information format to parse data from the read data stream and determine whether the message link is normal.

[0066] Step S2.2: For example, if it is necessary to extend the driver to support the Modbus industrial protocol, then write a custom data protocol parsing source program for the Modbus protocol.

[0067] The format for reading data information can be defined similarly to the following:

[0068] Table 1 Data Information Format

[0069]

[0070] If the information is read correctly, respond with a read response message, the format of which can be defined as similar to the following:

[0071] Table 2 Read Response Information

[0072]

[0073]

[0074] Step S3: Compile the modules from step S1 to generate Cvdriver.exe and Cvdrivercommon.dll. Compile the custom data protocol A.dll that needs to be extended in step S2. The installer generates, for example... Figure 2The directory contains the generic driver read / write framework file Cvdrivercommon.dll, located in the \executable directory. It also stores driver definition data protocol parsing modules that can be extended as needed. A \drivers directory is also generated under the \executable directory, with a subdirectory (e.g., \A) created for each extended driver. Cvdriver.exe is copied and renamed to \executable\drivers\A\A.exe. Step S3 includes the following steps:

[0075] Step S3.1: Compile the code from step S1 that loads the Cvdriver module M1 to generate the driver framework loader program Cvdriver.exe, as shown below. Figure 3 In process S1, compile the unified driver read / write framework Cvdrivercommon module M4 to generate the unified driver read / write framework library Cvdrivercommon.dll, as shown below. Figure 3 In process S2, the source code of the extended custom data protocol parser A is compiled and implemented, generating the custom data protocol parser library A.dll that needs to be extended.

[0076] Step S3.2: Generating the software installer Figure 2 The directory structure shown is as follows: the \executable directory is the working directory of this driver framework. Under it are the \config directory for storing configuration files, the \i18N directory for storing multi-language extension files, the general driver read / write framework library file cvdrivercommon.dll, and the extended custom data protocol parsing library A.dll, all stored as files in the \executable directory. For each type of driver extension, a file named "driver_name.dll" is added. The \executable directory also contains a \drivers directory, under which a subdirectory is created for each type of driver, such as Modbus, OPC, OPCUA, IEC104. These driver directories contain the corresponding protocol driver main programs, such as Modbus.exe, OPC.exe, OPCUA.exe, and IEC104.exe.

[0077] Step S3.3: Install the compiled driver framework. The deployment process is as follows: Figure 3The process is as follows: S4, the installer reads the driver configuration file; S5, the installer expands the driver to type A; S6, the installer copies Cvdriver.exe to the corresponding / drivier / A directory and renames it to A.exe; S7, the installer copies Cvdrivercommon.dll to the common library directory \executable; S8, the installer copies A.dll to the common library directory \executable; S9, the / drivier / A.exe program is activated; and S10, the / drivier / A.exe program reads the Cvdrivercommon.dll module and the A.dll module.

[0078] Step S4: After compilation and deployment, when the data acquisition and control application module P1 needs to acquire data, a command is sent to drive the framework to start running. The framework checks how many extended drivers are currently configured. For each extended driver, a process X.exe is started. The framework loads the general driver read / write framework Cvdrivercommon.dll to load the general driver read / write function, and then loads the custom data protocol parsing libraries A.dll, B.dll, ... N.dll to implement the parsing capability of the corresponding driver protocol. According to the driver configuration file, the data acquisition point configuration information is read. Based on the driver configuration information, it is determined whether multi-threaded acquisition needs to be started. If so, a multi-threaded acquisition task is generated according to the configuration to start acquiring data. The driver collects and merges the acquired data and then sends it to the data acquisition and control application module P1. Step S4 includes the following steps:

[0079] Step S4.1: After compilation and deployment are complete, when the data acquisition and control application module P1 needs to acquire data, a command is sent to drive the framework to start running and begin reading the driver configuration file, such as... Figure 4 In process S100, the driver configuration file records three types of information;

[0080] The current framework includes several extended drivers. Information for each driver type includes its associated devices, number of acquisition threads, acquisition period, etc. The driver needs to collect device data point information, including data point name, type, range, address, etc. Based on the current list of extended driver types, the driver framework checks how many extended drivers are currently configured and starts a process X.exe for each extended driver type. Figure 4 The processes S102 and S102.

[0081] Step S4.2: After the driver starts, the generic driver read / write framework Cvdrivercommon.dll is loaded. This implements the generic read / write functionality of the driver by calling the interface functions defined in step S1. Then, custom data protocol parsing libraries A.dll, B.dll, ... N.dll are loaded to implement the parsing capabilities of the corresponding driver protocols, such as... Figure 4 The process S104.

[0082] Step S4.3: The driver reads the data acquisition point configuration information according to the driver configuration file, and determines whether multi-threaded acquisition needs to be started based on the driver configuration information. If so, it generates a multi-threaded acquisition task according to the configuration and starts acquiring data. Through reasonable thread scheduling methods, such as staggering the acquisition cycles of different threads, binding different threads to different CPU cores of a multi-core computer, and setting different scheduling cycles for different processes according to the data acquisition efficiency of different devices, the driver improves the ability to acquire data from different devices. The driver collects, merges, and compresses the acquired data before sending it to the data acquisition and control application module P1, thereby realizing high-speed acquisition of multi-source heterogeneous real-time industrial data in the Industrial Internet.

[0083] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A scalable driver acquisition framework system, characterized in that, include: Driver framework loading module M1: Driver framework shell wrapper, responsible for loading the unified driver read / write framework module M4; Data acquisition point and driver parameter configuration module M2: responsible for configuring the data acquisition points and driver parameters in the Cvdriver module M1 loaded by the driver framework; Data acquisition process and thread scheduler M3: responsible for starting multiple driver processes according to driver configuration, generating multiple driver sub-threads according to each driver requirement, and scheduling these processes and threads; M4 Driver Read / Write Framework Module: The driver framework module is responsible for completing common operations of data acquisition drivers; Custom Data Protocol Parsing Module M5: Custom data protocol parsing source code is written according to the required extended driver data protocol; The data acquisition process and thread scheduler M3 are responsible for reading the driver configuration file from the directory after being called. Each time a driver is extended, a configuration file needs to be added to this directory. Each file records the necessary information of the driver. The data acquisition process and thread scheduler M3 starts an acquisition process for each driver, supporting the configuration of multiple similar devices under one driver; The driver read / write framework module M4 reads the data acquisition point information table in the driver configuration file, and builds a list of devices and data blocks. It provides the driver with communication interfaces for interacting with devices and updating data block data, and calls the device and data block scanning interface, self-organizing block interface, and control distribution interface written in the driver. The custom data protocol parsing module M5 is custom-written according to the extended driver data protocol as needed. Each extended driver data protocol parser must include at least the read data information format and the read response data information format, so as to parse data from the read data stream and determine whether the message link is normal.

2. The scalable driver acquisition framework system according to claim 1, characterized in that, After the driver framework loading module M1 starts, it reads the directory name where the current module is located. The directory name where the module is placed is the same as the name of the corresponding driver implementation. Then, it loads the corresponding custom data protocol parsing module in the executable directory according to the driver directory name.

3. A development method for a scalable driver acquisition framework system as described in claim 1, characterized in that, include: Step S1: Write the source code for the following modules: driver framework loading module M1, data acquisition point and driver parameter configuration module M2, data acquisition process and thread scheduler M3, and driver read / write framework module M4. Step S2: Write the source code for the custom data protocol parsing module M5; Step S3: Compile the modules from Step S1 to generate Cvdriver.exe and Cvdrivercommon.dll. Compile the custom data protocol A.dll that needs to be extended in Step S2. Store the general driver read / write framework file Cvdrivercommon.dll in the \executable directory. Also store the driver definition data protocol parsing module M5 that needs to be extended. A \drivers directory is also generated under the \executable directory. Create a directory named \A under each type of extended driver. Copy Cvdriver.exe and rename it to \executable\drivers\A\A.exe. Step S4: After compilation and deployment, when the data acquisition and control application module P1 needs to acquire data, it sends a command to drive the extensible driver acquisition framework system to start running. The framework checks how many extended drivers are currently configured. For each extended driver, it starts a process X.exe. The framework loads the general driver read / write framework Cvdrivercommon.dll to load the general driver read / write function, and then loads the custom data protocol parsing libraries A.dll, B.dll, ... N.dll to implement the parsing capability of the corresponding driver protocol. It reads the data acquisition point configuration information according to the driver configuration file, and determines whether multi-threaded acquisition needs to be started according to the driver configuration information. If so, it generates a multi-threaded acquisition task according to the configuration to start acquiring data. The driver collects and merges the acquired data and then sends it to the data acquisition and control application module P1.

4. The development method of the scalable driver acquisition framework system according to claim 3, characterized in that, Step S1 includes the following steps: Step S1.1: Write the code for the driver framework loading module M1; Step S1.2: Write the code for the driver read / write framework module M4; Step S1.3: Write the code for the data acquisition process and thread scheduler M3; Step S1.4: Write the code for the data acquisition point and drive parameter configuration module M2.

5. The development method of the scalable driver acquisition framework system according to claim 3, characterized in that, Step S2 includes the following steps: Step S2.1: Write the code for the custom data protocol parsing module M5; Step S2.2: For protocols that require extended support, write custom data protocol parsing source code.

6. The development method of the scalable driver acquisition framework system according to claim 3, characterized in that, Step S3 includes the following steps: Step S3.1: Compile the code of the driver framework loading module M1 in step S1 to generate the driver framework loader program Cvdriver.exe; compile the unified driver read and write framework module M4 to generate the unified driver read and write framework library Cvdrivercommon.dll; compile the source code of the extended custom data protocol parser A to generate the custom data protocol parser library A.dll that needs to be extended. Step S3.2: The software installer generates a directory structure, where the \executable directory is the working directory of this driver framework. Under it, there is a \config directory for storing configuration files, and a \i18N directory for storing multi-language extension files. The general driver read / write framework library file cvdrivercommon.dll and the extended custom data protocol parsing library A.dll are stored as files in the \executable directory. For each type of driver extension, a file named driver.dll is added. The \executable directory also contains a \drivers directory, under which a directory will be created for each type of driver. The corresponding protocol driver main program will be stored in the driver directory. Step S3.3: Installer deploys the compiled driver framework: The installer reads the driver configuration file. Based on the driver type A that needs to be extended, the installer copies Cvdriver.exe to the corresponding / drivier / A directory and renames it to A.exe. The installer copies Cvdrivercommon.dll to the common library directory \executable and A.dll to the common library directory \executable. The installer activates the / drivier / A.exe program, which reads the Cvdrivercommon.dll module and the A.dll module.

7. The development method of the scalable driver acquisition framework system according to claim 3, characterized in that, Step S4 includes the following steps: Step S4.1: After the compilation and deployment are completed, when the data acquisition and control application module P1 needs to acquire data, a command is sent to drive the extensible driver acquisition framework system to start running and begin reading the driver configuration file; Step S4.2: After the driver starts, the general driver read / write framework Cvdrivercommon.dll is loaded to implement the general driver read / write function by calling the interface function defined in step S1. Then, the custom data protocol parsing libraries A.dll, B.dll, ... N.dll are loaded to implement the parsing capability of the corresponding driver protocol. Step S4.3: The driver reads the data acquisition point configuration information according to the driver configuration file, determines whether multi-threaded acquisition needs to be started based on the driver configuration information, and if so, generates a multi-threaded acquisition task to start acquiring data according to the configuration. The acquisition cycles of different threads are staggered through thread scheduling, and different threads are bound to different CPU cores of a multi-core computer to run. Different scheduling cycles are set for different processes according to the data acquisition efficiency of different devices. The driver collects, merges, and compresses the acquired data before sending it to the data acquisition control application module P1.

Images