Construction method and device of data acquisition software and data acquisition system

By using object containers and device management interfaces, the reuse of hardware driver code and flexible adaptation of business processes in the aero-engine test stand data acquisition system were achieved. This solved the problems of low reusability and poor scalability of the acquisition business module, and improved the adaptability and R&D efficiency of the software.

CN121658083APending Publication Date: 2026-03-13AECC COMML AIRCRAFT ENGINE CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-08-26
Publication Date
2026-03-13

AI Technical Summary

Technical Problem

In existing aero-engine test stand data acquisition systems, the data acquisition modules have low reusability, inconsistent APIs, severe code coupling, and poor scalability, making it difficult to adapt to rapidly iterating business needs.

Method used

Hardware driver code reuse is achieved through object containers and device management interfaces. The device management interface is used to encapsulate the business processes such as registration, loading, and unloading of acquisition devices. Commands are issued through the main control interface to execute acquisition business, enabling flexible adaptation to different acquisition devices.

Benefits of technology

It improves the code reusability and scalability of data acquisition software, reduces development and maintenance costs, supports rapid iteration and the access of new devices, and meets the flexible configuration needs of various acquisition devices.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121658083A_ABST
    Figure CN121658083A_ABST
Patent Text Reader

Abstract

The invention provides a construction method and device of data acquisition software and a data acquisition system. The construction method of the data acquisition software comprises the following steps: carrying out initial configuration according to test requirements; packaging an acquisition equipment information implementation object related to the test requirement into an object container; using the object container to instantiate and collect the business implementation object; an acquisition service interface is called through an equipment management interface, so that hardware drive code multiplexing of different acquisition equipment is realized; and issuing a command to the equipment management interface through the main control interface, so that the equipment management interface executes an acquisition service corresponding to the test requirement.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of computers, and in particular to a method and apparatus for constructing data acquisition software and a data acquisition system. Background Technology

[0002] An aero-engine test cell is a specialized device used to test and evaluate the performance, reliability, and safety of aero-engines. The test cell's data acquisition system is a key component, responsible for collecting, recording, and analyzing the aero-engine's performance data under various operating conditions. The data acquisition system typically consists of multiple sensors, signal conditioning modules, and acquisition boards, used to measure engine test parameters such as thrust, temperature, engine speed, oil pressure, air pressure, differential pressure, and humidity. The processing and integration of these multi-channel signals are all handled by the data acquisition software. Summary of the Invention

[0003] The inventors noted that the sensor signals currently being acquired in experiments are diverse, necessitating the use of various acquisition scanning valves or boards in the data acquisition system. This means the data acquisition software needs to support multiple hardware drivers. Furthermore, even products from the same manufacturer may use different models of acquisition equipment or have different channel numbers depending on the experimental requirements. This necessitates that the data acquisition software implement different types and quantities of data acquisition and processing tasks based on changing needs. Additionally, the configuration and setup of an aero-engine test bench data acquisition system involves various processes, including requirements analysis, measurement scheme design, sensor selection and procurement, measurement scheme implementation, bench data acquisition system modification, and bench process system modification. Changes in any of these stages will impact the data acquisition software. Therefore, the relevant technologies have the following problems: First, the reusability of the data acquisition module is low. Each new type of scanning valve may require the redevelopment of the software itself or the hardware driver supporting the software. Second, the data acquisition APIs are not unified. Each data acquisition scanning valve or board defines its own set of APIs based on its own manufacturer's driver interface, and both the front-end and back-end need to develop and debug for each set of APIs. Third, the code for data acquisition task requests and data acquisition task execution is tightly coupled. For example, the business process of a certain model of scanning valve is hard-coded in the code logic of a working function. Once the business process of this model of scanning valve is adjusted or changed, all related code needs to be modified. Fourth, the software has poor scalability. When adding a brand new device or adding a certain function, changes and additions need to be made to the entire process code, which cannot meet the needs of the rapid iteration of business development of today's test bench systems.

[0004] Accordingly, this disclosure provides a method for constructing data acquisition software, which can flexibly construct data acquisition software according to experimental needs, effectively improving R&D efficiency.

