Multi-protocol data acquisition method and device, electronic equipment and readable storage medium

Abstract

The invention relates to the technical field of data processing, and provides a multi-protocol data acquisition method and device, electronic equipment and a readable storage medium. The method comprises the following steps: firstly, sending a first driving request to an independently running acquisition driver for discovering an acquisition driver configured in an acquisition scheduling framework; then receiving driving protocol information sent by the acquisition driver based on the first driving request; in response to a received task request sent by the acquisition driver, issuing task metadata in a target structured format to the acquisition driver according to the driver protocol information; and finally, receiving the acquisition data of the target structured format acquired by the acquisition driver based on task metadata acquisition. The protocol compatibility of the data acquisition system can be improved, loose coupling of the data acquisition system is realized, the expandability of the system is improved, the maintenance cost of the system is reduced, and the reliability of the whole acquisition system is improved.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and in particular relates to a multi-protocol data acquisition method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] The Industrial Internet of Things (IIoT) encompasses a wide variety of field devices, each employing different data interfaces and communication protocols. Therefore, traditional data acquisition solutions require custom development of specific protocols for different devices within the data acquisition system, leading to high coupling within the system. When a new protocol or device needs to be integrated, significant modifications or even complete redevelopment of the existing data acquisition system are often necessary. Clearly, existing data acquisition systems suffer from high coupling, poor scalability, high maintenance costs, and low development efficiency. Summary of the Invention

[0003] In view of the shortcomings of the prior art, the purpose of this invention is to provide a multi-protocol data acquisition method, apparatus, electronic device and readable storage medium to solve the above problems.

[0004] This invention provides a multi-protocol data acquisition method, applied to an acquisition scheduling framework, comprising: Send a first driver request to the acquisition driver, wherein the first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independently running process; receive driver protocol information sent by the acquisition driver based on the first driver request; respond to the received task request sent by the acquisition driver, and send task metadata in the target structured format to the acquisition driver according to the driver protocol information; receive the acquisition data uploaded by the acquisition driver, wherein the acquisition data is acquired by the acquisition driver according to the task metadata, and the format of the acquisition data is the target structured format.

[0005] In one embodiment of the present invention, sending a first drive request to the acquisition driver includes: Obtain the configuration address of the acquisition driver; send the first driver request to the acquisition driver based on the configuration address.

[0006] In one embodiment of the present invention, before sending the target structured format task metadata to the acquisition driver according to the driver protocol information, the method further includes: Based on the driver protocol information, the acquisition configuration information of the acquisition driver is determined, including the information of the device to be acquired and the information of the data to be acquired; based on the information of the device to be acquired and the information of the data to be acquired, the target structured format task metadata is obtained.

[0007] In one embodiment of the present invention, after receiving the collected data uploaded by the acquisition driver, the method further includes: Send a second drive request to the acquisition driver. The second drive request is of the same type as the first drive request. The second drive request is a control instruction in a target structured format. The control instruction is used to instruct the acquisition driver to perform the target operation. Receive the feedback result uploaded by the acquisition driver after performing the target operation.

[0008] This invention also provides a multi-protocol data acquisition method, applied to acquisition drivers, including: In response to receiving a first driver request from the acquisition scheduling framework, the system obtains the service address of the acquisition scheduling framework, wherein the first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independently running process; based on the service address, the system sends a task request to the acquisition scheduling framework; receives task metadata in the target structured format issued by the acquisition scheduling framework based on the task request; obtains the acquisition data based on the task metadata, and uploads the acquisition data to the acquisition scheduling framework, wherein the acquisition data is in the target structured format.

[0009] In one embodiment of the present invention, the task metadata includes the metadata of the device to be collected and the metadata of the information to be collected. Obtaining the collected data based on the task metadata includes: Establish a communication connection with the device to be collected based on the metadata of the device to be collected; obtain the collected data from the device based on the metadata of the information to be collected.

[0010] In one embodiment of the present invention, after uploading the collected data to the collection scheduling framework, the method further includes: Receive the second drive request issued by the acquisition scheduling framework. The second drive request is of the same type as the first drive request. The second drive request is a control instruction in a target structured format. Execute the target operation according to the control instruction and send the feedback result after the target operation to the acquisition scheduling framework.

