Data acquisition method and device, information processing equipment and power generation system

Abstract

The invention discloses a data acquisition method and device, information processing equipment and a power generation system. The method comprises the following steps: initializing a plurality of sub-threads; obtaining first equipment data corresponding to equipment on the first bus through the first sub-thread, and storing the first equipment data to a shared data pool; through the second sub-thread, obtaining a device message of the second bus and storing the device message to a message receiving queue; analyzing the message in the message receiving queue through a third sub-thread to obtain second equipment data, and storing the second equipment data to a shared data pool; and encoding the data in the shared data pool based on a preset protocol through the fourth sub-thread, and sending the encoded data to the target equipment through the second bus. According to the invention, the technical problem that the complexity of communication management is increased due to different data transmission formats and protocols caused by the fact that a fixed power generation system comprises a plurality of different devices which may adopt different communication interfaces is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of power generation, and in particular, to a data acquisition method, apparatus, information processing device, and power generation system. Background Art

[0002] A fixed power generation system may include a variety of different devices, such as hydrogen fuel cells, inverters, fire-fighting equipment, storage batteries, etc. These devices may use different communication interfaces, such as RS485, CAN, etc., resulting in inconsistent data transmission formats and protocols, increasing the complexity of communication management.

[0003] In view of the above problems, no effective solution has been proposed yet. Summary of the Invention

[0004] Embodiments of the present invention provide a data acquisition method, apparatus, information processing device, and power generation system to at least solve the technical problem that a fixed power generation system includes a variety of different devices, and these devices may use different communication interfaces, resulting in inconsistent data transmission formats and protocols, increasing the complexity of communication management.

[0005] According to one aspect of the embodiments of the present invention, a data acquisition method is provided, including: initializing a plurality of sub-threads, where the plurality of sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread; obtaining first device data corresponding to devices on a first bus through the first sub-thread and storing the first device data in a shared data pool; obtaining device messages of a second bus through the second sub-thread and storing the device messages in a message receiving queue; parsing the messages in the message receiving queue through the third sub-thread to obtain second device data and storing the second device data in the shared data pool; encoding the data in the shared data pool based on a preset protocol through the fourth sub-thread and sending the encoded data to a target device through the second bus.

[0006] Optionally, through a fifth sub-thread, receiving a data request from a configuration screen, and selecting corresponding data from the shared data pool based on the data request to respond to the configuration screen, where the fifth sub-thread is included in the plurality of sub-threads.

[0007] Optionally, through a sixth sub-thread, selecting data to be collected from the shared data pool, adding the data to be collected to a data collection message queue, where the sixth sub-thread is included in the plurality of sub-threads; taking out the data to be collected from the data collection message queue through a seventh sub-thread, converting the data to be collected into a preset format to obtain target data, and sending the target data to a data collection server, where the seventh sub-thread is included in the plurality of sub-threads.

[0008] Optionally, through the eighth sub-thread, status data is selected from the shared data pool and sent to the remote control server, where the sub-threads include the eighth sub-thread.

[0009] Optionally, through the ninth sub-thread, an instruction sent by the remote control server is received, and corresponding operations are performed based on the instruction. The operations corresponding to the instruction include at least one of the following: start, shutdown. The sub-threads include the ninth sub-thread.

[0010] According to another aspect of the embodiments of the present invention, an information processing device is further provided, including: a shared data pool for storing first device data and second device data; an interface unit for providing an interface to connect to the first bus and the second bus; a network interface unit for connecting to a data acquisition server and a remote control server; a processor unit for applying any one of the above data acquisition methods.

[0011] According to another aspect of the embodiments of the present invention, a power generation system is further provided, including: a data acquisition server, a remote control server, a hydrogen fuel cell controller, a configuration screen, a storage battery, and the above information processing device. The data acquisition server and the remote control server are connected to the information processing device through a network; the storage battery is connected to the information processing device through the first bus; the hydrogen fuel cell controller is connected to the information processing device through the second bus; the configuration screen is connected to the information processing device through the third bus.

[0012] According to another aspect of the embodiments of the present invention, a data acquisition device is further provided, including: an initialization module for initializing a plurality of sub-threads, where the plurality of sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread; a first acquisition module for acquiring first device data corresponding to a device on the first bus through the first sub-thread and storing the first device data in the shared data pool; a second acquisition module for acquiring device messages on the second bus through the second sub-thread and storing the device messages in the message reception queue; a parsing module for parsing the messages in the message reception queue through the third sub-thread to obtain second device data and storing the second device data in the shared data pool; a sending module for encoding the data in the shared data pool based on a preset protocol through the second bus and sending it to a target device through the fourth sub-thread.

[0013] According to yet another aspect of the embodiments of the present invention, a non-volatile storage medium is further provided. The non-volatile storage medium includes a stored program, where when the program runs, it controls the device where the non-volatile storage medium is located to execute any one of the above data acquisition methods.

[0014] According to another aspect of the embodiments of the present invention, a computer device is further provided. The computer device includes a processor for running a program, and when the program runs, it executes any one of the above data acquisition methods.

[0015] According to another aspect of the embodiments of the present invention, a computer program product is further provided, including a computer program which, when executed by a processor, implements any one of the above data acquisition methods.

[0016] In the embodiments of the present invention, by adopting the data acquisition method, multiple child threads are initialized, where the multiple child threads at least include a first child thread, a second child thread, a third child thread, and a fourth child thread; through the first child thread, the first device data corresponding to the device on the first bus is obtained and stored in the shared data pool; through the second child thread, the device message on the second bus is obtained and stored in the message receiving queue; through the third child thread, the message in the message receiving queue is parsed to obtain the second device data and stored in the shared data pool; through the fourth child thread, the data in the shared data pool is encoded based on a preset protocol and sent to the target device through the second bus. The purpose of adapting to the communication characteristics of different devices is achieved by using different child threads, thereby improving the technical effect of communication efficiency, and further solving the technical problem that a fixed power generation system includes multiple different devices, which may adopt different communication interfaces, resulting in inconsistent data transmission formats and protocols and increasing the complexity of communication management. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation to the present invention. In the drawings:

[0018] Figure 1 A hardware structure block diagram of a computer terminal for implementing the data acquisition method is shown;

[0019] Figure 2 It is a flowchart of the data acquisition method provided by the embodiments of the present invention;

[0020] Figure 3 It is a device schematic diagram of an information processing device provided by the embodiments of the present invention;

[0021] Figure 4 It is a system architecture diagram of a power generation system provided by the embodiments of the present invention;

[0022] Figure 5 It is a data flow diagram provided by an alternative embodiment of the present invention;

[0023] Figure 6 It is a structural block diagram of a data acquisition device provided according to an embodiment of the present invention. Detailed implementation manners

[0024] In order to enable those skilled in the art to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0025] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0026] First, some nouns or terms that appear in the process of describing the embodiments of the present application are applicable to the following explanations:

[0027] Shared data pool: The memory area in the program for storing the status data of each component and peripheral devices.

[0028] T-Box, that is, Telematics Box, can also be called a telematics control box. The core role of T-Box is to serve as a communication bridge between the device and the remote server. It can collect data such as the running status, location information, and health status of the device, and send this data to the cloud server or monitoring center through wireless or wired networks. At the same time, T-Box can also receive instructions from the remote server to achieve remote control and management of the device, such as software upgrade, parameter adjustment, fault diagnosis, etc.

[0029] According to an embodiment of the present invention, a method embodiment of a data acquisition method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in a different order than here.

[0030] The method embodiment provided in the first embodiment of this application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Figure 1 The following shows a hardware structure block diagram of a computer terminal for implementing a data collection method. As Figure 1 shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b,..., 102n in the figure, and the processor may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), and a memory 104 for storing data. In addition, it may further include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply, and / or a camera. Those of ordinary skill in the art can understand that Figure 1 the structure shown is only schematic and does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 10 may further include more or fewer components than Figure 1 shown, or have a different configuration from Figure 1 shown.

[0031] It should be noted that the above one or more processors and / or other data processing circuits are generally referred to as "data processing circuits" in this article. The data processing circuit may be embodied in software, hardware, firmware, or any combination thereof, in whole or in part. In addition, the data processing circuit may be a single independent processing module, or be incorporated in whole or in part into any one of the other elements in the computer terminal 10. As involved in the embodiments of this application, the data processing circuit is used for processor control (such as the selection of a variable resistance terminal path connected to an interface).

[0032] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the data collection method in the embodiments of the present invention. The processor runs the software programs and modules stored in the memory 104 to perform various functional applications and data processing, that is, to implement the data collection method of the above application program. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely set relative to the processor, and these remote memories can be connected to the computer terminal 10 through a network. Examples of the above network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0033] The display can be, for example, a touch-screen liquid crystal display (LCD), which enables a user to interact with the user interface of the computer terminal 10.

[0034] Figure 2 It is a schematic flowchart of the data acquisition method provided according to an embodiment of the present invention. As Figure 2 shown, the method includes the following steps:

[0035] Step S202, initialize multiple sub-threads. Among them, the multiple sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread.

[0036] In this step, multiple sub-threads can be initialized by the main thread. Specifically, a thread library can be initialized. This is usually done when the program starts to ensure that the thread management and scheduling mechanisms are available. Then, for each sub-thread, a thread function (the execution body of the thread) can be defined, and this function will be executed when the thread is scheduled. At the same time, parameters need to be prepared for each thread, and these parameters will be passed to the thread function to initialize the thread state or control the thread behavior. Attributes such as thread priority and scheduling policy can be set for each sub-thread to optimize the execution order and efficiency of the thread on the CPU. After ensuring that all sub-threads are ready, they can be started and run. Once all sub-threads are created, they will start executing their respective thread functions until they are explicitly terminated or the program ends. Through these steps, it can be ensured that multiple sub-threads in the T-Box communication software can work together to handle various communication tasks, including data collection, message reception and sending, data parsing, and remote control, so as to achieve efficient and stable data transmission and device control functions.

[0037] Step S204, through the first sub-thread, obtain the first device data corresponding to the device on the first bus and store the first device data in the shared data pool.

[0038] In this step, through the first sub-thread, the device data of the devices connected to the first bus can be obtained, that is, the first device data. The first bus can be an RS485 bus. RS485 (also known as TIA / EIA-485 or EIA-485) is a balanced differential signal transmission standard, mainly used for data communication over long distances and between multiple points. The devices connected to it can be fire-fighting devices, inverters, storage batteries and other devices. The first sub-thread can be a device data collection thread. Focusing on the interaction in the RS485 bus environment, this thread continuously polls various devices on the bus, collects their status information and data, and then securely stores the obtained data in the shared data pool for subsequent processing and use. The shared data pool can be a memory area composed of data structures such as arrays, linked lists or hash tables, and it is necessary to ensure its access security in a multi-threaded environment. In the thread function of the first sub-thread, a mutex can be set for data pool access to avoid data competition and inconsistency caused by multiple threads accessing the data pool simultaneously. When the first sub-thread collects data, the access to the data pool is protected by the mutex to ensure that the data is securely stored. Then the first device data is formatted or converted into the format required by the shared data pool, and then stored in the data pool. The mutex is released to allow other threads to access the shared data pool.