[0005] In a first aspect of this disclosure, a method for constructing data acquisition software is provided, comprising: initializing the configuration according to experimental requirements; encapsulating acquisition device information implementation objects related to the experimental requirements into an object container; instantiating acquisition service implementation objects using the object container; calling the acquisition service interface through a device management interface to achieve hardware driver code reuse for different acquisition devices; and issuing commands to the device management interface through a main control interface so that the device management interface executes the acquisition service corresponding to the experimental requirements.

[0006] In some embodiments, reusing hardware driver code for different acquisition devices by calling the acquisition service interface through the device management interface includes: constructing the device management interface and encapsulating at least one of the business processes of registration, loading, unloading, startup, scanning, calibration, zeroing, and shutdown of the acquisition device into the device management interface; and calling the acquisition service interface through the device management interface and selecting the hardware driver code of the corresponding acquisition device according to the object container.

[0007] In some embodiments, the imported configuration file is parsed using the device management interface to identify the hardware configuration and channel configuration of the acquisition device; the parsed hardware configuration and channel configuration are encapsulated into the corresponding acquisition device information implementation object using the device management interface, and the acquisition device information interface pointer is stored in the object container to load the device entity information.

[0008] In some embodiments, after the device entity information has been used, the device entity information is deleted from the object container using the device management interface.

[0009] In some embodiments, when the device management interface starts the acquisition device, the total number of loaded devices is calculated, and a pointer array of acquisition service interfaces is requested; the device management interface instantiates an acquisition service implementation object using the object container according to the type of the acquisition device, and uses the pointer in the acquisition service interface pointer array to point to the acquisition service implementation object; the execution thread instantiated using the pointer array as a parameter returns the thread pointer of the execution thread; and the corresponding acquisition thread is called using the thread pointer.

[0010] In some embodiments, instantiating a data acquisition service implementation object using the object container includes: creating a data acquisition service interface; encapsulating data acquisition device information and the hardware driver of the data acquisition device into the data acquisition service interface; importing the object container into the data acquisition service interface so that the data acquisition device information interface pointer in the object container points to the data acquisition device information implementation object corresponding to the data acquisition device information; and instantiating the data acquisition service implementation object corresponding to the data acquisition service information using the configuration information in the data acquisition device information implementation object.

[0011] In some embodiments, encapsulating the data acquisition device information implementation object related to the test requirements into an object container includes: creating a data acquisition device information interface, wherein the data acquisition device information interface encapsulates the public information of the data acquisition device; and encapsulating the data acquisition device information interface pointer into the object container.

[0012] In some embodiments, the public information includes at least one of the following: the device name of the acquisition device, the global device serial number, and the device type.

[0013] In some embodiments, initial configuration according to test requirements includes: encapsulating the hardware configuration and channel configuration information of the acquisition device related to the test requirements to generate a configuration file; and performing initial configuration according to the configuration file.

[0014] In some embodiments, issuing commands to the device management interface through the main control interface includes: constructing the main control interface; using the operation method of the device management interface encapsulated in the main control interface to control the device management interface to register the acquisition device, start the acquisition and scanning process, and instantiate the device management interface; and using the operation method to call the business acquisition-related functions of the acquisition device in the device management interface.

[0015] In some embodiments, the operation method is used to control the device management interface to unload the acquisition device, stop the acquisition and scanning process, and the instantiated object of the device management interface.

[0016] In some embodiments, functions related to service acquisition include at least one of acquisition device registration, uninstallation, start acquisition, and stop acquisition.

[0017] In a second aspect of this disclosure, an apparatus for constructing data acquisition software is provided, comprising: a first processing module configured to perform initialization configuration according to experimental requirements; a second processing module configured to encapsulate acquisition device information implementation objects related to the experimental requirements into an object container; a third processing module configured to instantiate acquisition service implementation objects using the object container; a fourth processing module configured to call an acquisition service interface through a device management interface to achieve hardware driver code reuse for different acquisition devices; and a fifth processing module configured to issue commands to the device management interface through a main control interface so that the device management interface executes acquisition services corresponding to the experimental requirements.

[0018] In a third aspect of this disclosure, an apparatus for constructing data acquisition software is provided, comprising: a memory; and a processor coupled to the memory, the processor being configured to execute instructions stored in the memory to implement the method as described in any of the above embodiments.

