Method and apparatus for multi-protocol hardware integration

Abstract

The application discloses a multi-protocol hardware integration method and device, which comprises the following steps: creating a first process and a second process, the first process is used for processing user interaction logic and hardware control instructions, and the second process is used for executing a signal processing algorithm and hardware driver scheduling; creating a shared storage space in a system memory, and establishing a cross-process communication protocol based on the shared storage space between the first process and the second process; receiving an access request for a target hardware through a unified hardware access interface, and performing a protocol conversion operation based on the access request to generate specific protocol instructions matched with the target hardware; and exchanging control data and response data related to the specific protocol instructions between the first process and the second process through the cross-process communication protocol. The application reduces the complexity of multi-protocol hardware unified integration and improves the cross-process communication efficiency by constructing a dual-process architecture and establishing a cross-process communication protocol, and by means of a unified hardware interface and protocol conversion.

Description

Technical Field

[0001] This invention relates to the field of control system integration technology for industrial automation control and quantum technology equipment, and particularly to a multi-protocol hardware integration method and device. Background Technology

[0002] In the field of industrial automation control and test measurement, the unified integration of multi-protocol hardware and efficient cross-process communication are two long-standing technical challenges. On the one hand, there are various hardware devices on the market, such as NI (National Instruments) hardware using the standard NI-DAQmx protocol, vendor-developed hardware using custom protocols, and third-party devices supporting protocols such as Modbus and CAN. These hardware devices each use different communication protocols and data formats, which means that separate drivers and interfaces need to be developed for each type of hardware during system integration, resulting in code redundancy, maintenance difficulties, and high development complexity as applications need to handle multiple heterogeneous protocols. On the other hand, to balance the efficient development of graphical user interfaces and the rapid implementation of complex signal processing algorithms, existing technologies often adopt a multi-language, multi-process architecture, for example, deploying the interface and logic in a C++ process and the algorithm in a LabVIEW process. However, traditional communication methods between C++ and LabVIEW processes, such as TCP / IP or named pipes, have problems such as high overhead for data serialization and deserialization and numerous memory copying operations, resulting in communication delays typically on the order of tens of microseconds. This makes it difficult to meet the needs of high real-time scenarios such as high-speed data acquisition (sampling rate > 1MHz) or fast closed-loop control (control cycle < 100 microseconds).

[0003] Furthermore, the aforementioned technical challenges not only exist in the field of industrial automation but also constrain the engineering development of quantum technology equipment. Taking a quantum gravimeter as an example, its control system needs to simultaneously manage multiple heterogeneous subsystems, including lasers, vacuum, magnetic field compensation, microwave / RF, and atomic detection. Each subsystem employs different protocols such as manufacturer-developed serial port protocols, Modbus, SCPI over LAN, and CameraLink, with real-time requirements ranging from milliseconds to nanoseconds. Similarly, a neutral atom quantum computer requires its control system to simultaneously coordinate hundreds of independent single-atom-addressable lasers, dynamic optical tweezers rearrangement systems, and high-resolution atomic imaging systems, resulting in a massive amount of hardware and highly heterogeneous protocols. Existing cross-process communication methods based on TCP / IP, named pipes, or traditional shared memory locking typically have communication latency in the tens of microseconds to milliseconds range and incur context switching overhead due to locking mechanisms. These methods fail to meet the stringent requirements of closed-loop feedback response latency for these quantum devices, becoming one of the bottlenecks restricting their transition from laboratory prototypes to large-scale engineering applications.

[0004] Therefore, there is an urgent need for a multi-protocol hardware integration method that can reduce the complexity of unified integration of multi-protocol hardware and improve the efficiency of cross-process communication. Summary of the Invention

[0005] The main objective of this invention is to provide a multi-protocol hardware integration method and apparatus, which aims to solve the technical problems of difficulty in unifying and integrating multi-protocol hardware and low efficiency in cross-process communication in the prior art.

[0006] To achieve the above objectives, the present invention provides a multi-protocol hardware integration method, the method comprising the following steps: Create a first process and a second process. The first process is used to handle user interaction logic and hardware control instructions, and the second process is used to execute signal processing algorithms and hardware driver scheduling. Create a shared memory space in the system memory, and establish a cross-process communication protocol based on the shared memory space between the first process and the second process; It receives access requests for the target hardware through a unified hardware access interface, performs protocol conversion operations based on the access requests, and generates specific protocol instructions that match the target hardware. Through a cross-process communication protocol, control data and response data related to specific protocol instructions are exchanged between the first process and the second process to complete the integration of the target hardware.

[0007] Optionally, the step of establishing a cross-process communication protocol based on shared memory space between the first process and the second process includes: The shared memory space includes a control header structure and a circular buffer. The control header structure includes at least the current write pointer and the current read pointer. Based on shared storage space and a preset data packet format, a cross-process communication protocol is established between the first process and the second process. The cross-process communication protocol uses pointer information in the control header structure to perform lock-free concurrent access to the circular buffer.

[0008] Optionally, the steps for lock-free concurrent access to the circular buffer by controlling pointer information in the header structure include: The write operator in the first or second process writes the data to be sent into the data slot corresponding to the current write pointer in the circular buffer according to the current write pointer. The memory barrier instruction is used to determine that the data write is complete, and the current write pointer is updated atomically by the compare and swap instruction; The read operator in the first or second process reads data from the data slot in the circular buffer according to the current read pointer, and atomically updates the current read pointer by comparing and swapping instructions.

[0009] Optionally, before the step of receiving an access request for the target hardware through the unified hardware access interface, the method further includes: Define a unified hardware access interface, which should include at least standard functions for hardware initialization, data reading and writing, timing configuration, and runtime status query. Construct protocol adapters adapted to different hardware types, with each protocol adapter inheriting a unified hardware access interface and mapping standard functions to the corresponding hardware's protocol command frames; Establish a mapping relationship between hardware type and protocol adapter construction logic, dynamically create an adapter instance corresponding to the target hardware based on the mapping relationship, and use the adapter instance to perform protocol conversion operation.

[0010] Optionally, the step of performing a protocol conversion operation based on the access request to generate specific protocol instructions that match the target hardware includes: The access request is parsed, and the target hardware identifier and the operation parameters to be executed are extracted based on the parsing results; The mapping relationship is queried based on the target hardware identifier to determine the corresponding adapter instance, and the conversion logic of the adapter instance is called. In response to determining that the target hardware identifier corresponds to the standard protocol hardware, the operation parameters to be executed are converted into standard protocol command frames through the conversion logic of the adapter instance, and the standard protocol command frames are used as specific protocol instructions that match the target hardware; In response to determining that the target hardware identifier corresponds to the self-developed protocol hardware, the operation parameters to be executed are converted into self-developed protocol command frames through the conversion logic of the adapter instance, and the self-developed protocol command frames are used as specific protocol instructions that match the target hardware. In response to determining that the target hardware identifier corresponds to the third-party protocol hardware, the operation parameters to be executed are converted into a third-party general protocol command frame through the conversion logic of the adapter instance, and the third-party general protocol command frame is used as a specific protocol instruction that matches the target hardware.

[0011] Optionally, after the step of exchanging control data and response data related to specific protocol instructions between the first process and the second process via an inter-process communication protocol, the method further includes: According to the preset hardware replacement strategy, multiple progressive replacement stages are executed sequentially. Each replacement stage corresponds to a different hardware combination ratio, which represents the proportion of the first type of hardware and the second type of hardware in the total number of hardware. During the current replacement phase, a first number of first-class hardware and a second number of second-class hardware configured according to the current hardware combination ratio are controlled through a unified hardware access interface, and the parallel operation performance data of the first-class hardware and the second-class hardware are recorded. When the parallel running performance data meets the preset conditions, switch to the next replacement stage to adjust the hardware combination ratio until the proportion of the first type of hardware in the hardware combination ratio is zero.

[0012] Optionally, before executing multiple progressive replacement stages sequentially according to a preset hardware replacement strategy, the method further includes: Obtain the configuration file for the first type of hardware, and extract the channel configuration parameters, sampling timing parameters, and trigger parameters from the configuration file; Based on the range conversion relationship and sampling rate adaptation relationship, the channel configuration parameters, sampling timing parameters and trigger parameters are mapped to the configuration parameters of the second type of hardware; A configuration file for the second type of hardware is generated based on the configuration parameters of the second type of hardware, so that the configuration file for the second type of hardware can be deployed to the second type of hardware when hardware replacement is performed.

[0013] Optionally, the steps for creating the first process and the second process include: The first process is created using a compiled language and configured to execute the graphical user interface, system configuration management, and self-developed protocol frame parsing. A second process is created using a graphical programming environment, and the core signal processing and control algorithms are encapsulated into a binary executable file and run in the second process. Configure the first process and the second process as isolated processes.

[0014] Optionally, the step of exchanging control data and response data related to specific protocol instructions between the first process and the second process via an inter-process communication protocol includes: Specific protocol instructions are used as input control data, written into the shared storage space, and transmitted from the first process to the second process through an inter-process communication protocol. In the second process, the input control data is parsed, the corresponding hardware driver is called to execute specific protocol instructions, and the hardware response returned by the target hardware is obtained. The hardware response is used as the raw response data. After being parsed by the protocol, standardized response data is generated, written to the shared storage space, and transmitted from the second process to the first process through the cross-process communication protocol.