[0039] Through the above steps, the first sub-thread can effectively collect device data from the first bus such as the RS485 bus and securely store it in the shared data pool, providing real-time device status information for other sub-threads or external systems.

[0040] Step S206, through the second sub-thread, obtain the device messages of the second bus and store the device messages in the message receiving queue.

[0041] In this step, the device messages of the second bus can be obtained through the second sub-thread. Here, the second bus can be a CAN bus. The second sub-thread can be a CAN message receiving thread. This thread specifically monitors the message dynamics on the CAN bus. Once a new valid message is detected, it is captured and added to a dedicated CAN message receiving queue. This process ensures the real-time performance and integrity of CAN communication data. The CAN (Controller Area Network) bus is a serial communication protocol for real-time applications, originally designed for communication between in-vehicle devices and now widely used in other industrial fields.

[0042] Because the RS485 bus and the CAN bus use different communication protocols and physical interfaces. RS485 uses half-duplex differential signal transmission, while the CAN bus supports full-duplex communication and has a complex message priority handling mechanism. Due to the significant differences in their communication methods and data formats, using independent sub-threads can better adapt to their respective characteristics and provide customized data acquisition and processing logic.

[0043] Step S208, through the third sub-thread, parse the messages in the message reception queue to obtain the second device data and store the second device data in the shared data pool.

[0044] In this step, the messages in the message reception queue can be parsed through the third sub-thread, where the third sub-thread can be a CAN message parsing thread. Immediately following CAN message reception, this thread sequentially retrieves messages from the filled CAN message queue (message reception queue), decodes them using predefined parsing rules, extracts the valid data, and stores it in the shared data pool for access by other threads or system components.

[0045] Specifically, after retrieving the messages from the CAN message reception queue, the third sub-thread can parse these messages. The parsing process may include identifying the message ID, checking the data length, decoding the data fields, etc., depending on the specific communication protocol used by the devices in the CAN bus. The result of message parsing is the extraction of the second device data, i.e., the status information and control data of the device connected to the CAN bus. The parsed second device data may need to be converted to a unified data format in the shared data pool. This step ensures the consistency and compatibility of all device data during storage and subsequent processing. A mutex or other synchronization mechanism can be used to protect the shared data pool to avoid data competition and inconsistency issues that may occur when multiple threads access the data pool simultaneously. Store the parsed second device data in the shared data pool in a secure manner. Once the data storage is complete, immediately release the mutex to allow other threads to access the shared data pool.

[0046] Step S210, through the fourth sub-thread, encode the data in the shared data pool based on a preset protocol and send it to the target device through the second bus.

[0047] In this step, the sub-thread 4, namely the CAN data sending thread, its core responsibility is to encode the data stored in the shared data pool according to the preset CAN (Controller Area Network) communication protocol, and then send it to the target device through the CAN bus. This process ensures the correct format, complete content, and efficient transmission of data during the transmission process. The sub-thread 4 can extract the data that needs to be sent through the CAN bus from the shared data pool periodically or triggered by specific events. These data may include key information such as device status, performance indicators, environmental parameters, operation records, etc. The extracted data will be encoded according to the CAN protocol standard. The CAN protocol defines the format of the message frame, including ID (identifier), data length, data field, CRC (Cyclic Redundancy Check), etc., to ensure the accuracy and reliability of data transmission on the CAN bus. The encoded data is packed into a frame format that conforms to the CAN protocol and is ready to be transmitted through the network. If the data volume is large, it may be necessary to split it into multiple frames for transmission. The sub-thread 4 sends the packed data frame to the CAN bus through the CAN controller, and the target device (such as the hydrogen fuel cell controller) can listen to the bus and receive these data packets. During the data sending process, if a transmission error is detected, such as data packet loss or CRC check failure, the sub-thread 4 will re-send the data until it is confirmed that the data has been successfully transmitted.

[0048] Through the efficient operation of the sub-thread 4, the T-BOX of the stationary power generation device can communicate stably and quickly with the devices on the CAN bus, ensuring the real-time monitoring and control capabilities of the entire system. This design not only improves the reliability of data transmission, but also optimizes the utilization of resources, reduces communication latency, and provides a solid technical support for the intelligent management of the power generation device.

[0049] Through the above steps, the data response thread can realize the data interaction between the data acquisition server and the T-Box, ensuring that the server can obtain the device data in the shared data pool in a timely and accurate manner. This design not only improves the response speed and data transmission efficiency of the system, but also enhances the stability of the system and the security of data, and is an important part of the T-Box communication software design.

[0050] Through the above steps, the purpose of adapting to the communication characteristics of different devices by using different sub-threads can be achieved, thus improving the technical effect of communication efficiency. Furthermore, it solves the technical problem that the fixed power generation system contains a variety of different devices, and these devices may adopt different communication interfaces, resulting in inconsistent data transmission formats and protocols, increasing the complexity of communication management.

[0051] As an alternative embodiment, the fifth sub-thread receives the data request from the configuration screen and selects the corresponding data from the shared data pool based on the data request, and responds to the configuration screen, where the fifth sub-thread is included in the multiple sub-threads.

[0052] Optionally, sub-thread 5 (configuration screen response thread) is a very crucial component in the T-BOX communication software design method. Its main functions include receiving the data requests sent by the configuration screen, selecting the corresponding data from the shared data pool according to these requests for processing, and then responding the processed data to the configuration screen to achieve real-time data interaction between the configuration screen and other parts of the system.