[0011] This invention also provides a multi-protocol data acquisition device, applied to an acquisition scheduling framework, comprising: The first sending module is configured to send a first driver request to the acquisition driver, wherein the first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independently running process; the first receiving module is configured to receive driver protocol information sent by the acquisition driver based on the first driver request; the task issuing module is configured to respond to the received task request sent by the acquisition driver and issue task metadata in the target structured format to the acquisition driver according to the driver protocol information; the second receiving module is configured to receive acquisition data uploaded by the acquisition driver, wherein the acquisition data is acquired by the acquisition driver according to the task metadata, and the format of the acquisition data is the target structured format.

[0012] This invention also provides a multi-protocol data acquisition device, applied to acquisition driving, comprising: The address acquisition module is configured to obtain the service address of the acquisition scheduling framework in response to receiving a first driver request sent by the acquisition scheduling framework. The first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independent running process. The second sending module is configured to send a task request to the acquisition scheduling framework based on the service address. The third receiving module is configured to receive task metadata in the target structured format issued by the acquisition scheduling framework based on the task request. The data uploading module is configured to obtain the acquisition data based on the task metadata and upload the acquisition data to the acquisition scheduling framework. The acquisition data is in the target structured format.

[0013] The present invention also provides an electronic device, comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device performs the steps of the above-described method.

[0014] The present invention also provides a storage medium comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, when the processor executes the computer program, the storage medium performs the steps of the above-described method.

[0015] The beneficial effects of this technical solution are as follows: First, a first driver request is sent to the independently running acquisition driver to discover the acquisition driver configured in the acquisition scheduling framework. Then, driver protocol information sent by the acquisition driver based on the first driver request is received. In response to the received task request from the acquisition driver, task metadata in the target structured format is sent to the acquisition driver according to the driver protocol information. Finally, the acquisition data in the target structured format obtained by the acquisition driver based on the task metadata is received. Since the acquisition driver is an independently running process, when adding new devices or protocols, only the corresponding acquisition driver needs to be developed and configured in the acquisition scheduling framework, without requiring extensive modifications or redevelopment of the entire acquisition system. This improves the protocol compatibility of the acquisition system, achieves loose coupling of the data acquisition system, enhances system scalability, and reduces system maintenance costs. Simultaneously, the task metadata and acquisition data in the target structured format make data processing more standardized and efficient, ensuring that the entire system has loose coupling, standardization, and easy integration characteristics. This improves the accuracy and reliability of data acquisition, thereby enhancing the reliability of the entire acquisition system.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 This is a schematic flowchart illustrating a multi-protocol data acquisition method according to an exemplary embodiment of the present invention; Figure 2 This is a flowchart illustrating another multi-protocol data acquisition method according to an exemplary embodiment of the present invention; Figure 3 This is a logical interaction diagram illustrating another multi-protocol data acquisition method according to an exemplary embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the structure of a multi-protocol data acquisition device according to an exemplary embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the structure of another multi-protocol data acquisition device according to an exemplary embodiment of the present invention; Figure 6 A schematic diagram of a computer system suitable for implementing embodiments of the present invention is shown. Detailed Implementation

[0018] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0019] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0020] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0021] Please see Figure 1 , Figure 1 This is a flowchart illustrating a multi-protocol data acquisition method in an exemplary embodiment of the present invention, which is applied to an acquisition scheduling framework. For example... Figure 1 As shown, in an exemplary embodiment, the multi-protocol data acquisition method includes steps S101 to S104, and each step is described in detail below.

[0022] S101, send the first driver request to the acquisition driver.

[0023] The first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independent running process.

[0024] Furthermore, it should be noted that the data acquisition system in this application includes an acquisition scheduling framework and acquisition drivers configured under the acquisition scheduling framework. Multiple acquisition drivers can be configured under one acquisition scheduling framework. The specific number is not specifically limited in this embodiment. The multiple acquisition drivers have different acquisition communication protocols.