[0019] In a fourth aspect of this disclosure, a data acquisition system is provided, comprising: an apparatus for constructing data acquisition software as described in any of the above embodiments.

[0020] In a fifth aspect of this disclosure, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any of the above embodiments.

[0021] In a sixth aspect of this disclosure, a computer program product is provided, including computer instructions, wherein the computer instructions, when executed by a processor, implement the method as described in any of the above embodiments.

[0022] Other features and advantages of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a method for constructing data acquisition software according to an embodiment of the present disclosure;

[0025] Figure 2 This is a flowchart illustrating a method for constructing data acquisition software according to another embodiment of this disclosure;

[0026] Figure 3 This is a schematic diagram of the structure of a data acquisition software construction apparatus according to an embodiment of the present disclosure;

[0027] Figure 4 This is a schematic diagram of the structure of a data acquisition software construction apparatus according to another embodiment of the present disclosure;

[0028] Figure 5 This is a schematic diagram of the structure of a data acquisition system according to an embodiment of the present disclosure. Detailed Implementation

[0029] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0030] Unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0031] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0032] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0033] In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0034] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0035] Figure 1 This is a flowchart illustrating a method for constructing data acquisition software according to an embodiment of the present disclosure. In some embodiments, the following method for constructing data acquisition software is executed by a data acquisition software construction apparatus, including steps 11-15.

[0036] In step 11, perform initial configuration according to the test requirements.

[0037] In some embodiments, the hardware configuration and channel configuration information of the acquisition device related to the test requirements are encapsulated to generate a configuration file, and the initial configuration is performed according to the configuration file.

[0038] In step 12, the acquisition equipment information related to the test requirements is encapsulated into an object container.

[0039] In some embodiments, the step of encapsulating the acquisition device information related to the test requirements into an object container includes the following steps.

[0040] 1) Create an interface for collecting device information, which encapsulates the public information of the collecting device.

[0041] For example, public information includes at least one of the following: the device name of the data collection device, the global device serial number, and the device type.

[0042] 2) Encapsulate the interface pointer for the data acquisition device into an object container.

[0043] For example, the device name and serial number of the LXI acquisition device Ex1048A are encapsulated in the acquisition device information interface. Correspondingly, parameters such as hardware trigger cycle, device SN (serial number) encoding, channel even type, and number of channels are encapsulated in the device information implementation class Ex1048.

[0044] In step 13, the data collection service implementation object is instantiated using an object container.

[0045] In some embodiments, the steps of instantiating a data collection service object using an object container include the following steps.

[0046] 1) Create a data collection service interface.

[0047] For example, this interface encapsulates the virtual function Execute for executing data collection services, and its subclass objects, i.e., data collection service implementation objects, provide the specific implementation of the data collection services.

[0048] 2) Encapsulate the data acquisition device information and the hardware driver of the data acquisition device into the data acquisition service interface.

[0049] It should be noted that the hardware driver of the acquisition device is encapsulated into the acquisition business implementation object, and then the hardware driver is integrated in sequence according to different business processes, thereby forming a variety of specific execution methods for acquisition business processes.

[0050] 3) Import the object container into the data acquisition business interface so that the data acquisition device information interface pointer in the object container points to the data acquisition device information implementation object corresponding to the data acquisition device information.

[0051] 4) Instantiate the collection service implementation object corresponding to the collection service information using the configuration information in the collection device information implementation object.

[0052] In step 14, the acquisition service interface is called through the device management interface to achieve the reuse of hardware driver code for different acquisition devices.

[0053] In some embodiments, a device management interface is constructed using the singleton pattern, encapsulating at least one of the business processes of registering, loading, unloading, starting, scanning, calibrating, zeroing, and shutting down the acquisition device into the device management interface. Next, the acquisition business interface is called through the device management interface, and the hardware driver code for the corresponding acquisition device is selected based on the object container.

[0054] It should be noted that the device management interface coordinates and triggers the execution objects of the data acquisition process, acting as an intermediary. It receives commands and requests from the business layer and delegates them to the corresponding objects for execution.

[0055] For example, the device management interface receives the initialization configuration and then passes it to the actual execution object, i.e., the data acquisition business interface. By using the device management interface, decoupling is achieved between the business layer and the specific execution object. The business layer does not need to know how the issued data acquisition device configuration is executed or by whom, and the execution object does not need to know the source of the business.