[0053] The configuration screen serves as the human-machine interface of the fixed power generation device. When the operator queries the device status or adjusts parameters, the configuration screen sends data requests to the T-BOX. These requests may involve information such as the working status of the hydrogen fuel cell, the power output of the inverter, and the remaining capacity of the battery. Sub-thread 5 is responsible for listening for these requests and immediately starts processing once a request is received. Sub-thread 5 retrieves the information that matches the request data type from the shared data pool. The shared data pool is an area that centrally stores all device data and is continuously updated by other sub-threads (such as sub-thread 1, sub-thread 2, sub-thread 3, etc.). Sub-thread 5 filters out the required data from the data pool according to the specific content of the request, performs necessary format conversion and processing to meet the display requirements of the configuration screen. The processed data will be packaged by sub-thread 5 and sent back to the configuration screen to update the display interface, enabling the operator to monitor the status of the power generation device in real time. In addition, sub-thread 5 can also receive control commands or operation instructions sent by the configuration screen. After being verified and processed, these instructions will also be stored in the shared data pool for other sub-threads to read and execute.

[0054] Through the efficient operation of sub-thread 5, real-time data interaction between the configuration screen and each component of the fixed power generation device is achieved, improving the work efficiency of the operator and the management convenience of the power generation system.

[0055] As an alternative embodiment, the sixth sub-thread selects the data to be collected from the shared data pool and adds the data to be collected to the data collection message queue, where the sixth sub-thread is included in the multiple sub-threads; the seventh sub-thread takes out the data to be collected from the data collection message queue, converts the data to be collected into a preset format to obtain the target data, and sends the target data to the data collection server, where the seventh sub-thread is included in the multiple sub-threads.

[0056] Optionally, the sub-thread 6, i.e., the data acquisition preparation thread, is responsible for screening the data to be acquired from the shared data pool. This data includes the operating status, performance parameters, environmental monitoring information, and operation records of the power generation device and its components. The sub-thread 6 sorts out this data to be acquired and adds it to the data acquisition message queue to prepare for subsequent data upload. The sub-thread 6 selects the data to be acquired related to data acquisition from the shared data pool according to preset rules or strategies. This may involve data filtering, cleaning, and format standardization to ensure the accuracy and consistency of the data. After the selected data to be acquired is formatted, it will be added to a data acquisition message queue and managed according to the first-in, first-out (FIFO) principle. This queue mechanism helps to process the data in an orderly manner and avoid data synchronization conflicts. The sub-thread 6 can also be responsible for managing the data acquisition message queue, including filling and maintaining the queue, and handling abnormal situations in the queue, such as queue overflow or idleness.

[0057] The sub-thread 7, i.e., the data acquisition and upload thread, follows the work of the sub-thread 6 and is responsible for taking out and processing this data to be acquired from the data acquisition message queue. Finally, it converts the data into target data in a preset format and then transmits it to the data acquisition server through the network. This process ensures the remote centralized storage and analysis of the data, providing data support for system operation and maintenance and performance optimization. The sub-thread 7 continuously monitors the data acquisition message queue. Once data is added to the queue, it immediately processes it. After taking out the data to be acquired from the queue, the thread 7 converts the data into the target data format according to the preset data format conversion rules. This may involve encoding, compressing, or encrypting the original data to improve the transmission efficiency and data security. The converted target data will be securely sent to the data acquisition server through network protocols (such as TCP / IP, MQTT, etc.). The sending process may include packet fragmentation, transmission control, error detection, and retransmission mechanisms to ensure the integrity and reliability of the data. After the data is successfully sent, the sub-thread 7 will record the sending status and can feedback the result to the main thread or other relevant sub-threads to update the communication log and ensure the integrity of the data acquisition process.

[0058] Through the cooperation of the sub-thread 6 and the sub-thread 7, the fixed power generation device can achieve efficient and orderly data acquisition and remote transmission, providing a solid data foundation for remote monitoring and data analysis. This design not only considers the efficiency and security of data transmission but also reflects the advantages of the multi-threaded architecture in processing complex data streams.

[0059] As an alternative embodiment, the status data is selected from the shared data pool and sent to the remote control server through the eighth sub-thread, where the sub-threads include the eighth sub-thread.

[0060] Optionally, the sub-thread 8, i.e., the remote control status data sending thread, is responsible for selecting data related to the status of the fixed power generation device from the shared data pool and sending this data to the remote control server to support remote monitoring and management. This thread is designed following the principles of efficiency, security, and real-time, ensuring that the remote control server can obtain the core status information of the device in a timely manner.

[0061] The sub-thread 8 accesses the shared data pool regularly or on demand, and filters out the status data related to remote control from it. These data may include, but are not limited to, the operating status of the power generation module, the charge and discharge status of the battery, the efficiency of the inverter, system health diagnosis information, environmental monitoring data, and any alarm or abnormal records. The extracted status data needs to be formatted according to the communication protocol of the remote control server. This may involve operations such as data encoding, compression, and encryption to ensure the security and integrity of the data during network transmission. The status data after format conversion is packaged into a format suitable for network transmission and then sent to the remote control server through the network interface. This process may use TCP / IP, UDP, or other network protocols, depending on the specific application scenario and communication requirements. The sub-thread 8 needs to manage the network connection with the remote control server to ensure the stability of the connection and the continuity of data transmission. In case of network interruption, packet loss, or server response timeout, etc., the thread 8 should have a reconnection mechanism and the ability to resend data to ensure the timely update of the status data.

[0062] For the convenience of troubleshooting and system maintenance, the sub-thread 8 will record the detailed information of each data transmission, including the sending time of the data packet, the receiving confirmation time, any communication errors or abnormal situations, etc., to form a communication log. Considering the limitations of network bandwidth and server processing capabilities, the sub-thread 8 also needs to intelligently adjust the data sending frequency and data volume to avoid network congestion or server overload, while ensuring the real-time and effectiveness of the data.