[0025] In some examples, such as a site having 3 devices (device A, device B, and device C). Device A uses the Open Platform Communications Unified Architecture (OPC UA) for communication, device B uses Modbus Transmission Control Protocol / Internet Protocol (Modbus TCP / IP) for communication, and device C uses the S7 Communication Protocol (S7). To accurately acquire data from devices A, B, and C, this application configures three independently running acquisition drivers within the acquisition scheduling framework, each corresponding to a different communication protocol. Specifically, the first acquisition driver is configured to support the OPC UA protocol for communication and data acquisition with device A; the second driver supports the Modbus TCP / IP protocol for communication and data acquisition with device B; and the third driver supports the S7 communication protocol for communication and data acquisition with device C. This avoids compatibility issues between different communication protocols present in existing technologies and prevents highly coupled data acquisition systems, which can lead to complex and error-prone data acquisition processes.

[0026] Furthermore, by configuring corresponding acquisition drivers for devices with different communication protocols, it can be ensured that each device can conduct stable and efficient data interaction using its own adapted communication method. At the same time, the design of independently running acquisition drivers ensures that the various acquisition tasks do not interfere with each other, guaranteeing that a single acquisition driver failure will not affect the acquisition scheduling framework and other acquisition drivers. This improves the reliability and scalability of the entire data acquisition system and allows for flexible addition or removal of acquisition drivers to adapt to different numbers and types of devices in acquisition scenarios.

[0027] Understandably, configuring an independently running acquisition driver within the acquisition scheduling framework allows for the independent development, deployment, and upgrading of both the acquisition scheduling framework and the acquisition driver, thereby reducing the complexity of system development and improving development efficiency.

[0028] In some examples, the first driving request may be a Representational State Transfer (REST) ​​request, or it may be other forms of request, such as a Hyper Text Transfer Protocol (HTTP) request or a Simple Object Access Protocol (SOAP) request, etc. This embodiment does not specifically limit this.

[0029] S102, Receive the driver protocol information sent by the acquisition driver based on the first driver request; It is understandable that after sending the first drive request, the acquisition driver can respond to the first drive request and send its own drive protocol information to the acquisition scheduling framework. The acquisition scheduling framework receives the acquisition driver's own drive protocol information, thereby establishing a data communication channel with the acquisition driver, providing a foundation for the subsequent accurate and complete acquisition of device data.

[0030] S103, in response to the received task request sent by the acquisition driver, send the target structured format task metadata to the acquisition driver according to the driver protocol information; Specifically, after initialization and establishing a communication channel with the acquisition scheduling framework, the acquisition driver can send a task request to the framework. Upon receiving the task request, the acquisition scheduling framework can generate task metadata conforming to the target structured format based on pre-configured rules or strategies and the acquisition driver's driver protocol information, and then distribute this task metadata to the corresponding acquisition driver. The task metadata describes the specific requirements of the relevant acquisition task to ensure that the acquisition driver can execute the data acquisition task accurately and without errors.

[0031] In some examples, the target structured format is JavaScript Object Notation (JSON), but it can also be other formats, such as Extensible Markup Language (XML), etc. This embodiment does not specifically limit it.

[0032] S104 receives the collected data uploaded by the acquisition driver.

[0033] The collected data is obtained by the acquisition driver based on the task metadata, and the format of the collected data is the target structured format.

[0034] It should be noted that the collected data is obtained by the acquisition driver based on the task metadata, and the format of the collected data is the target structured format. This ensures that the format of the collected data is consistent with the format of the task metadata, establishing a single, universal language between the acquisition scheduling framework and the acquisition driver. The acquisition scheduling framework and the acquisition driver do not need to adapt to multiple protocols for different types of data; they only need to understand and process the target structured format, thereby effectively reducing system complexity and improving data interaction efficiency. Achieving uniformity at the data format level guarantees the loose coupling, standardization, and easy integration characteristics of the entire system.

[0035] According to the technical solution provided in this application, firstly, a first driver request is sent to the independently running acquisition driver to discover the acquisition driver configured in the acquisition scheduling framework; then, driver protocol information sent by the acquisition driver based on the first driver request is received; in response to the received task request sent by the acquisition driver, task metadata in the target structured format is sent to the acquisition driver according to the driver protocol information; finally, acquisition data in the target structured format obtained by the acquisition driver based on the task metadata is received. Since the acquisition driver is an independently running process, when adding a new device or protocol, only the corresponding acquisition driver needs to be developed and configured in the acquisition scheduling framework, without requiring extensive modifications or redevelopment of the entire acquisition system. This improves the protocol compatibility of the acquisition system, achieves loose coupling of the data acquisition system, improves system scalability, and reduces system maintenance costs. Simultaneously, the task metadata and acquisition data in the target structured format make data processing more standardized and efficient, ensuring that the entire system has loose coupling, standardization, and easy integration characteristics. This improves the accuracy and reliability of data acquisition, thereby enhancing the reliability of the entire acquisition system.