[0015] Furthermore, to achieve the above objectives, the present invention also proposes a multi-protocol hardware integration device, the device comprising: The process creation module is used to create a first process and a second process. The first process is used to handle user interaction logic and hardware control instructions, and the second process is used to execute signal processing algorithms and hardware driver scheduling. The protocol establishment module is used to create a shared storage space in system memory and establish a cross-process communication protocol based on the shared storage space between the first process and the second process. The protocol conversion module is used to receive access requests for target hardware through a unified hardware access interface, and perform protocol conversion operations based on the access requests to generate specific protocol instructions that match the target hardware. The hardware integration module is used to exchange control data and response data related to specific protocol instructions between the first process and the second process through a cross-process communication protocol in order to complete the integration of the target hardware.

[0016] Furthermore, to achieve the above objectives, the present invention also proposes a multi-protocol hardware integration device, the device comprising: a memory, a processor, and a multi-protocol hardware integration program stored in the memory and executable on the processor, the multi-protocol hardware integration program being configured to implement the steps of the multi-protocol hardware integration method described above.

[0017] In addition, to achieve the above objectives, the present invention also proposes a storage medium storing a multi-protocol hardware integration program, which, when executed by a processor, implements the steps of the multi-protocol hardware integration method described above.

[0018] This invention discloses the creation of a first process and a second process. The first process handles user interaction logic and hardware control instructions, while the second process executes signal processing algorithms and hardware driver scheduling. A shared storage space is created in system memory, and a cross-process communication protocol based on this shared storage space is established between the first and second processes. Access requests for target hardware are received through a unified hardware access interface, and a protocol conversion operation is performed based on the access requests to generate specific protocol instructions matching the target hardware. Through the cross-process communication protocol, control data and response data related to the specific protocol instructions are exchanged between the first and second processes to complete the integration of the target hardware. Because this invention decouples interaction management and algorithm execution through a dual-process architecture, achieves low-latency cross-process data exchange based on shared storage space, and shields multi-protocol differences through a unified hardware interface and protocol conversion, compared to existing technologies, this invention reduces the complexity of unified integration of multi-protocol hardware and improves cross-process communication efficiency. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the multi-protocol hardware integration method of the present invention; Figure 2 This is a schematic diagram of the shared memory ring buffer architecture in the multi-protocol hardware integration method of the present invention; Figure 3 This is a flowchart illustrating the second embodiment of the multi-protocol hardware integration method of the present invention; Figure 4 This is a schematic diagram of the multi-protocol conversion process in the multi-protocol hardware integration method of the present invention; Figure 5This is a flowchart illustrating the third embodiment of the multi-protocol hardware integration method of the present invention; Figure 6 This is a structural block diagram of the first embodiment of the multi-protocol hardware integration device of the present invention; Figure 7 This is a schematic diagram of the structure of a multi-protocol hardware integration device for the hardware operating environment involved in the embodiments of the present invention.

[0020] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0022] This invention provides a multi-protocol hardware integration method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the multi-protocol hardware integration method of the present invention.

[0023] In this embodiment, the multi-protocol hardware integration method includes steps S10 to S40: Step S10: Create a first process and a second process. The first process is used to handle user interaction logic and hardware control instructions, and the second process is used to execute signal processing algorithms and hardware driver scheduling.

[0024] It should be noted that the executing entity in this embodiment can be a computer server device with data processing, network communication, and program execution functions applied in industrial automation control scenarios, such as a server, tablet computer, or personal computer, or an electronic device capable of performing the above functions (such as a multi-protocol hardware integration device). The following uses a system containing a multi-protocol hardware integration device (hereinafter referred to as the system) as an example to illustrate this embodiment and the following embodiments.

[0025] It should be explained that the aforementioned first process can be an independent program instance running within the operating system, responsible for direct interaction with the user and managing the overall electronic control process. The aforementioned user interaction logic can include the response logic of the graphical user interface, the processing logic of user input, and the logic for updating the interface state. The aforementioned hardware control instructions can include commands for starting, stopping, configuring parameters, and querying the status of hardware devices.

[0026] The second process mentioned above can be a separate program instance isolated from the first process, specifically responsible for performing computationally intensive signal processing tasks and low-level hardware driver calls. The signal processing algorithm can include a series of steps such as filtering, transforming, and extracting features from the acquired data. The hardware driver scheduling can include calling hardware drivers, managing hardware data acquisition tasks, and coordinating the timing of multiple hardware devices.

[0027] To improve data security, the steps of creating the first process and the second process may include: creating the first process using a compiled language and configuring the first process to execute the graphical user interface, system configuration management, and self-developed protocol frame parsing; creating the second process using a graphical programming environment and encapsulating the core signal processing algorithm and control algorithm into a binary executable file to run in the second process; and configuring the first process and the second process as mutually isolated processes.

[0028] It should be noted that the compiled languages ​​mentioned above include at least C, C++, Rust, and Go, and the graphical programming environments include at least LabVIEW, MATLAB / Simulink, SCADE Suite, NI VeriStand, and CODESYS. This embodiment and the following embodiments use C++ as the compiled language and LabVIEW as the graphical programming environment for illustration.

[0029] The C++ language mentioned above is a high-level programming language that supports system-level programming. It can directly manipulate memory and has high execution efficiency. LabVIEW, mentioned above, is a graphical programming development environment that uses data streams to drive program execution, making it suitable for algorithm development and hardware control.

[0030] It should be understood that by using a heterogeneous dual-process architecture, the advantages of C++ in GUI development and system control, as well as the advantages of LabVIEW in signal processing and control algorithm design, are fully utilized. At the same time, the core algorithm is compiled into a binary executable file and run in an isolated process, which effectively prevents the algorithm logic from being extracted through memory debugging tools and avoids the leakage of algorithm logic.

[0031] Understandably, the aforementioned graphical user interface can be a human-computer interaction interface composed of visual controls such as windows, menus, buttons, and charts. The aforementioned system configuration management can include reading, modifying, saving, and synchronizing system operating parameters such as hardware device parameters, sampling frequency, channel configuration, and trigger conditions. The aforementioned self-developed protocol frame parsing refers to the process of disassembling communication protocol data frames using a custom format and extracting command words, parameters, and verification information. A self-developed protocol is a non-standardized communication protocol defined by the hardware manufacturer.

[0032] The aforementioned core signal processing algorithms can refer to the key mathematical operations used to transform, filter, or extract features from the acquired signals, such as Fast Fourier Transform or digital filtering algorithms. The aforementioned control algorithms can refer to the operational rules used to implement closed-loop control, logical judgment, or state adjustment, such as proportional-integral-derivative (PID) control algorithms.

[0033] It should be noted that the aforementioned binary executable file can refer to a machine code file generated after compilation and linking, which can be directly loaded and run by the operating system and does not contain readable source code. The aforementioned isolated processes can refer to two processes each having their own independent virtual address space, where one process cannot directly access the memory data of the other process, thus achieving access isolation.

[0034] In its implementation, the system uses C++ to create a first process, which is then configured to handle graphical user interface rendering and event handling, manage system configuration parameters (including reading and saving hardware and runtime parameters), and perform frame parsing of the vendor's proprietary communication protocol—identifying protocol frames from the raw data stream and extracting their payloads. Next, the system uses the LabVIEW development environment to create a second process, encapsulating the core signal processing and control algorithms into a binary executable file, allowing the second process to run independently. Finally, the system configures the first and second processes as isolated processes, meaning they run in their own independent memory spaces and cannot directly read or write to each other's memory areas.

[0035] To facilitate understanding, the following examples illustrate the concept, but do not impose specific limitations on this embodiment. For instance, in a data acquisition and control system, the system uses C++ and the Qt framework to create a first process. This first process displays a user interface including waveform display, parameter setting buttons, and status indicator lights. It is also responsible for reading the local "config.xml" configuration file to obtain a sampling rate of 10kHz. When a self-developed protocol data frame is received from a self-developed DAQ card, the first process parses it according to a predefined frame format (frame header 0xAA, command byte, data length, data area, checksum). Simultaneously, the system uses LabVIEW to write a program implementing bandpass filtering and PID control, compiling this program into a "Algorithm.exe" binary executable file, which is then run as a second process. This system ensures that the first and second processes run in two independent address spaces, and a crash in the first process will not affect the continued execution of the second process.

[0036] Step S20: Create a shared storage space in system memory and establish a cross-process communication protocol based on the shared storage space between the first process and the second process.

[0037] It is understandable that the aforementioned shared storage space can refer to a physical memory region in the operating system that can be directly accessed by multiple processes, and this region does not perform data copying operations between processes.

[0038] It should be explained that the aforementioned inter-process communication protocol can be a set of format conventions and access rules followed when the first process and the second process exchange data. These rules define the data encapsulation structure, read and write methods, and synchronization mechanisms.

[0039] In its implementation, after creating the first and second processes, the system creates a shared memory space in system memory. The system allocates a contiguous physical memory region in system memory as this shared memory space. A cross-process communication protocol based on this shared memory space is then established between the first and second processes. The system allocates a physical memory region in the operating system kernel as the shared memory space, which is mapped to both the virtual address spaces of the first and second processes. Next, the system defines a cross-process communication protocol that specifies how the first and second processes exchange control and response data by reading and writing to this shared memory space. Through this shared memory space and the cross-process communication protocol, the system enables the first and second processes to directly exchange information without requiring data serialization and copying.