[0063] Through the operation of the sub-thread 8, the remote control server can obtain the real-time status data of the fixed power generation device, thereby performing data analysis, fault warning, system optimization, and remote operation, greatly improving the intelligent management level and operation efficiency of the power generation device.

[0064] As an optional embodiment, through the ninth sub-thread, receive the instructions issued by the remote control server and perform corresponding operations based on the instructions. Among them, the operations corresponding to the instructions include at least one of the following: start, shutdown. Among them, the sub-thread includes the ninth sub-thread.

[0065] Optionally, the sub-thread 9 (remote control command receiving thread) plays a crucial role in the T-BOX communication software design. It is responsible for receiving instructions from the remote control server and performing corresponding operations based on these instructions. Specifically, its workflow is as follows: The sub-thread 9 continuously monitors the communication channel with the remote control server. When the server sends control instructions, such as "start" or "shutdown" commands, the sub-thread 9 will receive and parse these instructions to ensure understanding the requirements of the remote control server. The received instructions will be initially verified, including checking whether the instruction format is correct, whether it comes from an authorized remote control server, and whether the instruction is compatible with the current state of the power generation device. This is to ensure the safe and stable operation of the system and prevent illegal or incompatible instructions from affecting the system. The verified instructions will be securely stored in the shared data pool. The shared data pool, as the center of inter-thread communication, ensures that the instructions can be accessed by all relevant threads in the system, thus enabling the efficient distribution and execution of the instructions. The instructions stored in the shared data pool will be read and executed by other sub-threads responsible for specific operations (for example, sub-threads for controlling the power generation module, inverter, or battery). For example, the "start" instruction may be used to start the hydrogen fuel cell or adjust the power output of the inverter, while the "shutdown" instruction may be used to safely shut down the power generation device or enter the standby mode. Once the instructions are executed, the sub-thread 9 or other sub-threads performing specific operations will feedback the execution results or the current device state to the remote control server, forming a closed-loop communication process. This step is crucial to ensure that the remote control server can understand the instruction execution status in real time and perform subsequent operations as needed.

[0066] Through the precise operation of the sub-thread 9, the T-BOX can establish a stable and reliable communication connection with the remote control server, ensuring that the latter can remotely monitor and control the fixed power generation device. This design not only ensures the real-time and accuracy of remote control but also enhances the security and stability of the system, which is an important means for remote management and maintenance of the power generation device.

[0067] In addition to the above RS485 and CAN buses, and the threads already described, different types of communication interface devices that are currently incompatible with the system can be integrated by simply adding interfaces and corresponding threads, thereby improving the system's compatibility. For example, it is possible to add support for wireless communication, especially for communication between nearby devices. For example, data exchange with mobile devices, wireless sensors, or other wireless components can be achieved through Wi-Fi or Bluetooth interfaces. It is also possible to add Zigbee / Z-Wave interfaces. These wireless communication protocols are very popular in the fields of smart home and building automation and can be used to communicate with Zigbee or Z-Wave smart home devices to expand the intelligent control capabilities of fixed power generation devices. An HTTP / HTTPS interface can also be included. Through the HTTP or HTTPS interface, the T-BOX can interact with web services, supporting data query and remote control through web pages or APIs. Correspondingly, threads can also be added to handle the processing work of different interfaces. For example, for Wi-Fi / Bluetooth interfaces, threads for listening and sending data can be designed for data communication with wireless sensors or other wireless devices. For wireless communication protocols such as Zigbee / Z-Wave, threads are designed for data adaptation and transmission to ensure compatibility with these devices. If interaction with web services through the HTTP / HTTPS interface is required, dedicated threads can be designed to handle HTTP requests and responses to support the integration of the system with cloud platforms or web applications.

[0068] Through these extended interfaces and threads, its connection ability with the external world can be further enhanced, the overall communication efficiency and compatibility of the system can be improved, enabling it to adapt to more diverse communication requirements and scenarios.

[0069] A specific embodiment is given below as follows:

[0070] Main thread: The core thread. This thread acts as the startup and initialization engine of the program and is responsible for creating and activating all subsequent child threads. Its primary task is to create and configure necessary system resources such as shared data pools, message queues, etc. Subsequently, the remaining nine working threads are started one by one to lay the operating foundation for the entire multi-threaded system.

[0071] Child thread 1: Device data collection thread. Focusing on the interaction in the RS485 bus environment, this thread continuously polls various devices on the bus, collects their status information and data, and then securely stores the obtained data in the shared data pool for subsequent processing.

[0072] Sub-thread 2: CAN Message Reception Thread. This thread specifically monitors the message dynamics on the CAN bus. Once a new valid message is detected, it captures and adds it to a dedicated CAN message reception queue. This process ensures the real-time nature and integrity of CAN communication data.

[0073] Sub-thread 3: CAN Message Parsing Thread. Immediately following the reception of CAN messages, this thread retrieves messages one by one from the filled CAN message queue, decodes them using predefined parsing rules, extracts the valid data, and stores it in the shared data pool for access by other threads or system components.

[0074] Sub-thread 4: CAN Data Transmission Thread. This thread is responsible for encoding and packing the data in the shared data pool according to the CAN protocol specifications, and then sending this data to the specified target via the CAN bus. This process serves as a bridge for data transfer from internal processing to external communication.

[0075] Sub-thread 5: Configuration Screen Response Thread. In response to data requests from the configuration screen, this thread retrieves the corresponding data from the shared data pool and directly responds to the configuration screen, enabling real-time data updates on the user interface and enhancing the user experience. At the same time, it receives real-time control instructions from the configuration screen and stores them in the shared data pool.