[0036] In some embodiments, sending a first driver request to the acquisition driver includes: Obtain the configuration address of the acquisition driver; send the first driver request to the acquisition driver based on the configuration address.

[0037] Specifically, when sending the first driver request to the acquisition driver, the acquisition scheduling framework can first obtain the configuration address of the acquisition driver, which can be pre-configured in the acquisition scheduling framework by the relevant user.

[0038] Then, the acquisition scheduling framework sends a first driver request to the acquisition driver according to the configured address. This first driver request is used to identify and discover the interface of the acquisition driver.

[0039] In this way, the data acquisition scheduling framework can proactively establish connections with independently running data acquisition drivers, providing a stable channel for subsequent data acquisition processes, ensuring that the data acquisition process runs according to established rules and procedures, and achieving efficient and stable data acquisition tasks.

[0040] In some embodiments, before sending the target structured format task metadata to the acquisition driver according to the driver protocol information, the method further includes: Based on the driver protocol information, the acquisition configuration information of the acquisition driver is determined, including the information of the device to be acquired and the information of the data to be acquired; based on the information of the device to be acquired and the information of the data to be acquired, the target structured format task metadata is obtained.

[0041] Specifically, the data acquisition configuration information can be pre-configured in the data acquisition scheduling framework. Different devices require different data to be acquired, so the data to be acquired by each device can be configured. The data acquisition configuration information includes information about the device to be acquired (such as device IP or device name) and information about the data to be acquired (such as data type, acquisition point, acquisition frequency, data precision, and other key parameters).

[0042] Then, the data is encapsulated based on the device information and the data to be collected to obtain task metadata. This task metadata is stored in the data acquisition scheduling framework so that it can be subsequently sent to the corresponding acquisition driver to ensure the accuracy of data acquisition. Storing the task metadata in the acquisition scheduling framework also facilitates the management and scheduling of acquisition tasks, improving the efficiency and reliability of data acquisition.

[0043] It should be noted that during the encapsulation process, the task metadata needs to be encapsulated into a target structured format. As mentioned earlier, the target structured format can be JSON or XML, etc. This standardized format helps reduce errors and ambiguities during data transmission and improves data processing efficiency.

[0044] In some embodiments, after receiving the collected data uploaded by the acquisition driver, the method further includes: Send a second drive request to the acquisition driver. The second drive request is of the same type as the first drive request. The second drive request is a control instruction in a target structured format. The control instruction is used to instruct the acquisition driver to perform the target operation. Receive the feedback result uploaded by the acquisition driver after performing the target operation.

[0045] Specifically, after receiving the collected data uploaded by the acquisition driver, a second driver request can be sent to the acquisition driver; It should be noted that if the first driving request is a REST request, the second driving request must also be a REST request. The type of the second driving request must be consistent with that of the first driving request to ensure the smoothness and stability of data interaction.

[0046] Meanwhile, the second drive request is a target structured control instruction. This control instruction instructs the acquisition driver to perform the target operation, allowing the acquisition scheduling framework to control and manage the acquisition driver in a unified and standardized manner. Upon receiving the second drive request, the acquisition driver executes the target operation according to the specific requirements in the control instruction.

[0047] The target operation includes at least one of the following: controlling the acquisition driver to start the device, stopping the device, sending data, reading data, and changing metadata.

[0048] Then, the acquisition driver encapsulates the operation results into feedback results in the target structured format and uploads them to the acquisition scheduling framework. After receiving the feedback results, the acquisition scheduling framework can perform further data processing or storage to complete the closed-loop management of the entire data acquisition process.