[0056] In some embodiments, the imported configuration file is parsed using a device management interface to identify the hardware and channel configurations of the acquisition device. Next, the parsed hardware and channel configurations are encapsulated into the corresponding acquisition device information implementation object using the device management interface, and the acquisition device information interface pointer is stored in the object container to load the device entity information. Furthermore, after the device entity information is no longer needed, it is deleted from the object container using the device management interface.

[0057] In some embodiments, when the device management interface starts the acquisition device, it calculates the total number of loaded devices and requests an array of pointers to acquisition service interfaces. Next, the device management interface instantiates acquisition service implementation objects using an object container according to the type of the acquisition device, and uses pointers from the acquisition service interface pointer array to point to these acquisition service implementation objects. Then, it instantiates an execution thread using the pointer array as a parameter, returns the thread pointer of the execution thread, and uses the thread pointer to call the corresponding acquisition thread.

[0058] In step 15, commands are sent from the main control interface to the device management interface so that the device management interface can perform data acquisition services corresponding to the test requirements.

[0059] In some embodiments, the step of issuing commands to the device management interface through the master control interface includes the following steps.

[0060] 1) Construct the main control interface.

[0061] 2) Utilize the operation methods of the device management interface encapsulated in the main control interface to control the device management interface to register acquisition devices, start the acquisition and scanning process, and instantiate the device management interface object.

[0062] In addition, the operation methods of the device management interface encapsulated in the main control interface can be used to control the device management interface to unload the acquisition device, stop the acquisition and scanning process, and instantiate the device management interface object.

[0063] 3) Use the operation method to call the functions related to business acquisition of the acquisition device in the device management interface.

[0064] For example, functions related to business data acquisition include at least one of the following: data acquisition device registration, uninstallation, data acquisition startup, and data acquisition stoppage.

[0065] In the data acquisition software construction method provided in the above embodiments of this disclosure, by encapsulating processes such as test configuration and operation scanning of acquisition equipment into a unified and standardized interface, and through flexible combinations of different configuration schemes and acquisition business processes, it is possible to flexibly adapt to multiple acquisition devices on the aero-engine test stand without modifying the business layer code. This enables excellent code reuse and allows the use of the same code to configure, package, and deploy corresponding hardware drivers for different acquisition devices and data acquisition systems, reducing development and maintenance costs and improving R&D efficiency. Simultaneously, it also allows for rapid integration of new acquisition device drivers during product iterations without changing existing business layer code, greatly improving the software's scalability.

[0066] The present disclosure will now be illustrated by an example.

[0067] Figure 2 This is a flowchart illustrating a method for constructing data acquisition software according to another embodiment of the present disclosure. In some embodiments, the following method for constructing data acquisition software is performed by a data acquisition software construction apparatus, including steps 21-28.

[0068] In step 21, initialize the configuration scheme.

[0069] This step involves configuring and initializing the data acquisition software, generating hardware and channel configuration files for the acquisition devices, and obtaining the software initialization configuration scheme. Using the ProtoBuffer framework, a proto file is written based on the device hardware list and parameters. Within the created proto file, acquisition device characteristics are placed in the "DeviceConfiguration" message, with different types of acquisition devices defined in different messages. For example, the LXI acquisition device EX1048A is placed in the "mEX1048" message. Other parameters of the data acquisition software are placed in the "SystemConfiguration" message. Based on this file, ProtoBuffer-related .h and .cc files are generated and compiled together with other data acquisition software source code to obtain the final configuration module. This module is used to write the acquisition device hardware and channel configuration into the configuration file as the software initialization configuration scheme.

[0070] In step 22, the acquisition device information is generated.

[0071] This step involves generating an implementation object for each acquisition device based on the software initialization configuration scheme. The acquisition device information interface supports importing configuration information from acquisition boards and scanning valves commonly used on aero-engine test benches such as LXI, PSI, and VTI. When generating the acquisition device information, a subclass object of the acquisition device information interface is constructed as the implementation object based on the software initialization configuration scheme. Different types of acquisition devices are implemented as different objects, each encapsulating the specific configuration information for that type of acquisition device. The corresponding base class object encapsulates the common configuration information of the acquisition devices.