[0076] Sub-thread 6: Data Acquisition Preparation Thread. The task of this thread is to screen and organize the data to be sent from the shared data pool, and then add this data to the data acquisition message queue in an orderly manner to prepare for subsequent data upload.

[0077] Sub-thread 7: Data Acquisition Upload Thread. This thread is responsible for retrieving data from the data acquisition message queue, encoding it according to the established format, and securely sending it to the data acquisition server via the network protocol to ensure remote centralized storage and analysis of the data.

[0078] Sub-thread 8: Remote Control Communication Thread. This thread undertakes the communication task with the remote control server. It extracts the necessary status data from the shared data pool in real time and sends it to the remote control server to achieve the functions of remote monitoring and management.

[0079] Sub-thread 9: Remote Control Command Reception Thread. Focusing on receiving instructions from the remote control server, these instructions include system startup, shutdown, power adjustment, etc. After receiving the commands, this thread immediately stores them in the shared data pool for other threads to perform corresponding processing or responses as needed.

[0080] Through multi-threaded cooperation, the status information of each functional component is collected in real time and aggregated into a unified shared data pool, forming a data warehouse rich in information. According to the actual requirements of each device, different threads can flexibly retrieve the required information from this data pool and accurately send control instructions or data updates to their corresponding devices.

[0081] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be carried out in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0082] Through the description of the above embodiments, those skilled in the art can clearly understand that the data acquisition method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including several instructions for causing a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of the present invention.

[0083] According to another aspect of the embodiments of the present invention, an information processing device is further provided. Figure 3 It is a schematic diagram of the device of the information processing device provided according to the embodiments of the present invention, as Figure 3 shown, including:

[0084] A shared data pool for storing first device data and second device data.

[0085] An interface unit for providing interfaces to connect to the first bus and the second bus.

[0086] A network interface unit for connecting to a data acquisition server and a remote control server.

[0087] A processor unit for applying any one of the above data acquisition methods.

[0088] According to another aspect of the embodiments of the present invention, a power generation system is further provided. Figure 4 It is a system architecture diagram of the power generation system provided according to the embodiments of the present invention, as Figure 4As shown in the figure, it includes: a data acquisition server, a remote control server, a hydrogen fuel cell controller, a configuration screen, a storage battery, and the above information processing device, where:

[0089] The data acquisition server and the remote control server are connected to the information processing device through a network.

[0090] The storage battery is connected to the information processing device through a first bus.

[0091] The hydrogen fuel cell controller is connected to the information processing device through a second bus.

[0092] The configuration screen is connected to the information processing device through a third bus.

[0093] Among them, as Figure 4 shown, both the first bus and the third bus can be RS485, but the configuration screen and other devices will not be connected to the same RS485 bus. Except for the storage battery, other devices such as fire-fighting equipment and inverters can be connected to the information processing device through RS485.

[0094] Figure 5 is a data flow diagram provided according to an optional embodiment of the present invention. As Figure 5 shown, it shows the data transfer path and working process between each sub-thread in the T-BOX communication software design method in the fixed power generation device. The following is a detailed explanation based on this figure:

[0095] Main thread: The data flow is not directly shown in the figure, but the function of the main thread is to initialize the T-BOX communication software, start and manage the operation of the remaining sub-threads, and ensure the rationality of resource allocation and the coordination of operation between each sub-thread.

[0096] Sub-thread 1: Device data collection thread, responsible for collecting status information and data from devices (fire-fighting equipment, inverters, storage batteries, and other devices) on the RS485 bus, and then storing these data in the shared data pool.

[0097] Sub-thread 2: CAN message receiving thread, listening to the CAN bus, receiving messages from the hydrogen fuel cell controller, and storing them in the CAN message receiving queue.

[0098] Sub-thread 3: CAN message parsing thread, taking out messages from the CAN message queue, parsing them and storing them in the shared data pool to ensure that the messages can be correctly interpreted and available for other threads to use.

[0099] Sub-thread 4: CAN data sending thread, extracting data from the shared data pool, encoding according to the CAN protocol, and then sending it to the CAN bus to achieve data transmission to the hydrogen fuel cell controller.

[0100] Sub-thread 5: Configuration screen response thread, which obtains data from the shared data pool, responds to the data requests of the configuration screen, and at the same time receives the commands of the configuration screen and stores them in the shared data pool to achieve two-way communication with the configuration screen.

[0101] Sub-thread 6: Data acquisition preparation thread, which filters the required data from the shared data pool and stores it in the data acquisition message queue to prepare for subsequent data upload.

[0102] Sub-thread 7: Data acquisition and upload thread, which retrieves data from the data acquisition message queue, performs encoding conversion, and sends it to the data acquisition server through the network protocol to achieve remote centralized storage and analysis of data.

[0103] Sub-thread 8: Remote control communication thread, which extracts status data from the shared data pool and sends it to the MQTT remote control server to support remote monitoring and management functions.

[0104] Sub-thread 9: Remote control command receiving thread, which receives control instructions from the MQTT remote control server and stores them in the shared data pool for other sub-threads to respond according to the instructions.

[0105] According to an embodiment of the present invention, there is also provided a data acquisition device for implementing the above data acquisition method. Figure 6 It is a structural block diagram of the data acquisition device provided according to an embodiment of the present invention, as Figure 6 shown. The data acquisition device includes: an initialization module 602, a first acquisition module 604, a second acquisition module 606, a parsing module 608, and a sending module 610. The data acquisition device will be described below.

[0106] The initialization module 602 is used to initialize multiple sub-threads, where the multiple sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread.

[0107] The first acquisition module 604 is connected to the initialization module 602 and is used to obtain the first device data corresponding to the devices on the first bus through the first sub-thread and store the first device data in the shared data pool.