[0049] In this way, the data acquisition scheduling framework can monitor and control the acquisition drive, improving the flexibility and reliability of the data acquisition system. Meanwhile, since the second drive request is of the same type as the first drive request, and both the second drive request and the feedback result use the target structured format, data interaction becomes more standardized and efficient, further enhancing the overall system compatibility of the acquisition system.

[0050] Please see Figure 2 , Figure 2 This is a flowchart illustrating another multi-protocol data acquisition method in an exemplary embodiment of the present invention, which is applied to an acquisition driver. For example... Figure 2 As shown, in an exemplary embodiment, the multi-protocol data acquisition method includes steps S201 to S204, and each step is described in detail below.

[0051] S201, in response to receiving the first drive request sent by the acquisition scheduling framework, obtain the service address of the acquisition scheduling framework.

[0052] The first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independent running process.

[0053] It is understandable that after the acquisition scheduling framework sends the first driver request, the acquisition driver can respond to the first driver request and obtain the service address of the acquisition scheduling framework (such as the metadata interface Uniform Resource Locator (URL), data upload interface URL, etc.).

[0054] S202, based on the service address, send a task request to the data collection and scheduling framework; Specifically, after obtaining the service address of the data acquisition and scheduling framework, the data acquisition driver can call the metadata interface URL based on the service address to send a task request to the data acquisition and scheduling framework.

[0055] S203, Receive target structured task metadata issued by the acquisition and scheduling framework based on the task request; Specifically, after receiving a task request, the data acquisition and scheduling framework can distribute the task metadata related to the data acquisition driver in the target structured format.

[0056] S204. Obtain the collected data based on the task metadata and upload the collected data to the collection scheduling framework. The format of the collected data is the target structured format.

[0057] Specifically, after receiving the task metadata, the acquisition driver can cache the task metadata in its own process memory, obtain the acquisition data based on the cached task metadata, and then upload the acquisition data to the acquisition scheduling framework in the target structured format.

[0058] According to the technical solution provided in this application, since the acquisition driver is an independently running process, when adding new devices or protocols, only the corresponding acquisition driver needs to be developed and configured into the acquisition scheduling framework. This eliminates the need for extensive modifications or redevelopment of the entire acquisition system, thereby improving the protocol compatibility of the acquisition system, achieving loose coupling of the data acquisition system, enhancing system scalability, and reducing system maintenance costs. Simultaneously, the task metadata and acquisition data with a target structured format make data processing more standardized and efficient, improving the accuracy and reliability of data acquisition, and thus enhancing the reliability of the entire acquisition system. In some embodiments, the task metadata includes the metadata of the device to be collected and the metadata of the information to be collected. Obtaining the collected data based on the task metadata includes: Establish a communication connection with the device to be collected based on the metadata of the device to be collected; obtain the collected data from the device based on the metadata of the information to be collected.

[0059] Specifically, the task metadata includes metadata for the device to be acquired and metadata for the information to be acquired. The metadata for the device to be acquired corresponds to the information about the device, and the metadata for the information to be acquired corresponds to the information about the data to be acquired. Therefore, the metadata for the device to be acquired contains information about the device (e.g., device IP address or device name), and the metadata for the information to be acquired contains information about the data to be acquired (e.g., data type, acquisition point location, acquisition frequency, data precision, and other key parameters). Thus, the acquisition driver establishes a communication connection with the device to be acquired based on the metadata for the device to be acquired, and obtains the acquired data from the device based on the metadata for the information to be acquired.

[0060] In this way, the acquisition driver can accurately locate the device that needs to collect data and collect data according to the predetermined parameters, ensuring the accuracy and completeness of the data collection. Furthermore, because the acquisition driver interacts with the acquisition scheduling framework through explicit service addresses and task metadata, the entire data acquisition process is clearer and more controllable, facilitating system maintenance and optimization.

[0061] Meanwhile, since the acquisition drivers are independent processes, they do not interfere with each other. When one acquisition driver fails, it will not affect the normal operation of other acquisition drivers, thereby improving the stability and reliability of the entire system.

[0062] In some embodiments, after uploading the collected data to the collection scheduling framework, the method further includes: Receive the second drive request issued by the acquisition scheduling framework. The second drive request is of the same type as the first drive request. The second drive request is a control instruction in a target structured format. Execute the target operation according to the control instruction and send the feedback result after the target operation to the acquisition scheduling framework.