[0040] To avoid the data serialization and copying overhead of traditional communication methods and eliminate context switching caused by locking mechanisms, the steps for establishing a cross-process communication protocol based on shared memory space between the first process and the second process may include: the shared memory space includes a control header structure and a circular buffer, the control header structure including at least a current write pointer and a current read pointer; based on the shared memory space and a preset data packet format, a cross-process communication protocol is established between the first process and the second process, and the cross-process communication protocol uses the pointer information in the control header structure to perform lock-free concurrent access to the circular buffer.

[0041] It should be explained that the aforementioned control header structure can refer to a fixed-length data region located at the beginning of the shared memory space, used to store and manage the status information of the circular buffer, such as write pointer position, read pointer position, buffer depth, and status flags. The aforementioned circular buffer can refer to a circular data storage region connected end-to-end, which is divided into multiple fixed-size data slots, each slot used to store a complete data packet.

[0042] It is understood that the aforementioned preset data packet format may refer to the predetermined structure followed when the first process and the second process exchange data. This structure includes a data packet header and a payload. The data packet header may include a magic number field (32-bit unsigned integer, used for data packet validity verification), a version field (16-bit unsigned integer, identifying the protocol version number), a type field (6-bit unsigned integer, identifying the data packet type, which may include control commands, status responses, streaming data, event notifications, configuration synchronization, and heartbeat packets), a sequence number field (32-bit unsigned integer, used for data packet sequence tracking and packet loss detection), a timestamp field (32-bit unsigned integer, recording the data packet generation time), a payload length field (32-bit unsigned integer, indicating the number of bytes of data payload), and a checksum field (32-bit unsigned integer, which can be calculated using the CRC32 algorithm).

[0043] It should be noted that the aforementioned lock-free concurrent access can refer to multiple processes simultaneously performing read and write operations on a shared resource without using mutexes or semaphores. Atomic operation instructions ensure data consistency and the atomicity of operations, avoiding the performance overhead caused by context switching.

[0044] In its implementation, the system defines and initializes a control header structure at the beginning of the shared memory space to store pointer information and status flags required for managing the circular buffer. Next, the system constructs the circular buffer in a contiguous memory region following the control header structure, dividing it into multiple data slots of equal length. Subsequently, based on the shared memory space and a preset data packet format, the system establishes a cross-process communication protocol between the first and second processes. The system defines the organization of data packets according to the preset data packet format, including the definition of header fields and the arrangement rules of the payload. The cross-process communication protocol controls the read and write operations of the first or second process on the circular buffer by reading the write and read pointer information stored in the control header structure, achieving lock-free concurrent access.

[0045] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, the above system creates a 10MB memory-mapped file as shared storage space using the CreateFileMapping function in the Windows operating system. The system defines a control header structure in the first 64 bytes of this shared storage space, containing a 64-bit write pointer and a 64-bit read pointer. Following the control header structure, the system creates a circular buffer with 1024 data slots, each slot being 10KB in size. The system defines a preset data packet format: the first 16 bytes are the header (containing 2 bytes of type, 4 bytes of sequence number, 4 bytes of timestamp, 4 bytes of length, and 2 bytes of checksum), followed by the payload. The inter-process communication protocol specifies that when the write pointer is not equal to the read pointer, it indicates that the buffer is not empty; the write operator writes data to the slot corresponding to the write pointer and then atomically moves the write pointer.

[0046] It should be understood that by using a cross-process communication protocol based on shared storage space and a circular buffer, the data serialization and copying overhead of traditional TCP / IP or named pipe methods is avoided; combined with pointer information in the control header structure, lock-free concurrent access is achieved, eliminating the context switching delay caused by the locking mechanism, thereby significantly reducing the cross-process data transmission latency and meeting the timeliness requirements of industrial real-time control scenarios.

[0047] It should be added that the steps for lock-free concurrent access to the circular buffer by controlling the pointer information in the header structure can include: the write operator in the first process or the second process writes the data to be sent into the data slot in the circular buffer corresponding to the current write pointer according to the current write pointer; determines that the data writing is complete by using a memory barrier instruction, and atomically updates the current write pointer by using a compare and swap instruction; the read operator in the first process or the second process reads the data from the data slot in the circular buffer according to the current read pointer, and atomically updates the current read pointer by using a compare and swap instruction.

[0048] It should be understood that the write operator mentioned above can refer to the execution entity that writes data to the circular buffer, and this execution entity can be either the first process or the second process. The read operator mentioned above can refer to the execution entity that reads data from the circular buffer, and this execution entity can be either the first process or the second process.

[0049] Understandably, the aforementioned current write pointer can refer to an integer value stored in the control header structure, representing the index position of the next writable data slot in the circular buffer. The aforementioned data slot can refer to a fixed-size storage unit in the circular buffer allocated to store a single data packet. Similarly, the aforementioned current read pointer can refer to an integer value stored in the control header structure, representing the index position of the next readable data slot in the circular buffer.

[0050] It should be explained that the memory barrier instruction mentioned above can be a processor-level synchronization instruction. This instruction forces the processor to complete all memory read and write operations before the barrier, and then execute memory operations after the barrier, thereby ensuring the consistency of memory operation order in a multi-core processor environment. The compare-and-swap instruction mentioned above can be an atomic operation instruction. This instruction compares the value of a memory location with a given expected value, and only updates the value of the memory location to the specified new value if the two are equal. The entire process cannot be interrupted.

[0051] In its implementation, after establishing a cross-process communication protocol based on shared memory, the system performs lock-free concurrent access operations. When either the first or second process needs to send data as a write operator, the system controls the write operator to read the current write pointer stored in the control header structure. The system calculates the address of the target data slot based on the value of the current write pointer and writes the data to be sent into the data slot corresponding to the current write pointer in the circular buffer. Next, the system executes a memory barrier instruction to ensure that the data to be sent has been completely written into the physical memory of the data slot, guaranteeing that the completion of the write operation is visible to other processor cores. Subsequently, the system atomically updates the current write pointer by executing a compare-and-swap instruction, pointing the write pointer to the next available data slot. When either the first or second process needs to read data as a read operator, the system controls the read operator to read the current read pointer stored in the control header structure. The system reads the data stored in the corresponding data slot from the circular buffer based on the current read pointer. After the read is complete, the system atomically updates the current read pointer by executing a compare and swap instruction, pointing the read pointer to the next data slot to be read.

[0052] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, in a data acquisition system, a first process (a C++ process), acting as a write operator, needs to send a "Start Acquisition" command to a second process (a LabVIEW process). The system controls the first process to read the current write pointer in the control header structure. Assuming the current write pointer is 5, the first process writes the command data to the data slot at index 5 in the circular buffer. Next, the system executes a memory barrier instruction (e.g., _mm_sfence) to ensure the write is complete. Then, the system executes a compare-and-swap instruction (e.g., __sync_bool_compare_and_swap) to atomically update the write pointer from 5 to 6. Subsequently, the second process, acting as a read operator, reads the current read pointer. Assuming the read pointer is 5, the second process reads the command data from the data slot at index 5 and updates the read pointer to 6 using a compare-and-swap instruction, completing a lock-free data transfer.

[0053] It should be understood that by comparing and exchanging instructions in conjunction with memory barriers, lock-free concurrent access is achieved, avoiding the context switching and thread blocking overhead caused by traditional locking mechanisms. Write operations directly write to shared memory slots, and read operations directly read from them, without the need to perform memory copying, achieving zero-copy transmission. While ensuring data visibility and sequential consistency among multi-core processors, this significantly reduces cross-process communication latency and improves the system's real-time response capability.

[0054] For example, refer to Figure 2 , Figure 2This is a schematic diagram of the shared memory ring buffer architecture in the multi-protocol hardware integration method of the present invention. The diagram illustrates the specific implementation logic of the cross-process communication architecture based on shared memory space. The "shared memory area" on the right side of the diagram is divided into two parts: "data buffer" and "control header". The data buffer contains multiple 64B aligned data slots (Slot[0] to Slot[N-1]), while the control header contains write pointers, read pointers, status flags, and spinlocks. The C++ process (first process) and the LabVIEW process (second process) on the left act as "producers / consumers" respectively, directly operating the data slots through "zero-copy access", avoiding the additional memory copy overhead of data; at the same time, the two processes use "CAS operation" and "atomic update" mechanisms to perform lock-free concurrent access control of the write pointer and read pointer in the control header. Specifically, the write operator (producer) writes data to the corresponding data slot based on the current write pointer and atomically updates the write pointer using memory barriers and compare-and-swap (CAS) instructions; the read operator (consumer) reads data from the data slot based on the current read pointer and similarly atomically updates the read pointer using CAS. This mechanism enables lock-free concurrent access to the circular buffer, ensuring efficient cross-process communication and data consistency.

[0055] Step S30: Receive access requests for the target hardware through the unified hardware access interface, and perform protocol conversion operations based on the access requests to generate specific protocol instructions that match the target hardware.

[0056] It should be explained that the aforementioned unified hardware access interface can refer to a set of predefined standardized functions or methods. This interface shields the protocol differences between different underlying hardware and provides a consistent way of operating hardware to upper-layer applications.