[0072] For example, information such as the even-mode value of each channel, the input voltage of each channel, and the enable status of each channel's digital input / output of the LXI acquisition device EX1048A are encapsulated in the acquisition device information implementation object. Information such as the total number of channels, the board's sampling frequency, and the board's filtering frequency are encapsulated in the base class object corresponding to this acquisition device information implementation object.

[0073] In step 23, the information of the acquisition device is encapsulated.

[0074] This step involves creating a container for the implementation objects of the data acquisition device information and placing these implementation objects into the container. During the encapsulation of the data acquisition device information, a container is created to store pointers to the data acquisition device information interface. Since the data acquisition device information interface is the base class for all implementation objects, the interface pointers can point to all implementation objects. When using the encapsulated data acquisition device information, the data acquisition business interface sequentially retrieves the interface pointers from the object container and, based on business requirements, points to the corresponding implementation objects for different types of data acquisition devices.

[0075] In step 24, the data acquisition service is encapsulated.

[0076] This step includes encapsulating the data acquisition service interface and the data acquisition service implementation object. The data acquisition service interface is responsible for receiving the data acquisition device object container and providing the thread worker function interface for the data acquisition service execution thread. The data acquisition service implementation class, as a subclass of this interface, encapsulates different data acquisition device information and hardware drivers provided by device manufacturers, and integrates the hardware drivers in a certain order to form a data acquisition service workflow including configuration, startup, scanning, calibration, and zeroing.

[0077] In step 25, the data acquisition service is generated.

[0078] This step involves creating different acquisition service implementation objects using the acquisition service interface. When generating an acquisition service, the acquisition service interface first receives a container of acquisition device information implementation objects, sequentially retrieves these objects, and then instantiates the corresponding acquisition service implementation object based on the acquisition device information implementation object. During the instantiation of the acquisition service implementation object, the acquisition service execution thread function in the acquisition service interface is specifically implemented based on the acquisition device information, and the workflows such as configuration, startup, scanning, calibration, and zeroing are attached to the thread function.

[0079] Step 26, Packaging device management method.

[0080] This step includes creating a device management interface using the singleton pattern, encapsulating methods for registering, uninstalling, starting, scanning, calibrating, and zeroing the acquisition device, and providing operation methods for the above methods to the main control interface.

[0081] In step 27, the main control interface issues commands and requests.

[0082] This step includes using the main control interface to send commands and requests such as starting the scanning valve, performing scanning, performing calibration, and performing zeroing to the device management interface; then the device management interface receives the software initialization configuration scheme, parses the software initialization configuration scheme according to the ProtoBuffer framework, and then hands it over to the data acquisition device information interface for processing, and puts this information into the data acquisition device information implementation object container, and then calls the data acquisition service interface to generate the data acquisition service implementation object.

[0083] In step 28, the data collection process is executed.

[0084] This step uses worker threads to execute the acquisition process, including configuration, startup, scanning, calibration, and zeroing, which are attached to the thread worker function when the acquisition business implementation object is instantiated.

[0085] Figure 3 This is a schematic diagram of the structure of a data acquisition software construction apparatus according to an embodiment of this disclosure. Figure 3 As shown, the data acquisition software construction device includes a first processing module 31, a second processing module 32, a third processing module 33, a fourth processing module 34, and a fifth processing module 35.

[0086] The first processing module 31 is configured to perform initialization according to the test requirements.

[0087] In some embodiments, the first processing module 31 encapsulates the hardware configuration and channel configuration information of the acquisition device related to the test requirements to generate a configuration file, and performs initialization configuration according to the configuration file.

[0088] The second processing module 32 is configured to encapsulate the acquisition device information related to the test requirements into an object container.

[0089] In some embodiments, the second processing module 32 performs the following steps.

[0090] 1) Create an interface for collecting device information, which encapsulates the public information of the collecting device.

[0091] For example, public information includes at least one of the following: the device name of the data collection device, the global device serial number, and the device type.

[0092] 2) Encapsulate the interface pointer for the data acquisition device into an object container.