[0063] Specifically, after the acquisition driver uploads the acquired data to the acquisition scheduling framework, it can receive a second driver request issued by the acquisition scheduling framework.

[0064] The second drive request is of the same type as the first drive request, and the second drive request is a control instruction in the target structured format; then According to the control command, the target operation is executed, which includes at least one of the following: controlling the acquisition driver to start the device, stop the device, send data, read data, and change metadata.

[0065] Finally, the acquisition driver executes the target operation according to the control command and sends the feedback result after the target operation to the acquisition scheduling framework to complete the closed-loop management of the entire data acquisition process.

[0066] Figure 3 This is a logical interaction diagram illustrating another multi-protocol data acquisition method, as shown in an exemplary embodiment of the present invention. For example... Figure 3 As shown, this exemplary multi-protocol data acquisition method includes: S301, Configure the IP and port of the driver. Specifically, the user can configure the configuration address (IP and port) of the acquisition driver in the acquisition scheduling framework.

[0067] S302, Return Configuration Result. Specifically, the data collection and scheduling framework returns the configuration result to the user, which can be displayed in a visual format.

[0068] S303, call the driver discovery interface. Specifically, the data acquisition scheduling framework sends a discovery request (e.g., a REST request) to the data acquisition driver based on the configured address.

[0069] S304, Update driver status to registered. Specifically, the acquisition driver can respond to the discovery request, register itself under the acquisition scheduling framework, and update its driver status to registered.

[0070] S305, returns driver information; specifically, the acquisition driver returns driver protocol information to the acquisition scheduling framework.

[0071] S306, Obtain task metadata. Specifically, the acquisition driver sends a task request to the acquisition scheduling framework to obtain the target structured task metadata.

[0072] S307, Returns task metadata. Specifically, the acquisition scheduling framework sends the target structured task metadata to the acquisition driver based on the task request.

[0073] S308 updates / saves task metadata. Specifically, after the acquisition driver obtains the task metadata, it updates / saves the task metadata in its own process memory.

[0074] S309, construct a data acquisition task based on task metadata. Specifically, the data acquisition driver constructs a data acquisition task for an external device (the device to be acquired) based on the task metadata.

[0075] S310, data acquisition; specifically, the acquisition driver acquires data based on the constructed acquisition task.

[0076] S311, Return Acquired Data. Specifically, the external device (the device to be acquired) returns the acquired data to the acquisition driver.

[0077] S312, Unified Data Format, specifically, after the acquisition driver obtains the acquired data, it converts it into the target structured format.

[0078] S313, Upload Acquired Data. Specifically, the acquisition driver uploads the target structured data to the acquisition scheduling framework.

[0079] Furthermore, to better understand this application, an embodiment will be used to further illustrate this application, as follows: Take Modbus-TCP and OPC DA drivers as examples. Deployment: Users deploy modbus-driver (written in Go) and opcda-driver (written in Python) on two separate servers and configure the ports they listen on (e.g., 9090 and 9091).

[0080] Framework configuration: Add two driver configurations to the data acquisition and scheduling framework UI: 192.168.1.10:9090 and 192.168.1.11:9091.

[0081] Automatic discovery: After configuration is complete and the driver is enabled, send an HTTP POST request (e.g., the discover interface) to the two addresses mentioned above.