[0108] The second acquisition module 606 is connected to the initialization module 602 and is used to obtain the device messages of the second bus through the second sub-thread and store the device messages in the message receiving queue.

[0109] The parsing module 608 is connected to the second acquisition module 606 and is used to parse the messages in the message receiving queue through the third sub-thread to obtain the second device data and store the second device data in the shared data pool.

[0110] A sending module 610, connected to the initialization module 602, is configured to encode the data in the shared data pool based on a preset protocol through a fourth sub-thread and send the encoded data to a target device via a second bus.

[0111] It should be noted here that the above-mentioned initialization module 602, first acquisition module 604, second acquisition module 606, parsing module 608, and sending module 610 correspond to steps S202 to S210 in the embodiment. The instances and application scenarios implemented by the multiple modules and the corresponding steps are the same, but are not limited to the content disclosed in the above-mentioned embodiment. It should be noted that the above-mentioned modules, as part of the device, can run in the computer terminal 10 provided in the embodiment.

[0112] An embodiment of the present invention can provide a computer device. Optionally, in this embodiment, the above-mentioned computer device can be located in at least one of multiple network devices in a computer network. The computer device includes a memory and a processor.

[0113] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the data acquisition method and device in the embodiment of the present invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, implements the above-mentioned data acquisition method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory may further include a memory remotely set relative to the processor, and these remote memories can be connected to the computer terminal through a network. Examples of the above-mentioned network include but are not limited to the Internet, enterprise intranet, local area network, mobile communication network, and combinations thereof.

[0114] The processor can call the information and application programs stored in the memory through a transmission device to execute the following steps: initialize multiple sub-threads, where the multiple sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread; through the first sub-thread, acquire first device data corresponding to a device on a first bus and store the first device data in a shared data pool; through the second sub-thread, acquire device messages on a second bus and store the device messages in a message receiving queue; through the third sub-thread, parse the messages in the message receiving queue to obtain second device data and store the second device data in the shared data pool; through the fourth sub-thread, encode the data in the shared data pool based on a preset protocol and send the encoded data to a target device via a second bus.

[0115] Optionally, the above-mentioned processor may also execute the program code of the following steps: through the fifth sub-thread, receive the data request of the configuration screen, and select the corresponding data from the shared data pool to respond to the configuration screen, where the fifth sub-thread is included in the multiple sub-threads.

[0116] Optionally, the above-mentioned processor may also execute the program code of the following steps: through the sixth sub-thread, select the data to be collected from the shared data pool, and add the data to be collected to the data collection message queue, where the sixth sub-thread is included in the multiple sub-threads; through the seventh sub-thread, take out the data to be collected from the data collection message queue, convert the data to be collected into a preset format to obtain the target data, and send the target data to the data collection server, where the seventh sub-thread is included in the multiple sub-threads.

[0117] Optionally, the above-mentioned processor may also execute the program code of the following steps: through the eighth sub-thread, select the status data from the shared data pool and send it to the remote control server, where the eighth sub-thread is included in the sub-threads.

[0118] Optionally, the above-mentioned processor may also execute the program code of the following steps: through the ninth sub-thread, receive the instruction sent by the remote control server, and perform corresponding operations based on the instruction, where the operations corresponding to the instruction include at least one of the following: start, shutdown, where the ninth sub-thread is included in the sub-threads.

[0119] By adopting the embodiment of the present invention, a solution for a data collection method is provided. By initializing multiple sub-threads, where the multiple sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread; through the first sub-thread, obtain the first device data corresponding to the device on the first bus and store the first device data in the shared data pool; through the second sub-thread, obtain the device message of the second bus and store the device message in the message receiving queue; through the third sub-thread, parse the message in the message receiving queue to obtain the second device data and store the second device data in the shared data pool; through the fourth sub-thread, encode the data in the shared data pool based on a preset protocol and send it to the target device through the second bus, achieving the purpose of adapting to the communication characteristics of different devices by using different sub-threads, thereby improving the technical effect of communication efficiency, and further solving the technical problem that a fixed power generation system includes a variety of different devices, and these devices may use different communication interfaces, resulting in inconsistent data transmission formats and protocols, increasing the complexity of communication management.

[0120] Those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the relevant hardware of the terminal device through a program, and this program can be stored in a non-volatile storage medium. The storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, an optical disk, etc.

[0121] An embodiment of the present invention also provides a non-volatile storage medium. Optionally, in this embodiment, the above non-volatile storage medium can be used to store the program code executed by the data acquisition method provided in the above embodiment.

[0122] Optionally, in this embodiment, the above non-volatile storage medium can be located in any one of the computer terminals in the computer terminal group in the computer network, or in any one of the mobile terminals in the mobile terminal group.

[0123] Optionally, in this embodiment, the non-volatile storage medium is set to store program code for performing the following steps: initializing a plurality of sub-threads, where the plurality of sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread; through the first sub-thread, obtaining first device data corresponding to the devices on the first bus and storing the first device data in a shared data pool; through the second sub-thread, obtaining device messages on the second bus and storing the device messages in a message receiving queue; through the third sub-thread, parsing the messages in the message receiving queue to obtain second device data and storing the second device data in the shared data pool; through the fourth sub-thread, encoding the data in the shared data pool based on a preset protocol and sending it to the target device through the second bus.

[0124] Optionally, in this embodiment, the non-volatile storage medium is set to store program code for performing the following steps: through a fifth sub-thread, receiving a data request from a configuration screen and selecting corresponding data from the shared data pool to respond to the configuration screen, where the fifth sub-thread is included in the plurality of sub-threads.