[0093] For example, the device name and serial number of the LXI acquisition device Ex1048A are encapsulated in the acquisition device information interface. Correspondingly, parameters such as hardware trigger cycle, device SN (serial number) encoding, channel even type, and number of channels are encapsulated in the device information implementation class Ex1048.

[0094] The third processing module 33 is configured to instantiate the collection service implementation object using an object container.

[0095] In some embodiments, the third processing module 33 performs the following operations.

[0096] 1) Create a data collection service interface.

[0097] For example, this interface encapsulates the virtual function Execute for executing data collection services, and its subclass objects, i.e., data collection service implementation objects, provide the specific implementation of the data collection services.

[0098] 2) Encapsulate the data acquisition device information and the hardware driver of the data acquisition device into the data acquisition service interface.

[0099] It should be noted that the hardware driver of the acquisition device is encapsulated into the acquisition business implementation object, and then the hardware driver is integrated in sequence according to different business processes, thereby forming a variety of specific execution methods for acquisition business processes.

[0100] 3) Import the object container into the data acquisition business interface so that the data acquisition device information interface pointer in the object container points to the data acquisition device information implementation object corresponding to the data acquisition device information.

[0101] 4) Instantiate the collection service implementation object corresponding to the collection service information using the configuration information in the collection device information implementation object.

[0102] The fourth processing module 34 is configured to call the acquisition service interface through the device management interface to implement the hardware driver code replication of different acquisition devices.

[0103] In some embodiments, the fourth processing module 34 constructs a device management interface using the singleton pattern, encapsulating at least one of the business processes of registering, loading, unloading, starting, scanning, calibrating, zeroing, and shutting down the acquisition device into the device management interface. Next, the acquisition business interface is called through the device management interface, and the hardware driver code for the corresponding acquisition device is selected based on the object container.

[0104] It should be noted that the device management interface coordinates and triggers the execution objects of the data acquisition process, acting as an intermediary. It receives commands and requests from the business layer and delegates them to the corresponding objects for execution.

[0105] For example, the device management interface receives the initialization configuration and then passes it to the actual execution object, i.e., the data acquisition business interface. By using the device management interface, decoupling is achieved between the business layer and the specific execution object. The business layer does not need to know how the issued data acquisition device configuration is executed or by whom, and the execution object does not need to know the source of the business.

[0106] In some embodiments, the fourth processing module 34 uses the device management interface to parse the imported configuration file to identify the hardware configuration and channel configuration of the acquisition device. Next, it uses the device management interface to encapsulate the parsed hardware configuration and channel configuration into the corresponding acquisition device information implementation object, and stores the acquisition device information interface pointer in the object container to load the device entity information. Furthermore, after the device entity information is used, it is deleted from the object container using the device management interface.

[0107] In some embodiments, when the device management interface starts the acquisition device, the fourth processing module 34 calculates the total number of loaded devices and requests a pointer array for the acquisition service interface. Next, the device management interface instantiates an acquisition service implementation object using an object container according to the type of the acquisition device, and uses pointers in the acquisition service interface pointer array to point to the acquisition service implementation object. Then, it instantiates an execution thread using the pointer array as a parameter, returns the thread pointer of the execution thread, and uses the thread pointer to call the corresponding acquisition thread.

[0108] The fifth processing module 35 is configured to issue commands to the device management interface through the main control interface so that the device management interface can perform data acquisition services corresponding to the test requirements.

[0109] In some embodiments, the fifth processing module 35 performs the following operations.

[0110] 1) Construct the main control interface.

[0111] 2) Utilize the operation methods of the device management interface encapsulated in the main control interface to control the device management interface to register acquisition devices, start the acquisition and scanning process, and instantiate the device management interface object.

[0112] In addition, the operation methods of the device management interface encapsulated in the main control interface can be used to control the device management interface to unload the acquisition device, stop the acquisition and scanning process, and instantiate the device management interface object.

[0113] 3) Use the operation method to call the functions related to business acquisition of the acquisition device in the device management interface.

[0114] For example, functions related to business data acquisition include at least one of the following: data acquisition device registration, uninstallation, data acquisition startup, and data acquisition stoppage.

[0115] Figure 4 This is a schematic diagram of the structure of a data acquisition software construction apparatus according to another embodiment of the present disclosure.