[0082] The request content is as follows: {"url"192.168.1.100:8080","metadataInterface":"api / metadata","uploadInterface":"api / upload"}).

[0083] Driver response: {"status":"success","protocol":"MODBUS_TCP"}.

[0084] Metadata retrieval: After receiving the framework address, modbus-driver calls http: / / 192.168.1.100:8080 / api / metadata to obtain the JSON configuration of the devices, locations, and collection frequency to be collected, and caches it.

[0085] Autonomous data collection and reporting: modbus-driver connects to the Modbus device according to the configuration, reads data every 5 seconds, processes the collected data into a unified JSON format, and then POSTs it to http: / / 192.168.1.100:8080 / api / upload.

[0086] Reverse control: When the user clicks "Start Device" in the framework UI, the framework sends a POST request to http: / / 192.168.1.10:9090 / control with the following body: {"command":"device_stop",command_id:"00-00-00-00",command_value:{device_id:"1"}}. The driver will initiate a data acquisition operation for device ID 1.

[0087] In addition to the "start device" operation, it can also execute reverse control commands such as "stop device", "send data", "read data", and "modify metadata".

[0088] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the process of the embodiments of this application.

[0089] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0090] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0091] Figure 4 This is a schematic diagram illustrating the structure of a multi-protocol data acquisition device according to an exemplary embodiment of the present invention. Figure 4 As shown, the exemplary multi-protocol data acquisition device includes: The first sending module 401 is configured to send a first driver request to the acquisition driver, wherein the first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independent running process. The first receiving module 402 is configured to receive driver protocol information sent by the acquisition driver based on the first driver request; The task distribution module 403 is configured to respond to a task request sent by the received acquisition driver and distribute the target structured format task metadata to the acquisition driver according to the driver protocol information. The second receiving module 404 is configured to receive the data uploaded by the acquisition driver, wherein the data is acquired by the acquisition driver based on the task metadata and the format of the data is the target structured format.

[0092] In some embodiments, the first sending module 401 is further configured to obtain the configuration address of the acquisition driver and send a first driver request to the acquisition driver according to the configuration address.

[0093] In some embodiments, the task distribution module 403 is further configured to determine the acquisition configuration information of the acquisition driver according to the driver protocol information, wherein the acquisition configuration information includes the device information to be acquired and the data information to be acquired; and to obtain the target structured format task metadata according to the device information to be acquired and the data information to be acquired.

[0094] The second receiving module 404 is also configured to, after receiving the collected data uploaded by the acquisition driver, further include: sending a second driving request to the acquisition driver, wherein the second driving request is of the same type as the first driving request, the second driving request is a control instruction in a target structured format, and the control instruction is used to instruct the acquisition driver to perform a target operation; and receiving the feedback result uploaded by the acquisition driver after performing the target operation.

[0095] Figure 5 This is a schematic diagram illustrating the structure of another multi-protocol data acquisition device, as shown in an exemplary embodiment of the present invention. Figure 5 As shown, the exemplary multi-protocol data acquisition device includes: Address acquisition module 501 is configured to obtain the service address of the acquisition scheduling framework in response to receiving a first driver request sent by the acquisition scheduling framework, wherein the first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independent running process. The second sending module 502 is configured to send a task request to the collection and scheduling framework based on the service address; The third receiving module 503 is configured to receive target structured format task metadata sent by the acquisition scheduling framework based on task requests; The data upload module 504 is configured to obtain the collected data based on the task metadata and upload the collected data to the collection scheduling framework, wherein the format of the collected data is the target structured format.

[0096] In some embodiments, the task metadata includes the metadata of the device to be collected and the metadata of the information to be collected. The data upload module 504 is also configured to establish a communication connection with the device to be collected based on the metadata of the device to be collected, and to obtain the collected data of the device to be collected based on the metadata of the information to be collected.

[0097] In some embodiments, the data upload module 504 is further configured to receive a second drive request issued by the acquisition scheduling framework, wherein the second drive request is of the same type as the first drive request and the second drive request is a control instruction in a target structured format; execute the target operation according to the control instruction, and send the feedback result after the target operation to the acquisition scheduling framework.

[0098] Embodiments of the present invention also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the methods provided in the above embodiments.

[0099] Figure 6 A schematic diagram of a computer system suitable for implementing embodiments of the present invention is shown. It should be noted that... Figure 6 The computer system 600 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0100] like Figure 6 As shown, the computer system 600 includes a Central Processing Unit (CPU) 601, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on a program stored in Read-Only Memory (ROM) 602 or a program loaded from Storage Section 608 into Random Access Memory (RAM) 603. The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An Input / Output (I / O) interface 605 is also connected to the bus 605.

[0101] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 604 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0102] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs various functions defined in the system of the present invention.

[0103] It should be noted that the computer-readable medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In the present invention, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0104] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0105] The units described in the embodiments of the present invention can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0106] Another aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer's processor, causes the computer to perform the method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0107] Another aspect of the present invention provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods described in the various embodiments above.

[0108] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the present invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the steps of the present invention.

Claims