[0057] Understandably, the target hardware mentioned above can refer to the specific physical device that the current access request seeks to operate on, such as a data acquisition card, control card, or sensor device. The access request mentioned above can refer to operation instructions issued by the upper-layer application for the target hardware, such as reading analog data, writing digital data, or configuring sampling parameters.

[0058] It should be noted that the above protocol conversion operation can refer to the process of mapping a uniform format access request to a native command format that can be recognized by specific hardware, including the reorganization of command fields, conversion of data format, and calculation of checksum.

[0059] Furthermore, the aforementioned specific protocol instruction may refer to a raw command frame that conforms to the inherent communication protocol of the target hardware. This command frame contains command codes, parameter data, and verification information that the hardware can parse.

[0060] In its implementation, after establishing a cross-process communication protocol, the system receives access requests for target hardware from upper-layer applications via a unified hardware access interface. The system exposes a set of standardized hardware access functions, such as ReadAnalog, WriteAnalog, or ConfigureTiming. Upper-layer applications issue access requests by calling these functions and passing in parameters. Upon receiving the access request, the system parses it, extracting the target hardware type identifier, operation type, and operation parameters. Then, based on the parsing results, the system performs a protocol conversion operation, transforming the unified access request into a specific protocol instruction matching the target hardware. According to the target hardware's protocol type (e.g., NI-DAQmx standard protocol, vendor-developed protocol, or Modbus protocol), the system calls the corresponding conversion logic to generate a native command frame (i.e., a specific protocol instruction) conforming to the target hardware's communication specifications. The system outputs this specific protocol instruction for subsequent steps to send to the target hardware.

[0061] To facilitate understanding, the following example illustrates the concept, but does not impose specific limitations on this embodiment. For instance, in a test system, an upper-layer application calls the ReadAnalog function in the unified hardware access interface, passing in the parameters "channel 0, number of sampling points 1000", with the target hardware being a data acquisition card developed by a certain manufacturer. After receiving the access request, the system parses it to obtain the target hardware type as "SelfDeveloped" and the operation type as "simulated read". The system performs a protocol conversion operation, converting the read request into the protocol format of the self-developed hardware: assembling a specific protocol instruction with a frame header of 0xAA55, a command code of 0x01, a channel mask of 0x01, a number of sampling points of 1000, and a CRC16 checksum of 0x1234. This instruction is the command frame that the self-developed hardware can directly parse and execute.

[0062] Step S40: Through the cross-process communication protocol, control data and response data related to specific protocol instructions are exchanged between the first process and the second process to complete the integration of the target hardware.

[0063] Understandably, the aforementioned control data can refer to information exchanged between the first and second processes to control the hardware operation process, such as start acquisition commands, stop acquisition commands, configuration parameter synchronization information, or status query requests. The aforementioned response data can refer to the result information returned by the second or first process after receiving the control data, such as sampling data returned by the hardware, command execution status codes, or error messages.

[0064] It should be understood that the above integration may refer to incorporating hardware devices that follow different native communication protocols into the same unified software control framework, so that upper-layer applications can access these hardware devices through a consistent interface without being aware of the underlying protocol differences.

[0065] In its implementation, after performing protocol conversion and generating specific protocol instructions matching the target hardware, the system exchanges control and response data related to these specific protocol instructions between the first and second processes via an established inter-process communication protocol. The system transmits these specific protocol instructions as part of the control data from the first process to the second process through a circular buffer in shared memory. Upon receiving the control data, the second process parses the specific protocol instructions, calls the corresponding hardware driver to execute the instructions, and uses the execution result or the raw data returned by the hardware as response data, which is then transmitted back to the first process via the inter-process communication protocol. Through this bidirectional exchange of control and response data, the system integrates the target hardware, making it an accessible device within a unified hardware access framework.

[0066] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, in a hybrid hardware test platform, the target hardware is a data acquisition card developed by a manufacturer. A first process (C++ process) has generated a specific protocol instruction "Read Channel 0 Voltage Value". The system writes this specific protocol instruction as control data to a circular buffer in shared memory. A second process (LabVIEW process) reads the control data from the circular buffer through an inter-process communication protocol, parses it, and calls the driver of the self-developed hardware to perform a voltage reading operation, obtaining the raw code value 0x3456. The second process converts this raw code value into a standardized voltage value (e.g., 1.234V) and writes it back to the circular buffer as response data. After reading the response data, the first process displays the voltage value on the graphical user interface. Through the above exchange, the system integrates the self-developed data acquisition card into a unified hardware access framework, and the upper-layer application does not need to care about the specific details of the self-developed protocol to complete the data reading.

[0067] It should be noted that the steps of exchanging control data and response data related to specific protocol instructions between the first process and the second process through the inter-process communication protocol may include: writing the specific protocol instruction as input control data into the shared memory space and transmitting it from the first process to the second process through the inter-process communication protocol; parsing the input control data in the second process, calling the corresponding hardware driver to execute the specific protocol instruction, and obtaining the hardware response returned by the target hardware; using the hardware response as raw response data, generating standardized response data after protocol parsing, writing it into the shared memory space, and transmitting it from the second process to the first process through the inter-process communication protocol.

[0068] Understandably, the aforementioned input control data can refer to raw instruction information transmitted from the first process to the second process to trigger hardware operations, such as the specific protocol instruction itself or its encapsulated form. The aforementioned hardware response can refer to the raw electrical signal or data frame returned by the target hardware after receiving the specific protocol instruction, such as a voltage code value, a status register value, or an acknowledgment frame. The aforementioned raw response data can refer to response information directly obtained by the second process from the hardware driver layer before format conversion, such as a binary code stream or byte array.

[0069] It should be explained that the above-mentioned protocol parsing can refer to the process of disassembling and verifying the original response data according to the communication protocol followed by the target hardware, including extracting the payload, verifying the checksum, and parsing the status field.

[0070] Accordingly, the standardized response data mentioned above can refer to the result data that has been converted into a unified data format after protocol parsing. This data conforms to the return format defined by the unified hardware access interface, such as voltage values ​​expressed as floating-point numbers or status information in the form of a unified structure.

[0071] In its implementation, the system uses an inter-process communication protocol (IPC) to exchange data between the first and second processes. Specific protocol instructions are written as input control data to a circular buffer in shared memory. The system controls the first process to encapsulate the generated specific protocol instructions according to a preset data packet format and write them to the data slot pointed to by the write pointer in the circular buffer. This input control data is then transmitted from the first process to the second process via the IPC. Next, the system parses the received input control data in the second process. After reading the input control data from the circular buffer, the second process extracts the specific protocol instructions and executes them by calling the corresponding hardware driver based on the instruction type. The second process sends instructions to the target hardware through the hardware driver and obtains the hardware response returned by the target hardware. Subsequently, the system uses the obtained hardware response as raw response data, performs protocol parsing according to the communication protocol followed by the target hardware, extracts valid data, converts it into a unified data representation format, and generates standardized response data. Finally, the system writes the standardized response data to the circular buffer in shared memory and transmits it from the second process to the first process via the IPC for display in the graphical user interface or for use by upper-level logic.

[0072] It should be understood that by using shared storage space to achieve bidirectional and efficient transmission of control commands and response data, the second process directly parses and calls the hardware driver to execute commands, ensuring close collaboration between the algorithm engine and hardware operations. At the same time, the raw response data is converted into a standardized format for return, so that upper-layer applications do not need to pay attention to the differences in the underlying protocol, forming a complete closed-loop control process and improving the system's real-time performance and reliability.

[0073] It should be noted that the multi-protocol hardware integration method described in this invention is not only applicable to the fields of industrial automation control and testing measurement, but also to the control system integration of quantum technology equipment. The following illustrative examples are a quantum gravimeter and a neutral atom quantum computer, but these do not limit the scope of application of this invention.

[0074] In a quantum gravimeter, the control system needs to simultaneously manage multiple subsystems, including a laser cooling and manipulation system, a vacuum maintenance system, a magnetic field compensation system, a microwave / RF drive system, an atomic detection system, and a global timing controller. These subsystems employ various protocols, such as manufacturer-developed serial protocols, Modbus RTU protocols, analog input control, SCPI over LAN protocols, and high-speed image transmission protocols like CameraLink or GigE Vision. When applying the method of this invention, the above system performs the following operations: First, the system creates a first process (e.g., implemented in C++) to handle user interaction logic (including parameter setting, status monitoring, and data display) and hardware control instructions; and creates a second process (e.g., implemented in LabVIEW) to execute signal processing algorithms (such as cold atom interference fringe extraction and gravity acceleration calculation) and hardware driver scheduling.

[0075] Next, the system creates a shared storage space in the system memory and establishes a cross-process communication protocol based on this shared storage space between the first process and the second process. It adopts a circular buffer and a lock-free concurrent access mechanism to achieve microsecond-level data transmission latency, which meets the stringent requirements of quantum gravimeters for closed-loop feedback response time (usually required to be less than 100 microseconds).

[0076] Subsequently, the system receives access requests for target subsystems (e.g., magnetic field compensation power supplies) through a unified hardware access interface and performs protocol conversion operations based on the access requests: if the target subsystem is a vacuum gauge using the Modbus protocol, the unified interface call is converted into a Modbus RTU command frame; if the target subsystem is a microwave source using SCPI over LAN, it is converted into an SCPI command string. Through this protocol conversion, the upper-layer algorithm can uniformly control each subsystem without needing to be concerned with the differences in the underlying protocols.