[0116] like Figure 4As shown, the building device 40 can be represented in the form of a general computing device. The building device 40 includes a memory 41, a processor 42, and a bus 43 connecting different system components.

[0117] The memory 41 may include, for example, system memory, non-volatile storage media, etc. System memory may store, for example, an operating system, application programs, a boot loader, and other programs. System memory may include volatile storage media, such as random access memory (RAM) and / or cache memory. Non-volatile storage media may store, for example, instructions for a corresponding embodiment of a method for constructing at least one data acquisition software being executed. Non-volatile storage media include, but are not limited to, disk storage, optical storage, flash memory, etc.

[0118] The processor 42 can be implemented using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete hardware components such as discrete gates or transistors. Accordingly, each module, such as the acquisition module, the calculation module, and the adjustment module, can be implemented by executing instructions in the central processing unit (CPU) running memory to perform the corresponding steps, or by implementing dedicated circuits that perform the corresponding steps.

[0119] For example, processor 42 is configured for memory-based instruction execution implementation such as Figure 1-2 The method involved in any of the embodiments.

[0120] Bus 43 can use any of the various bus architectures. For example, bus architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, and the Peripheral Component Interconnect (PCI) bus.

[0121] The interfaces 44, 45, and 46 of the building device 40, as well as the memory 41 and processor 42, can be connected via bus 43. Input / output interface 44 provides a connection interface for input / output devices such as monitors, mice, and keyboards. Network interface 45 provides a connection interface for various networked devices. Storage interface 46 provides a connection interface for external storage devices such as floppy disks, USB flash drives, and SD cards.

[0122] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus, and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations thereof, can be implemented by computer-readable program instructions.

[0123] These computer-readable program instructions are provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable device to produce a machine, such that execution of the instructions by the processor produces means for implementing the functions specified in one or more boxes of the flowchart and / or block diagram.

[0124] These computer-readable program instructions may also be stored in a computer-readable storage medium. These instructions cause a computer to work in a particular manner to produce an article of manufacture, including instructions that implement the functions specified in one or more boxes in a flowchart and / or block diagram.

[0125] This disclosure may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.

[0126] This disclosure also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement... Figure 1-2 The method involved in any of the embodiments.

[0127] This disclosure also provides a computer program product, including computer instructions, wherein the computer instructions, when executed by a processor, implement as follows: Figure 1-2 The method involved in any of the embodiments.

[0128] Figure 5 This is a schematic diagram of the structure of a data acquisition system according to an embodiment of this disclosure. Figure 5 As shown, the data acquisition system 50 includes a data acquisition software building device 51, which is a... Figure 3 or Figure 4 The apparatus for constructing data acquisition software involved in any of the embodiments.

[0129] By implementing the embodiments of this disclosure, and through flexible combinations of different configuration schemes and data acquisition processes, it is possible to flexibly adapt to various data acquisition devices on an aero-engine test stand without modifying the business layer code. This enables excellent code reuse and allows for the configuration, packaging, and deployment of corresponding hardware drivers for different data acquisition devices and data acquisition systems using the same set of code, reducing development and maintenance costs and improving R&D efficiency. Furthermore, it allows for rapid integration of new data acquisition device drivers during product iterations without altering existing business layer code, significantly enhancing software scalability.

[0130] In some embodiments, the functional units described above may be implemented as general-purpose processors, programmable logic controllers (PLCs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or any suitable combination thereof for performing the functions described herein.

[0131] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0132] The description in this disclosure is provided for illustrative and descriptive purposes only and is not intended to be exhaustive or to limit the disclosure to its forms. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described in order to better illustrate the principles and practical application of this disclosure and to enable those skilled in the art to understand this disclosure and to design various embodiments with various modifications suitable for a particular purpose.

Claims

1. A method for constructing data acquisition software, comprising: Perform initial configuration according to test requirements; The information on the acquisition equipment related to the experimental requirements is encapsulated into an object container; The object container is used to instantiate the data collection service implementation object; By calling the data acquisition service interface through the device management interface, the hardware driver code of different data acquisition devices can be reused; Commands are sent from the main control interface to the device management interface so that the device management interface can perform data acquisition services corresponding to the test requirements.