[0125] Optionally, in this embodiment, the non-volatile storage medium is set to store program code for performing the following steps: through a sixth sub-thread, selecting data to be collected from the shared data pool and adding the data to be collected to a data collection message queue, where the sixth sub-thread is included in the plurality of sub-threads; through a seventh sub-thread, taking out the data to be collected from the data collection message queue, converting the data to be collected into a preset format to obtain target data, and sending the target data to a data collection server, where the seventh sub-thread is included in the plurality of sub-threads.

[0126] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: selecting status data from the shared data pool through the eighth sub-thread and sending the status data to the remote control server, where the sub-threads include the eighth sub-thread.

[0127] Optionally, in this embodiment, the non-volatile storage medium is configured to store program code for performing the following steps: receiving an instruction sent by the remote control server through the ninth sub-thread and performing corresponding operations based on the instruction, where the operations corresponding to the instruction include at least one of the following: start, shutdown, and the sub-threads include the ninth sub-thread.

[0128] An embodiment of the present invention further provides a computer program product, including a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it can implement: initializing multiple sub-threads, where the multiple sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread; obtaining first device data corresponding to devices on the first bus through the first sub-thread and storing the first device data in the shared data pool; obtaining device messages on the second bus through the second sub-thread and storing the device messages in the message receiving queue; parsing the messages in the message receiving queue through the third sub-thread to obtain second device data and storing the second device data in the shared data pool; encoding the data in the shared data pool based on a preset protocol and sending the encoded data to the target device through the second bus.

[0129] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages and disadvantages of the embodiments.

[0130] In the above embodiments of the present invention, the descriptions of the various embodiments have their own emphases. For parts not detailed in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0131] In several embodiments provided in the present application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only illustrative. For example, the division of the units can be a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the shown or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of units or modules can be in an electrical or other form.

[0132] The unit described as a separation component may or may not be physically separated. The component shown as a unit may or may not be a physical unit, that is, it may be located in one place or may be distributed to multiple units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0133] In addition, each functional unit in various embodiments of the present invention may be integrated into a processing unit, may exist separately as individual physical units, or two or more units may be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0134] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs, etc., which can store program codes.

[0135] The above is only the preferred embodiment of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. A data acquisition method, characterized in that, including: Initializing multiple sub-threads, where the multiple sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread; Through the first sub-thread, obtaining first device data corresponding to devices on the first bus and storing the first device data in a shared data pool; Through the second sub-thread, obtaining device messages on the second bus and storing the device messages in a message receiving queue; Through the third sub-thread, parsing the messages in the message receiving queue to obtain second device data and storing the second device data in the shared data pool; Through the fourth sub-thread, encoding the data in the shared data pool based on a preset protocol and sending it to a target device through the second bus.

2. The method according to claim 1, wherein It further includes: Through a fifth sub-thread, receiving a data request from a configuration screen, and selecting corresponding data from the shared data pool based on the data request to respond to the configuration screen, where the fifth sub-thread is included in the multiple sub-threads.

3. The method according to claim 1, wherein It further includes: Through a sixth sub-thread, selecting data to be collected from the shared data pool, adding the data to be collected to a data collection message queue, where the sixth sub-thread is included in the multiple sub-threads; Through a seventh sub-thread, taking out the data to be collected from the data collection message queue, converting the data to be collected into a preset format to obtain target data, and sending the target data to a data collection server, where the seventh sub-thread is included in the multiple sub-threads.

4. The method according to claim 1, wherein It further includes: Through an eighth sub-thread, selecting status data from the shared data pool and sending it to a remote control server, where the eighth sub-thread is included in the sub-threads.

5. The method according to claim 1, wherein It further includes: Through a ninth sub-thread, receiving an instruction issued by the remote control server and performing corresponding operations based on the instruction, where the operations corresponding to the instruction include at least one of the following: start, shutdown, where the ninth sub-thread is included in the sub-threads.

6. An information processing device, characterized in that, including: A shared data pool for storing first device data and second device data; An interface unit for providing interfaces to connect to the first bus and the second bus; A network interface unit for connecting to a data collection server and a remote control server; A processor unit for applying the data collection method described in any one of claims 1 to 5 above.

7. A power generation system, characterized in that, including: A data collection server, a remote control server, a hydrogen fuel cell controller, a configuration screen, a storage battery, and the information processing device described in claim 6, where The data collection server and the remote control server are connected to the information processing device through a network; The storage battery is connected to the information processing device through the first bus; The hydrogen fuel cell controller is connected to the information processing device through the second bus; The configuration screen is connected to the information processing device through the third bus.

8. A data acquisition device, characterized in that, including: An initialization module for initializing multiple sub-threads, where the multiple sub-threads at least include a first sub-thread, a second sub-thread, a third sub-thread, and a fourth sub-thread; A first acquisition module, configured to acquire first device data corresponding to devices on the first bus through the first sub-thread and store the first device data in a shared data pool; A second acquisition module, configured to acquire device messages on the second bus through the second sub-thread and store the device messages in a message reception queue; An analysis module, configured to analyze the messages in the message reception queue through the third sub-thread to obtain second device data and store the second device data in the shared data pool; A sending module, configured to encode the data in the shared data pool based on a preset protocol through the fourth sub-thread and send the encoded data to a target device through the second bus.

9. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein when the program runs, it controls the device where the non-volatile storage medium is located to execute the data acquisition method according to any one of claims 1 to 5.

10. A computer device, characterized in that, Comprising: A memory and a processor, The memory stores a computer program; The processor is configured to execute the computer program stored in the memory, and when the computer program runs, it causes the processor to execute the data acquisition method according to any one of claims 1 to 5.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the data acquisition method according to any one of claims 1 to 5.

Images