[0077] Finally, the system uses a cross-process communication protocol to exchange control and response data related to specific protocol instructions between the first and second processes, thereby integrating the various subsystems of the quantum gravimeter and achieving closed-loop control of atomic interferometry and real-time magnetic field compensation.

[0078] In a neutral atom quantum computer, the control system needs to simultaneously manage hundreds of independent single-atom-addressable laser beams (each requiring independent control of amplitude, phase, and frequency), a dynamic optical tweezers rearrangement system (based on spatial light modulators or acousto-optic deflectors), a high-resolution atom imaging system (for state readout), and a global quantum gate driving system. When the method of this invention is applied, the above systems perform similar operations: The system creates a first process (C++) to handle quantum circuit compilation, user interface, and global scheduling logic, and a second process (LabVIEW) to execute atomic imaging processing, optical tweezers position correction, and quantum state determination algorithms. A zero-copy communication protocol with shared memory enables command issuance and status feedback with nanosecond-level timing accuracy. Through a hardware abstraction layer and protocol conversion engine, heterogeneous devices from different manufacturers, such as laser controllers (using a self-developed protocol), spatial light modulators (using the CameraLink protocol), and EMCCD cameras (using the GigE Vision protocol), are unified into a single control framework, ensuring reliable execution of real-time feedback tasks such as quantum error correction.

[0079] The above examples demonstrate that the present invention can effectively solve the technical problems of difficult integration of multi-protocol hardware and high cross-process communication latency in quantum technology equipment, and has broad application prospects.

[0080] This embodiment discloses the creation of a first process and a second process. The first process handles user interaction logic and hardware control instructions, while the second process executes signal processing algorithms and hardware driver scheduling. A shared storage space is created in system memory, and a cross-process communication protocol based on the shared storage space is established between the first and second processes. Access requests for target hardware are received through a unified hardware access interface, and a protocol conversion operation is performed based on the access requests to generate specific protocol instructions matching the target hardware. Through the cross-process communication protocol, control data and response data related to the specific protocol instructions are exchanged between the first and second processes to complete the integration of the target hardware. Because this embodiment decouples interaction management and algorithm execution through a dual-process architecture, achieves low-latency cross-process data exchange based on shared storage space, and shields multi-protocol differences by leveraging a unified hardware interface and protocol conversion, compared to existing technologies, this embodiment reduces the complexity of unified integration of multi-protocol hardware and improves cross-process communication efficiency.

[0081] refer to Figure 3 , Figure 3This is a flowchart illustrating the second embodiment of the multi-protocol hardware integration method of the present invention.

[0082] Based on the first embodiment described above, in this embodiment, before step S30, steps S211 to S213 are further included: Step S211: Define a unified hardware access interface. The unified hardware access interface shall include at least standard functions for hardware initialization, data reading and writing, timing configuration, and runtime status query.

[0083] Step S212: Construct protocol adapters adapted to different hardware types. Each protocol adapter inherits the unified hardware access interface and maps standard functions to the corresponding hardware's protocol command frames.

[0084] Step S213: Establish a mapping relationship between hardware type and protocol adapter construction logic, dynamically create an adapter instance corresponding to the target hardware based on the mapping relationship, and use the adapter instance to perform protocol conversion operation.

[0085] Understandably, the aforementioned unified hardware access interface can refer to a set of predefined abstract methods that define standardized operating procedures for accessing hardware devices, but do not provide concrete implementations. The aforementioned standard functions can refer to functions declared in the unified hardware access interface that have fixed names, parameter types, and return values, such as the Initialize function for hardware initialization, the ReadAnalog function for data reading, the ConfigureTiming function for timing configuration, and the GetDeviceInfo function for runtime status queries.

[0086] It should be noted that the aforementioned protocol adapter can refer to a software module or class that is responsible for converting standard function calls of the unified hardware access interface into native protocol commands that can be recognized by specific hardware, and converting the native response returned by the hardware into a standard format.

[0087] It should be understood that the above inheritance can refer to the process by which a software class acquires attributes and methods from another class. After inheriting from the parent class, the subclass can override the parent class's methods to implement specific functions. The above protocol command frames can refer to command frames recognized by the hardware device's own firmware and following its inherent communication format, such as NI-DAQmx API call sequences or vendor-defined serial port command frames.

[0088] It should be noted that the mapping relationship mentioned above can refer to a data structure (such as a hash table or dictionary) that records the correspondence between the name of each hardware type and the corresponding protocol adapter construction logic (such as a factory function or class constructor). The adapter instance mentioned above can refer to a protocol adapter object dynamically created based on the mapping relationship. This object occupies actual space in memory and can be called by the program to perform specific hardware operations.

[0089] In its implementation, the system first defines a unified hardware access interface before performing protocol conversion. The system declares an abstract base class or interface class in its code, containing standard functions for hardware initialization, data reading and writing, timing configuration, and runtime status query. Each standard function defines specific input parameters and return value types. Next, the system constructs protocol adapters adapted to different hardware types. For each hardware type (e.g., NI standard hardware, vendor-developed hardware, Modbus third-party devices), the system creates a concrete adapter class. This class inherits from the unified hardware access interface to obtain the declarations of the standard functions and implements the specific logic of each standard function internally, mapping the operation of the standard function to the corresponding hardware's native protocol commands (i.e., protocol command frames). Subsequently, the system establishes a mapping relationship between hardware types and the protocol adapter construction logic. The system maintains a registry where the keys are hardware type identifier strings (e.g., "NI_DAQmx", "SelfDeveloped", "Modbus"), and the values ​​are constructor pointers or factory methods of the corresponding adapter classes. Based on the above mapping relationship, when the system needs to operate a certain target hardware, it searches the registry for the corresponding construction logic according to the target hardware type identifier and dynamically creates an adapter instance corresponding to the target hardware. This adapter instance can then be used for subsequent unified hardware access.

[0090] Furthermore, the step of performing a protocol conversion operation based on the access request to generate a specific protocol instruction matching the target hardware may include: parsing the access request and extracting the target hardware identifier and the operation parameters to be executed based on the parsing result; querying the mapping relationship based on the target hardware identifier to determine the corresponding adapter instance and calling the conversion logic of the adapter instance; in response to determining that the target hardware identifier corresponds to standard protocol hardware, converting the operation parameters to be executed into a standard protocol command frame through the conversion logic of the adapter instance, and using the standard protocol command frame as the specific protocol instruction matching the target hardware; in response to determining that the target hardware identifier corresponds to self-developed protocol hardware, converting the operation parameters to be executed into a self-developed protocol command frame through the conversion logic of the adapter instance, and using the self-developed protocol command frame as the specific protocol instruction matching the target hardware; in response to determining that the target hardware identifier corresponds to third-party protocol hardware, converting the operation parameters to be executed into a third-party general protocol command frame through the conversion logic of the adapter instance, and using the third-party general protocol command frame as the specific protocol instruction matching the target hardware.

[0091] Understandably, the aforementioned target hardware identifier can refer to identification information used to uniquely distinguish different hardware devices or their types, such as device name, device model, device ID, or hardware type string.

[0092] It should be noted that the above-mentioned operation parameters to be executed can refer to the specific operation data carried in the access request, such as the channel number list, the number of sampling points, the voltage value, the sampling rate, or the trigger edge type.

[0093] It should be understood that the aforementioned standard protocol hardware can refer to hardware devices that follow publicly available standardized communication protocols, such as NI data acquisition cards using the NI-DAQmx protocol. The aforementioned self-developed protocol hardware can refer to hardware devices that use manufacturer-defined proprietary communication protocols; these protocols are not publicly disclosed and have specific frame formats and command sets. The aforementioned third-party protocol hardware can refer to devices that follow common industrial protocols, such as sensors or actuators that support Modbus or CAN bus protocols.

[0094] It should be noted that the aforementioned standard protocol command frames can refer to command data packets conforming to publicly standardized protocol formats, such as data structures conforming to the NI-DAQmx API call specification. The aforementioned self-developed protocol command frames can refer to command data packets conforming to vendor-specific protocol formats, which typically include a specific frame header, command code, parameter fields, and checksum. The aforementioned third-party general protocol command frames can refer to command data packets conforming to general industrial protocol formats such as Modbus, CAN, and PROFIBUS, such as the function code frame structure in the Modbus RTU protocol.

[0095] In its implementation, after receiving an access request for the target hardware through a unified hardware access interface, the system parses the request. It extracts various fields from the request and, based on the parsing results, extracts the target hardware identifier and the parameters to be executed. Then, based on the extracted target hardware identifier, the system queries the established mapping relationship between hardware types and protocol adapter construction logic, searching the mapping table for the adapter instance corresponding to the target hardware identifier. Once the system identifies the corresponding adapter instance, it calls the adapter instance's internal conversion logic to perform protocol conversion. When the system determines that the target hardware identifier corresponds to standard protocol hardware, it converts the parameters to be executed into a command frame conforming to the standard protocol format using the adapter instance's conversion logic. When the system determines that the target hardware identifier corresponds to self-developed protocol hardware, it converts the parameters to be executed into a command frame conforming to the vendor's self-developed protocol format using the adapter instance's conversion logic. When the system determines that the target hardware identifier corresponds to third-party protocol hardware, it converts the parameters to be executed into a command frame conforming to the third-party's general protocol format using the adapter instance's conversion logic.