2. The method according to claim 1, wherein, By calling the data acquisition service interface through the device management interface, the reuse of hardware driver code for different data acquisition devices can be achieved, including: Construct the device management interface, and encapsulate at least one of the business processes of registration, loading, unloading, startup, scanning, calibration, zeroing, and shutdown of the data acquisition device into the device management interface; The acquisition service interface is called through the device management interface, and the hardware driver code of the corresponding acquisition device is selected according to the object container.

3. The method according to claim 2, further comprising: The imported configuration file is parsed using the device management interface to identify the hardware configuration and channel configuration of the acquisition device; The parsed hardware configuration and channel configuration are encapsulated into the corresponding data acquisition device information implementation object using the device management interface, and the data acquisition device information interface pointer is stored in the object container to load the device entity information.

4. The method according to claim 3, further comprising: After the device entity information has been used, the device entity information is deleted from the object container using the device management interface.

5. The method according to claim 3, further comprising: When the acquisition device is started in the device management interface, the total number of loaded devices is calculated, and a pointer array for the acquisition service interface is requested; The device management interface instantiates a data acquisition service implementation object using the object container according to the type of the data acquisition device, and uses pointers in the data acquisition service interface pointer array to point to the data acquisition service implementation object; The execution thread instantiated using the pointer array as a parameter is returned as a thread pointer. The corresponding acquisition thread is invoked using the thread pointer.

6. The method according to claim 1, wherein, Instantiating the data collection service object using the object container includes: Create a data acquisition service interface; The acquisition device information and the hardware driver of the acquisition device are encapsulated into the acquisition service interface; Import the object container into the data acquisition service interface so that the data acquisition device information interface pointer in the object container points to the data acquisition device information implementation object corresponding to the data acquisition device information. The configuration information in the data acquisition device information object is used to instantiate the data acquisition service implementation object corresponding to the data acquisition service information.

7. The method according to claim 1, wherein, Encapsulating the acquisition equipment information related to the aforementioned test requirements into an object container includes: Create an interface for acquiring device information, which encapsulates the public information of the acquiring device. The pointer to the acquisition device information interface is encapsulated in the object container.

8. The method according to claim 7, wherein, The public information includes at least one of the following: the device name of the data acquisition device, the global device serial number, and the device type.

9. The method according to claim 1, wherein, Initial configuration based on test requirements includes: The hardware configuration and channel configuration information of the acquisition equipment related to the test requirements are encapsulated to generate a configuration file; Perform initial configuration according to the configuration file.

10. The method according to any one of claims 1-9, wherein, Sending commands to the device management interface via the main control interface includes: Construct the main control interface; The operation method of the device management interface encapsulated in the main control interface is used to control the device management interface to register the acquisition device, start the acquisition and scanning process, and instantiate the device management interface object; The operation method is used to call the functions related to service acquisition of the acquisition device in the device management interface.

11. The method of claim 10, further comprising: Using the aforementioned operation method, the device management interface is controlled to unload the acquisition device, stop the acquisition and scanning process, and instantiate the device management interface.

12. The method according to claim 11, wherein, Functions related to business data acquisition include at least one of the following: data acquisition device registration, uninstallation, data acquisition startup, and data acquisition stoppage.

13. An apparatus for constructing data acquisition software, comprising: The first processing module is configured to initialize the configuration according to the test requirements; The second processing module is configured to encapsulate the acquisition device information related to the test requirements into an object container; The third processing module is configured to instantiate the collection service implementation object using the object container; The fourth processing module is configured to call the acquisition service interface through the device management interface to achieve the reuse of hardware driver code for different acquisition devices; The fifth processing module is configured to issue commands to the device management interface through the main control interface, so that the device management interface can perform the data acquisition service corresponding to the test requirements.

14. An apparatus for constructing data acquisition software, comprising: Memory; A processor, coupled to a memory, configured to implement the method as described in any one of claims 1-12 based on memory-stored instruction execution.

15. A data acquisition system, comprising: The apparatus for constructing data acquisition software as described in claim 13 or 14.

16. A computer-readable storage medium, wherein, A computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-12.

17. A computer program product comprising computer instructions, wherein the computer instructions, when executed by a processor, implement the method as described in any one of claims 1-12.