1. A multi-protocol data acquisition method, characterized in that, Applied to the data acquisition and scheduling framework, including: Send a first driver request to the acquisition driver, wherein the first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independently running process; Receive the driver protocol information sent by the acquisition driver based on the first driver request; In response to the received task request sent by the acquisition driver, the target structured format task metadata is sent to the acquisition driver according to the driver protocol information; The system receives the data uploaded by the acquisition driver, wherein the data is acquired by the acquisition driver based on the task metadata, and the format of the data is the target structured format.

2. The method according to claim 1, characterized in that, Sending the first driver request to the acquisition driver includes: Obtain the configuration address of the acquisition driver; The first driver request is sent to the acquisition driver according to the configured address.

3. The method according to claim 1, characterized in that, Before sending the target structured format task metadata to the acquisition driver according to the driver protocol information, the method further includes: Based on the driver protocol information, the acquisition configuration information of the acquisition driver is determined, wherein the acquisition configuration information includes the device information to be acquired and the data information to be acquired; Based on the device information to be collected and the data information to be collected, the target structured format task metadata is obtained.

4. The method according to claim 1, characterized in that, After receiving the collected data uploaded by the acquisition driver, the process further includes: Send a second drive request to the acquisition driver, wherein the second drive request is of the same type as the first drive request, and the second drive request is a control instruction in the target structured format, the control instruction being used to instruct the acquisition driver to perform a target operation; Receive the feedback results uploaded after the acquisition driver performs the target operation.

5. A multi-protocol data acquisition method, characterized in that, Applied to acquisition drivers, including: In response to receiving a first driver request sent by the data acquisition scheduling framework, the service address of the data acquisition scheduling framework is obtained, wherein the first driver request is used to discover the data acquisition driver configured in the data acquisition scheduling framework, and the data acquisition driver is an independently running process; Based on the service address, a task request is sent to the data collection and scheduling framework; Receive the target structured format task metadata issued by the acquisition scheduling framework based on the task request; The collected data is obtained based on the task metadata and uploaded to the collection scheduling framework, wherein the format of the collected data is the target structured format.

6. The method according to claim 5, characterized in that, The task metadata includes the metadata of the device to be collected and the metadata of the information to be collected. Obtaining the collected data based on the task metadata includes: Establish a communication connection with the device to be collected based on the metadata of the device to be collected; Based on the metadata of the information to be collected, the collected data of the device to be collected is obtained.

7. The method according to claim 5, characterized in that, After uploading the collected data to the collection scheduling framework, the process further includes: Receive a second driving request issued by the acquisition scheduling framework, wherein the second driving request is of the same type as the first driving request, and the second driving request is a control instruction in the target structured format; The target operation is executed according to the control command, and the feedback result after the target operation is sent to the acquisition and scheduling framework.

8. A multi-protocol data acquisition device, characterized in that, Applied to the data acquisition and scheduling framework, including: The first sending module is configured to send a first driver request to the acquisition driver, wherein the first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independently running process. The first receiving module is configured to receive driver protocol information sent by the acquisition driver based on the first driver request; The task distribution module is configured to, in response to a received task request sent by the acquisition driver, distribute task metadata in a target structured format to the acquisition driver according to the driver protocol information. The second receiving module is configured to receive the acquisition data uploaded by the acquisition driver, wherein the acquisition data is acquired by the acquisition driver according to the task metadata, and the format of the acquisition data is the target structured format.

9. A multi-protocol data acquisition device, characterized in that, Applied to acquisition drivers, including: The address acquisition module is configured to obtain the service address of the acquisition scheduling framework in response to receiving a first driver request sent by the acquisition scheduling framework, wherein the first driver request is used to discover the acquisition driver configured in the acquisition scheduling framework, and the acquisition driver is an independently running process. The second sending module is configured to send a task request to the collection and scheduling framework based on the service address; The third receiving module is configured to receive target structured format task metadata sent by the acquisition scheduling framework based on the task request. The data upload module is configured to obtain collected data based on the task metadata and upload the collected data to the collection scheduling framework, wherein the format of the collected data is the target structured format.

10. An electronic device, characterized in that, include: One or more processors and a memory, wherein a computer program is stored in the memory, and when the one or more processors execute the computer program, the device performs the steps of the method as described in any one of claims 1 to 7.

Images