[0096] It should be understood that by parsing access requests and extracting hardware identifiers, the mapping relationship is automatically queried and the corresponding adapter instance is determined. The unified operation parameters are converted into command frames of standard protocols, self-developed protocols, or third-party general protocols, enabling upper-layer applications to control heterogeneous devices simultaneously with a unified interface without having to pay attention to the differences in underlying protocols. This achieves seamless collaboration and flexible scheduling of multi-protocol hardware on the same platform.

[0097] For example, refer to Figure 4 , Figure 4This diagram illustrates the multi-protocol conversion process in the multi-protocol hardware integration method of this invention. The diagram shows the detailed architecture of the hardware abstraction layer and the protocol conversion engine. The "protocol abstraction layer," located in the middle layer, first defines a unified hardware access interface for the application layer and receives standardized API calls through a "protocol router." During the protocol conversion phase, the system internally includes an "NI command converter" and a "vendor command wrapper," which correspond to the processing logic of standard protocols and custom protocols, respectively. The system pre-builds protocol adapters adapted to different hardware types. These adapters inherit the unified interface and map the standard functions of the upper layer to the native protocol commands of the underlying hardware. When an access request for the target hardware is received, the system performs a protocol conversion operation through the protocol converter based on the type of the target hardware: for NI standard hardware, the operation parameters are converted into standard protocol command frames; for self-developed or third-party protocol hardware, they are converted into corresponding custom protocol command frames. The converted specific protocol instructions are finally sent to the driver layer, which then controls the underlying NI hardware or vendor-developed hardware through the NI-DAQmx driver or the vendor's self-developed driver, thereby achieving unified access and protocol-independent control of heterogeneous hardware. Meanwhile, the raw data returned by the hardware is reverse-converted into standardized data by the "NI Data Parser" and the "Vendor Data Parser" and then fed into the data cache pool (i.e., shared storage space) for use by upper-layer applications.

[0098] This embodiment discloses the definition of a unified hardware access interface, which includes at least standard functions for hardware initialization, data read / write, timing configuration, and runtime status query. Protocol adapters adapted to different hardware types are constructed, each inheriting the unified hardware access interface and mapping the standard functions to the corresponding hardware's protocol command frames. A mapping relationship between hardware type and protocol adapter construction logic is established, and adapter instances corresponding to the target hardware are dynamically created based on this mapping relationship to perform protocol conversion operations. This embodiment shields the underlying differences between different hardware protocols through the unified hardware access interface, enabling upper-layer applications to access heterogeneous devices in a standardized manner. Each protocol adapter maps the standard functions of the unified interface to the corresponding hardware's protocol command frames, achieving seamless access to multi-protocol hardware. The dynamic creation of adapter instances based on the mapping relationship between hardware type and construction logic supports flexible expansion and runtime access for new hardware types without modifying the main program code. Compared to existing technologies, this embodiment reduces the development cycle and maintenance costs of multi-protocol hardware integration.

[0099] refer to Figure 5 , Figure 5 This is a flowchart illustrating the third embodiment of the multi-protocol hardware integration method of the present invention.

[0100] Based on the above embodiments, in this embodiment, after step S40, steps S50 to S70 are further included: Step S50: According to the preset hardware replacement strategy, execute multiple progressive replacement stages in sequence. Each replacement stage corresponds to a different hardware combination ratio. The hardware combination ratio represents the proportion of the first type of hardware and the second type of hardware in the total number of hardware.

[0101] Step S60: In the current replacement phase, control the first number of first-type hardware and the second number of second-type hardware configured according to the current hardware combination ratio through the unified hardware access interface, and record the parallel operation performance data of the first-type hardware and the second-type hardware.

[0102] Step S70: When the parallel running performance data meets the preset conditions, switch to the next replacement stage to adjust the hardware combination ratio until the proportion of the first type of hardware in the hardware combination ratio is zero.

[0103] It should be noted that the first type of hardware can be NI standard hardware, while the second type of hardware can be self-developed hardware. For example, the first type of hardware can refer to hardware devices that use open and standardized communication protocols, including but not limited to National Instruments hardware using the NI-DAQmx protocol, Siemens PLCs using the S7 protocol, and industrial equipment using the Modbus protocol; the second type of hardware can refer to hardware devices that use manufacturer-defined proprietary protocols, including but not limited to self-developed data acquisition cards or control cards.

[0104] It should be explained that the aforementioned preset hardware replacement strategy can refer to a pre-defined overall plan to guide the gradual transition from one hardware platform to another. This plan includes multiple stages and a target hardware ratio for each stage. The aforementioned progressive replacement stages can refer to multiple consecutive execution time intervals or configuration states divided according to the preset hardware replacement strategy. Each stage has a different hardware combination ratio. For example, stage one is a pure NI platform, stage two is 80% NI and 20% self-developed, stage three is 50% each, stage four is 80% self-developed and 20% NI, and stage five is a pure self-developed platform.

[0105] Understandably, the aforementioned hardware combination ratio can refer to the relative relationship between the number of NI standard hardware and the number of self-developed hardware in the system, and can be expressed as a percentage or a specific quantity ratio. The first quantity mentioned above can refer to the specific number of NI standard hardware components that the system plans to connect to and control during the current replacement phase. The second quantity mentioned above can refer to the specific number of self-developed hardware components that the system plans to connect to and control during the current replacement phase.

[0106] It should be noted that the above parallel operation performance data can refer to the various performance indicators measured by the system when NI standard hardware and self-developed hardware are working simultaneously, such as sampling rate, response latency, data throughput, control cycle jitter or error rate.

[0107] It should be understood that the aforementioned preset conditions may refer to pre-set performance indicator thresholds or judgment rules used to determine whether the current stage is running normally and whether it can enter the next stage, such as performance deviation not exceeding 5% or all test cases passing.

[0108] In its implementation, the system performs multiple progressive replacement phases during multi-protocol hardware integration, based on a pre-defined hardware replacement strategy. Each phase corresponds to a different hardware combination ratio; for example, the first phase uses pure NI standard hardware, the second phase introduces a small amount of self-developed hardware, the third phase deploys hardware evenly, the fourth phase primarily uses self-developed hardware, and the fifth phase achieves full self-development. In the current replacement phase, the system simultaneously controls a first number of NI standard hardware and a second number of self-developed hardware through an established unified hardware access interface. The system executes pre-defined test tasks or actual operation tasks on both types of hardware, recording parallel operation performance data of the NI standard hardware and self-developed hardware during the process. This includes recording the sampling rate, communication latency, data loss rate, and overall system response time for each device. After recording the parallel operation performance data, the system determines whether the performance data meets pre-defined conditions, such as whether the sampling rate of the self-developed hardware reaches more than 95% of that of the NI hardware, or whether the overall system latency is within acceptable limits. When the parallel performance data meets the preset conditions, the system switches to the next replacement phase, adjusting the ratio of NI standard hardware to self-developed hardware. For example, the number of self-developed hardware units is increased from 2 to 4, and the number of NI hardware units is reduced from 8 to 6. The system repeats this process until the number of NI standard hardware units is zero and the number of self-developed hardware units reaches the preset total, completing the replacement of all hardware.

[0109] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, in a certain automated testing system, the preset hardware replacement strategy includes five stages: Stage 1: 8 NI hardware and 0 self-developed hardware; Stage 2: 6 NI hardware and 2 self-developed hardware; Stage 3: 4 NI hardware and 4 self-developed hardware; Stage 4: 2 NI hardware and 6 self-developed hardware; Stage 5: 0 NI hardware and 8 self-developed hardware, with a preset total of 8. Currently, when executing Stage 2, the system controls 6 NI standard data acquisition cards and 2 self-developed data acquisition cards through a unified hardware access interface, simultaneously running 1000 continuous sampling tasks and recording parallel operation performance data. If the measured average sampling rate of the self-developed hardware is 1.96 MS / s and the average sampling rate of the NI hardware is 2.0 MS / s, with a deviation of 2%, which is less than the preset 5% threshold, then the preset condition is met, and the system switches to Stage 3, adjusting the configuration to 4 NI hardware and 4 self-developed hardware. This continues until Stage 5 achieves 0 NI hardware and 8 self-developed hardware.

[0110] It should be understood that by replacing hardware in stages and gradually, the systemic risks caused by replacing all hardware at once are avoided. Each stage runs in parallel with different proportions of standard hardware and self-developed hardware under a unified interface, and performance data is collected and compared in real time. This ensures that the stability and compatibility of the self-developed hardware meet the standards before moving to the next stage, thus achieving a smooth transition from the standard hardware platform to the self-developed hardware platform and effectively reducing the technical risks and business interruption risks during the hardware migration process.

[0111] To ensure configuration consistency and compatibility during hardware replacement, improve migration efficiency, and reduce the risk of system failures caused by configuration errors, before executing multiple progressive replacement stages according to a preset hardware replacement strategy, the process may include: obtaining the configuration file of the first type of hardware and extracting the channel configuration parameters, sampling timing parameters, and trigger parameters from the configuration file; mapping the channel configuration parameters, sampling timing parameters, and trigger parameters to the configuration parameters of the second type of hardware based on the range conversion relationship and sampling rate adaptation relationship; and generating the configuration file of the second type of hardware based on the configuration parameters of the second type of hardware, so as to deploy the configuration file of the second type of hardware to the second type of hardware during hardware replacement.

[0112] It is understandable that the configuration file of the aforementioned NI standard hardware can refer to a data file that stores the operating parameter settings of the NI standard hardware, such as an XML file, a JSON file, or an INI file. This file records configuration information such as the channel definition, sampling rate, range, and triggering method of the hardware device.

[0113] The channel configuration parameters mentioned above can refer to the parameters in the configuration file used to define analog input channels, analog output channels, or digital input / output ports, such as channel number, channel type, range upper and lower limits, coupling method, etc. The sampling timing parameters mentioned above can refer to the parameters in the configuration file used to define data acquisition time-related behaviors, such as sampling rate, number of sampling points per channel, buffer size, clock source, edge polarity, etc. The trigger parameters mentioned above can refer to the parameters in the configuration file used to define the data acquisition start conditions, such as trigger source, trigger edge (rising or falling edge), trigger level, number of pre-trigger points, etc.

[0114] It should be explained that the aforementioned range conversion relationship can refer to the corresponding rules for mapping the voltage measurement range of NI standard hardware (e.g., ±10V, ±5V) to the range setting or encoding range of proprietary hardware, such as linear mapping formulas or lookup table rules. The aforementioned sampling rate adaptation relationship can refer to the corresponding rules for converting the sampling rate value of NI standard hardware to the sampling rate value supported by proprietary hardware. Since different hardware may have different sampling rate levels, the adaptation relationship includes rounding, rounding to the nearest range, or selecting the nearest range.

[0115] It is understandable that the configuration parameters of the self-developed hardware mentioned above can refer to a set of parameters that conform to the inherent configuration format of the self-developed hardware, such as the channel mask, gain setting, sampling frequency division coefficient, trigger mode word, etc. of the self-developed hardware.

[0116] In its implementation, before executing the incremental hardware replacement phase, the system first obtains the configuration file of the NI standard hardware. The system reads the configuration file from a specified path and parses it. Next, it extracts channel configuration parameters, sampling timing parameters, and trigger parameters from the parsed configuration file. These parameters are temporarily stored in memory as structured data. Subsequently, based on pre-established range conversion and sampling rate adaptation relationships, the system maps the extracted channel configuration parameters, sampling timing parameters, and trigger parameters to the configuration parameters of the self-developed hardware. The system converts the range values ​​(e.g., ±10V) in the NI standard hardware to the gain setting or ADC code range of the self-developed hardware according to the range conversion relationship; it converts the sampling rate values ​​of the NI standard hardware to the closest sampling rate value or frequency division coefficient supported by the self-developed hardware according to the sampling rate adaptation relationship; and it maps the trigger source and trigger edge in the trigger parameters to the corresponding register settings of the self-developed hardware. Finally, based on all the mapped configuration parameters of the self-developed hardware, the system generates a configuration file that conforms to the format requirements of the self-developed hardware, such as a binary configuration file or a text-based configuration file. When performing hardware replacement in the future, the above system will deploy the configuration file of the self-developed hardware to the corresponding self-developed hardware to complete the configuration migration.

[0117] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, a system originally used NI standard hardware, whose configuration file "NI_Config.xml" contained channel configuration parameters: "Channel AI0, range -10V to +10V"; sampling timing parameters: "Sampling rate 100000S / s"; trigger parameters: "Trigger source PFI0, rising edge trigger". After extracting these parameters, the above system, based on the range conversion relationship (NI's ±10V corresponds to the gain of the self-developed hardware = 1, and the ADC code value range 0-65535 is mapped to -10V to +10V) and the sampling rate adaptation relationship (the self-developed hardware supports 96000S / s and 128000S / s, and the closest 96000S / s is selected), maps to obtain the configuration parameters of the self-developed hardware: channel mask 0x01, gain set to 1, sampling frequency division coefficient 15625, trigger source GPIO0, and trigger edge rising edge. The system generates a configuration file "Self_Config.bin" for its self-developed hardware based on these parameters. During the replacement phase from NI hardware to self-developed hardware, the system burns this bin file to the self-developed data acquisition card via serial port.

[0118] This embodiment discloses a method for sequentially executing multiple progressive replacement stages according to a preset hardware replacement strategy. Each replacement stage corresponds to a different hardware combination ratio, which represents the proportion of first-type hardware and second-type hardware in the total number of hardware components. In the current replacement stage, a unified hardware access interface controls a first number of first-type hardware and a second number of second-type hardware configured according to the current hardware combination ratio, and records the parallel operation performance data of the first-type hardware and second-type hardware. When the parallel operation performance data meets preset conditions, the system switches to the next replacement stage to adjust the hardware combination ratio until the proportion of first-type hardware in the hardware combination ratio is zero. Because this embodiment executes multiple progressive replacement stages sequentially according to a preset hardware replacement strategy, it avoids the systemic risks caused by replacing all hardware at once, and achieves a smooth transition from a standard hardware platform to a self-developed hardware platform. Compared with the prior art, this embodiment effectively reduces the technical risks and business interruption risks during the hardware migration process.

[0119] Furthermore, this embodiment of the invention also proposes a storage medium storing a multi-protocol hardware integration program, which, when executed by a processor, implements the steps of the multi-protocol hardware integration method described above.

[0120] Reference Figure 6 , Figure 6 This is a structural block diagram of the first embodiment of the multi-protocol hardware integration device of the present invention.

[0121] like Figure 6As shown, the multi-protocol hardware integration device proposed in this embodiment of the invention includes: a process creation module 801, a protocol establishment module 802, a protocol conversion module 803, and a hardware integration module 804.

[0122] The process creation module 801 is used to create a first process and a second process. The first process is used to handle user interaction logic and hardware control instructions, and the second process is used to execute signal processing algorithms and hardware driver scheduling.

[0123] The protocol establishment module 802 is used to create a shared storage space in the system memory and establish a cross-process communication protocol based on the shared storage space between the first process and the second process.

[0124] The protocol conversion module 803 is used to receive access requests for target hardware through a unified hardware access interface, and perform protocol conversion operations based on the access requests to generate specific protocol instructions that match the target hardware.

[0125] The hardware integration module 804 is used to exchange control data and response data related to specific protocol instructions between the first process and the second process through an inter-process communication protocol in order to complete the integration of the target hardware.

[0126] The process creation module 801 is also used to create a first process using a compiled language and configure the first process to execute the graphical user interface, system configuration management, and self-developed protocol frame parsing; to create a second process using a graphical programming environment and encapsulate the core signal processing algorithm and control algorithm into a binary executable file to run in the second process; and to configure the first process and the second process as mutually isolated processes.

[0127] The protocol establishment module 802 is also used to establish a cross-process communication protocol between the first process and the second process based on the shared storage space, including a control header structure and a circular buffer. The control header structure includes at least a current write pointer and a current read pointer. The cross-process communication protocol uses the pointer information in the control header structure to perform lock-free concurrent access to the circular buffer.

[0128] The protocol establishment module 802 is also used by the write operator in the first process or the second process to write the data to be sent into the data slot corresponding to the current write pointer in the circular buffer according to the current write pointer; to determine that the data writing is complete through the memory barrier instruction, and to atomically update the current write pointer through the comparison and exchange instruction; and by the read operator in the first process or the second process to read the data from the data slot in the circular buffer according to the current read pointer, and to atomically update the current read pointer through the comparison and exchange instruction.

[0129] The hardware integration module 804 is also used to write specific protocol instructions as input control data into the shared storage space and transmit them from the first process to the second process through an inter-process communication protocol; in the second process, the input control data is parsed, the corresponding hardware driver is called to execute the specific protocol instructions, and the hardware response returned by the target hardware is obtained; the hardware response is used as raw response data, and after protocol parsing, standardized response data is generated, written into the shared storage space, and transmitted from the second process to the first process through an inter-process communication protocol.

[0130] This device embodiment discloses the creation of a first process and a second process. The first process handles user interaction logic and hardware control instructions, while the second process executes signal processing algorithms and hardware driver scheduling. A shared storage space is created in system memory, and a cross-process communication protocol based on the shared storage space is established between the first and second processes. Access requests for target hardware are received through a unified hardware access interface, and a protocol conversion operation is performed based on the access requests to generate specific protocol instructions matching the target hardware. Through the cross-process communication protocol, control data and response data related to the specific protocol instructions are exchanged between the first and second processes to complete the integration of the target hardware. Because this device embodiment decouples interaction management and algorithm execution through a dual-process architecture, achieves low-latency cross-process data exchange based on shared storage space, and shields multi-protocol differences by leveraging a unified hardware interface and protocol conversion, compared to existing technologies, this device embodiment reduces the complexity of unified integration of multi-protocol hardware and improves cross-process communication efficiency.

[0131] Based on the first embodiment of the multi-protocol hardware integration device of the present invention, a second embodiment of the multi-protocol hardware integration device of the present invention is proposed.

[0132] In this embodiment, the protocol conversion module 803 is further configured to define a unified hardware access interface, which includes at least standard functions for hardware initialization, data reading and writing, timing configuration, and runtime status query; construct protocol adapters adapted to different hardware types, each protocol adapter inheriting the unified hardware access interface and mapping the standard functions to the corresponding hardware's protocol command frames; establish a mapping relationship between hardware type and protocol adapter construction logic, and dynamically create an adapter instance corresponding to the target hardware based on the mapping relationship, so as to use the adapter instance to perform protocol conversion operations.

[0133] The protocol conversion module 803 is also used to parse the access request, extract the target hardware identifier and the operation parameters to be executed based on the parsing result; query the mapping relationship based on the target hardware identifier to determine the corresponding adapter instance, and call the conversion logic of the adapter instance; in response to determining that the target hardware identifier corresponds to standard protocol hardware, convert the operation parameters to be executed into a standard protocol command frame through the conversion logic of the adapter instance, and use the standard protocol command frame as a specific protocol instruction matching the target hardware; in response to determining that the target hardware identifier corresponds to self-developed protocol hardware, convert the operation parameters to be executed into a self-developed protocol command frame through the conversion logic of the adapter instance, and use the self-developed protocol command frame as a specific protocol instruction matching the target hardware; in response to determining that the target hardware identifier corresponds to third-party protocol hardware, convert the operation parameters to be executed into a third-party general protocol command frame through the conversion logic of the adapter instance, and use the third-party general protocol command frame as a specific protocol instruction matching the target hardware.

[0134] Other embodiments or specific implementations of the multi-protocol hardware integration device of the present invention can be referred to the above-described method embodiments, and will not be repeated here.

[0135] This application provides a multi-protocol hardware integration device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the multi-protocol hardware integration method in Embodiment 1 above.

[0136] The following is for reference. Figure 7 This document illustrates a structural schematic diagram of a multi-protocol hardware integration device suitable for implementing embodiments of this application. The multi-protocol hardware integration device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The multi-protocol hardware integration device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0137] like Figure 7As shown, the multi-protocol hardware integration device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory 1002 or a program loaded from storage device 1003 into random access memory 1004. Random access memory 1004 also stores various programs and data required for the operation of the multi-protocol hardware integration device. The processing unit 1001, read-only memory 1002, and random access memory 1004 are interconnected via bus 1005. Input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to input / output interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the multi-protocol hardware integration device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a multi-protocol hardware integration device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0138] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0139] The multi-protocol hardware integration device provided in this application, employing the multi-protocol hardware integration method described in the above embodiments, can solve the technical problems of difficulty in unified integration of multi-protocol hardware and low efficiency of cross-process communication in the prior art. Compared with the prior art, the beneficial effects of the multi-protocol hardware integration device provided in this application are the same as those of the multi-protocol hardware integration method provided in the above embodiments, and other technical features of this multi-protocol hardware integration device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0140] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0141] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0142] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0143] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0144] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, 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 read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0145] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A multi-protocol hardware integration method, characterized in that, The method includes: A first process and a second process are created. The first process is used to handle user interaction logic and hardware control instructions, and the second process is used to execute signal processing algorithms and hardware driver scheduling. Create a shared storage space in the system memory, and establish a cross-process communication protocol based on the shared storage space between the first process and the second process; The system receives access requests for target hardware through a unified hardware access interface, performs protocol conversion operations based on the access requests, and generates specific protocol instructions that match the target hardware. Through the inter-process communication protocol, control data and response data related to the specific protocol instructions are exchanged between the first process and the second process to complete the integration of the target hardware.

2. The multi-protocol hardware integration method as described in claim 1, characterized in that, The step of establishing a cross-process communication protocol based on the shared memory space between the first process and the second process includes: The shared storage space includes a control header structure and a circular buffer, and the control header structure includes at least a current write pointer and a current read pointer; Based on the shared storage space and the preset data packet format, a cross-process communication protocol is established between the first process and the second process. The cross-process communication protocol performs lock-free concurrent access to the circular buffer through the pointer information in the control header structure.

3. The multi-protocol hardware integration method as described in claim 2, characterized in that, The step of performing lock-free concurrent access to the circular buffer includes: The write operator in the first process or the second process writes the data to be sent into the data slot in the circular buffer corresponding to the current write pointer according to the current write pointer. The completion of the data write is determined by a memory barrier instruction, and the current write pointer is atomically updated by a compare and swap instruction. The read operator in the first process or the second process reads the data in the data slot from the circular buffer according to the current read pointer, and atomically updates the current read pointer by comparing and exchanging instructions.

4. The multi-protocol hardware integration method as described in claim 1, characterized in that, Before the step of receiving an access request for the target hardware through the unified hardware access interface, the method further includes: Define a unified hardware access interface, which includes at least standard functions for hardware initialization, data reading and writing, timing configuration, and runtime status query. Protocol adapters adapted to different hardware types are constructed respectively. Each protocol adapter inherits the unified hardware access interface and maps the standard functions to the corresponding hardware protocol command frames. Establish a mapping relationship between hardware type and protocol adapter construction logic, dynamically create an adapter instance corresponding to the target hardware based on the mapping relationship, and use the adapter instance to perform protocol conversion operation.

5. The multi-protocol hardware integration method as described in claim 4, characterized in that, The step of performing a protocol conversion operation based on the access request to generate specific protocol instructions that match the target hardware includes: The access request is parsed, and the target hardware identifier and the operation parameters to be executed are extracted based on the parsing results; The mapping relationship is queried based on the target hardware identifier to determine the corresponding adapter instance, and the conversion logic of the adapter instance is invoked. In response to determining that the target hardware identifier corresponds to standard protocol hardware, the operation parameters to be executed are converted into standard protocol command frames through the conversion logic of the adapter instance, and the standard protocol command frames are used as specific protocol instructions that match the target hardware; In response to determining that the target hardware identifier corresponds to the self-developed protocol hardware, the operation parameters to be executed are converted into a self-developed protocol command frame through the conversion logic of the adapter instance, and the self-developed protocol command frame is used as a specific protocol instruction that matches the target hardware; In response to determining that the target hardware identifier corresponds to third-party protocol hardware, the operation parameters to be executed are converted into third-party general protocol command frames through the conversion logic of the adapter instance, and the third-party general protocol command frames are used as specific protocol instructions that match the target hardware.

6. The multi-protocol hardware integration method as described in claim 1, characterized in that, After the step of exchanging control data and response data related to the specific protocol instruction between the first process and the second process through the cross-process communication protocol, the method further includes: According to the preset hardware replacement strategy, multiple progressive replacement stages are executed sequentially. Each replacement stage corresponds to a different hardware combination ratio, which represents the proportion of the first type of hardware and the second type of hardware in the total number of hardware. During the current replacement phase, the unified hardware access interface controls a first number of first-type hardware and a second number of second-type hardware configured according to the current hardware combination ratio, and records the parallel operation performance data of the first-type hardware and the second-type hardware. When the parallel operation performance data meets the preset conditions, switch to the next replacement stage to adjust the hardware combination ratio until the proportion of the first type of hardware in the hardware combination ratio is zero.

7. The multi-protocol hardware integration method as described in claim 6, characterized in that, Before the step of sequentially executing multiple progressive replacement stages according to a preset hardware replacement strategy, the method further includes: Obtain the configuration file of the first type of hardware, and extract the channel configuration parameters, sampling timing parameters and trigger parameters from the configuration file; Based on the range conversion relationship and sampling rate adaptation relationship, the channel configuration parameters, the sampling timing parameters, and the trigger parameters are mapped to the configuration parameters of the second type of hardware; The configuration file for the second type of hardware is generated based on the configuration parameters of the second type of hardware, so that the configuration file for the second type of hardware can be deployed to the second type of hardware when hardware replacement is performed.

8. The multi-protocol hardware integration method as described in claim 1, characterized in that, The steps for creating the first process and the second process include: The first process is created using a compiled language and configured to perform graphical user interface, system configuration management, and self-developed protocol frame parsing. The second process is created using a graphical programming environment, and the core signal processing algorithm and control algorithm are encapsulated into a binary executable file and run in the second process; Configure the first process and the second process as mutually isolated processes.

9. The multi-protocol hardware integration method as described in claim 1, characterized in that, The step of exchanging control data and response data related to the specific protocol instruction between the first process and the second process through the cross-process communication protocol includes: The specific protocol instruction is written as input control data into the shared storage space and transmitted from the first process to the second process via the cross-process communication protocol. In the second process, the input control data is parsed, the corresponding hardware driver is called to execute the specific protocol instruction, and the hardware response returned by the target hardware is obtained; The hardware response is used as the raw response data. After protocol parsing, standardized response data is generated, written into the shared storage space, and transmitted from the second process to the first process through the cross-process communication protocol.

10. A multi-protocol hardware integration device, characterized in that, The device includes: The process creation module is used to create a first process and a second process. The first process is used to handle user interaction logic and hardware control instructions, and the second process is used to execute signal processing algorithms and hardware driver scheduling. The protocol establishment module is used to create a shared storage space in the system memory and establish a cross-process communication protocol based on the shared storage space between the first process and the second process. The protocol conversion module is used to receive access requests for target hardware through a unified hardware access interface, and perform protocol conversion operations based on the access requests to generate specific protocol instructions that match the target hardware. The hardware integration module is used to exchange control data and response data related to the specific protocol instructions between the first process and the second process through the cross-process communication protocol, so as to complete the integration of the target hardware.

Images