An open instrument controller interface adaptation method and system

Abstract

The application provides an open instrument controller interface adaptation method and system, specifically, by performing static analysis on an interface driver library of an instrument to be adapted, extracting a unique fingerprint of an exported function and constructing a function index, loading the driver library in an independent logical address space, and completing address relocation and symbol resolution, realizing safe residence of the driver in a user state, when a standard instruction is issued by an upper application, matching a corresponding function fingerprint according to an instruction semantic, searching the index to obtain a function entry address, and constructing a call context containing a parameter stack rule and an entry pointer, before execution, performing logical verification on the instruction through a virtual state machine, ensuring that the state transition is legal before triggering an actual hardware call, and writing return data into a protected shared buffer.

Description

Technical Field

[0001] This application belongs to the field of interface adaptation, and in particular relates to an open instrument controller interface adaptation method and system. Background Technology

[0002] An open instrument controller refers to a control system platform that breaks away from the limitations of traditional closed, dedicated systems, supporting standardized hardware interfaces, third-party software integration, and user-defined development. Its core advantages are high flexibility and scalability, adaptability to intelligent instruments, and a real-time, open development architecture that meets the high precision, openness, and flexibility requirements of intelligent instruments for controllers. To achieve unified control of heterogeneous hardware, existing software architectures typically employ a layered approach, where communication between upper-layer control applications and lower-layer hardware devices occurs through interface driver libraries. In traditional adaptation schemes, control applications usually rely on standard loaders provided by the operating system to load vendor-provided interface driver libraries into the main process's memory space, or develop specific adaptation layer code based on standards such as VISA and IVI. There is coupling between the control application and the driver library; the driver library typically runs in the same address space as the main process. If a third-party driver experiences memory leaks, illegal pointer accesses, or crashes, it will cause the entire control software to terminate abnormally, severely impacting the stability of the testing system. Furthermore, driver libraries from different vendors may depend on different versions of the underlying base library, and loading them can easily lead to "DLL hell" or symbol conflicts, causing some instruments to fail to initialize correctly.

[0003] Existing instrument interface adaptation technologies focus on static mapping of function symbols, lacking in-depth analysis of driver library binary files and runtime security control mechanisms. In practical applications, many legacy or non-standard devices only provide binary driver files, lacking complete header files or source code support, making interface adaptation impossible through conventional compilation methods. Traditional driver calling methods are "stateless" or "blind," meaning upper-layer applications often cannot perceive the current state of the instrument hardware when issuing control commands, and calling driver functions can easily lead to hardware errors or even damage due to timing errors or state mismatches. Therefore, how to achieve an open interface adaptation method that can parse binary drivers at runtime, implement memory-level isolated loading, and ensure hardware operation security through state machines has become a pressing technical challenge in the field of instrument control. Summary of the Invention

[0004] This invention proposes an open instrument controller interface adaptation method to address the problems of existing technologies that cannot parse binary drivers at runtime, achieve memory-level isolated loading, and ensure hardware operation security through state machines. The method includes the following steps:

[0005] Static binary analysis is performed on the interface driver library file of the instrument to be adapted that is connected through the physical interface. The exported function symbol table is traversed, the function name and parameter type list are extracted, a unique fingerprint of each exported function is generated, and a functional feature index containing the correspondence between the fingerprint and the relative offset address of the function entry is constructed.

[0006] Based on the memory page allocation granularity of the current operating system and the segment space requirements of the interface driver library file, an independent logical virtual address space is requested. The code segment and data segment of the interface driver library file are loaded into the space, and address relocation repair and external symbol dependency resolution are performed based on the load base address to complete the memory residency of the driver library.

[0007] The system receives standard operation instructions from the upper-layer control application, parses the operator semantics and operand sequence of the instructions, retrieves the corresponding local execution function entry address in the functional feature index according to the preset mapping rules between instruction semantics and function fingerprints, and constructs a call context that includes parameter stack rules and function entry pointers.

[0008] A virtual state machine representing the current working logic of the instrument hardware is maintained in memory. Before the local execution function is triggered through the calling context, the operators of the standard operation instructions are used as input events to deduce the state transition of the virtual state machine. If the target state after the transition is within the preset set of legal states, the virtual state machine state is updated. The local execution function is executed through the calling context in the logical virtual address space, and the hardware return data is written to a shared data buffer protected by mutual exclusion.

[0009] Optionally, the step of traversing the exported function symbol table, extracting the function name and parameter type list, and generating a unique identifier fingerprint for each exported function includes:

[0010] Read the function name string of the exported function, traverse the parameter list of the exported function to obtain the data type name of each parameter, and concatenate the data type names into a parameter type signature string according to the declaration order of the parameters in the list;

[0011] The feature metadata is obtained by concatenating the function name string with the parameter type signature string. The feature metadata is then subjected to a SHA-256 hash operation, and the first 16 bytes of the result are used as the unique identifier fingerprint of the derived function.

[0012] Optionally, the construction of a functional feature index containing the correspondence between fingerprints and the relative offset addresses of function entry points includes:

[0013] Create a hash mapping table, using the unique identifier fingerprint as the hash key and the relative offset address of the exported function within the segment of the interface driver library file as the hash value;

[0014] The open addressing method is used to resolve hash collisions. The correspondence between the fingerprints and offset addresses of all derived functions is filled into the hash mapping table, and the hash mapping table is serialized and stored as a binary index file.

[0015] Optionally, loading the code segment and data segment of the interface driver library file into the space, and performing address relocation repair and external symbol dependency resolution based on the load base address, includes:

[0016] The file header information of the interface driver library file is parsed to obtain the loading size and memory alignment requirements of each section, calculate the total target memory space size, and request a contiguous virtual memory region with read, write, and execute permissions from the operating system;

[0017] According to the section offset defined in the file header, the binary contents of the code section and data section are copied byte by byte to the corresponding relative address in the contiguous virtual memory region;

[0018] Traverse the relocation table of the interface driver library file and, based on the starting address of the contiguous virtual memory region, perform numerical correction on all instruction operands in the code segment that involve absolute address references;

[0019] Iterate through the import table of the interface driver library file, load the external libraries that the library depends on, obtain the memory addresses of the external symbols and fill them back into the import address table.

[0020] Optionally, receiving standard operation instructions from the upper-layer control application and parsing the operator semantics and operand sequence of the instructions includes:

[0021] Detect the first space delimiter in the received standard operation instruction string, and extract the substring to the left of the delimiter as the operator semantic identifier;

[0022] Detect comma delimiters in the remaining string and split the remaining string into multiple operand substrings based on the position of the comma delimiters;

[0023] Identify the numeric format of each operand substring, convert integer-formatted data to integer data, convert floating-point-formatted data to double-precision floating-point data, and store the converted data into the operand value list.

[0024] Optionally, the step of retrieving the corresponding local execution function entry address from the functional feature index according to the preset mapping rules between instruction semantics and function fingerprints, and constructing a call context containing parameter stack rules and function entry pointers, includes:

[0025] Based on the operator semantic identifier, the corresponding target function fingerprint is searched in the preset semantic mapping configuration table;

[0026] The relative offset address of the native execution function is obtained by retrieving it from the functional feature index using the target function fingerprint, and the absolute memory address of the native execution function is calculated by combining it with the load base address of the logical virtual address space.

[0027] Based on the parameter type signature of the locally executed function, generate a parameter push instruction sequence adapted to the current CPU architecture calling convention or construct a parameter pointer array;

[0028] Instantiate a structure containing the absolute memory address and the parameter push instruction sequence as the calling context.

[0029] Optionally, the step of using operators of standard operation instructions as input events to deduce the state transitions of the virtual state machine includes the following if the target state after the transition is within a preset set of legal states:

[0030] Read the current state value of the virtual state machine. In the pre-constructed two-dimensional matrix of state transitions, the current state value is the row index, and the operator ID of the standard operation instruction is the column index. Find the value in the target cell.

[0031] The value in the target cell is used as the next state value to be changed;

[0032] Query the list of legal states and check if the next state value to be transitioned exists in the list of legal states. If it exists, the legality constraint is satisfied.

[0033] Optionally, writing the hardware return data to a mutually exclusive shared data buffer includes:

[0034] Acquire the mutex lock object for the shared data buffer and perform a locking operation to prevent concurrent write conflicts;

[0035] Calculate the byte length of the data returned by the local execution function, and check whether the remaining available space between the write pointer and the read pointer of the shared data buffer is greater than the byte length;

[0036] When there is sufficient remaining available space, the returned data will be written to the memory address pointed to by the write pointer in binary stream form, and the write pointer position will be updated to point to the end of the data.

[0037] Unlock the mutex object and trigger a data ready signal to notify the upper-layer control application to read it.

[0038] In another aspect, the present invention also discloses an open instrument controller interface adapter system, comprising the following modules:

[0039] The generation module is used to perform static binary analysis on the interface driver library file of the instrument to be adapted that is connected through the physical interface, traverse the exported function symbol table, extract the function name and parameter type list, generate a unique identifier fingerprint for each exported function, and construct a functional feature index containing the correspondence between the fingerprint and the relative offset address of the function entry.

[0040] The execution module is used to apply for an independent logical virtual address space according to the memory page allocation granularity of the current operating system and the segment space requirements of the interface driver library file, load the code segment and data segment of the interface driver library file into the space, and perform address relocation repair and external symbol dependency resolution based on the load base address to complete the memory residency of the driver library.

[0041] The construction module is used to receive standard operation instructions issued by the upper-layer control application, parse the operator semantics and operand sequence of the instructions, retrieve the corresponding local execution function entry address in the functional feature index according to the preset mapping rules of instruction semantics and function fingerprints, and construct a call context containing parameter stack rules and function entry pointers;

[0042] The update module is used to maintain a virtual state machine in memory that represents the current working logic of the instrument hardware. Before triggering the local execution function through the calling context, it uses the operators of standard operation instructions as input events to deduce the state transition of the virtual state machine. If the target state after the transition is within the preset set of legal states, the virtual state machine state is updated. The local execution function is executed through the calling context in the logical virtual address space, and the hardware return data is written to a shared data buffer protected by mutual exclusion.

[0043] Preferably, the step of traversing the exported function symbol table, extracting the function name and parameter type list, and generating a unique identifier fingerprint for each exported function includes:

[0044] Read the function name string of the exported function, traverse the parameter list of the exported function to obtain the data type name of each parameter, and concatenate the data type names into a parameter type signature string according to the declaration order of the parameters in the list;

[0045] The feature metadata is obtained by concatenating the function name string with the parameter type signature string. The feature metadata is then subjected to a SHA-256 hash operation, and the first 16 bytes of the result are used as the unique identifier fingerprint of the derived function.

[0046] Preferably, the construction of the functional feature index, which includes the correspondence between fingerprints and the relative offset addresses of function entry points, includes:

[0047] Create a hash mapping table, using the unique identifier fingerprint as the hash key and the relative offset address of the exported function within the segment of the interface driver library file as the hash value;

[0048] The open addressing method is used to resolve hash collisions. The correspondence between the fingerprints and offset addresses of all derived functions is filled into the hash mapping table, and the hash mapping table is serialized and stored as a binary index file.

[0049] Preferably, the step of loading the code segment and data segment of the interface driver library file into the space, and performing address relocation repair and external symbol dependency resolution based on the load base address, includes:

[0050] The file header information of the interface driver library file is parsed to obtain the loading size and memory alignment requirements of each section, calculate the total target memory space size, and request a contiguous virtual memory region with read, write, and execute permissions from the operating system;

[0051] According to the section offset defined in the file header, the binary contents of the code section and data section are copied byte by byte to the corresponding relative address in the contiguous virtual memory region;

[0052] Traverse the relocation table of the interface driver library file and, based on the starting address of the contiguous virtual memory region, perform numerical correction on all instruction operands in the code segment that involve absolute address references;

[0053] Iterate through the import table of the interface driver library file, load the external libraries that the library depends on, obtain the memory addresses of the external symbols and fill them back into the import address table.

[0054] Preferably, receiving standard operation instructions issued by the upper-layer control application and parsing the operator semantics and operand sequence of the instructions includes:

[0055] Detect the first space delimiter in the received standard operation instruction string, and extract the substring to the left of the delimiter as the operator semantic identifier;

[0056] Detect comma delimiters in the remaining string and split the remaining string into multiple operand substrings based on the position of the comma delimiters;

[0057] Identify the numeric format of each operand substring, convert integer-formatted data to integer data, convert floating-point-formatted data to double-precision floating-point data, and store the converted data into the operand value list.

[0058] Preferably, the step of retrieving the corresponding local execution function entry address from the functional feature index according to the preset mapping rules between instruction semantics and function fingerprints, and constructing a call context containing parameter stack rules and function entry pointers, includes:

[0059] Based on the operator semantic identifier, the corresponding target function fingerprint is searched in the preset semantic mapping configuration table;

[0060] The relative offset address of the native execution function is obtained by retrieving it from the functional feature index using the target function fingerprint, and the absolute memory address of the native execution function is calculated by combining it with the load base address of the logical virtual address space.

[0061] Based on the parameter type signature of the locally executed function, generate a parameter push instruction sequence adapted to the current CPU architecture calling convention or construct a parameter pointer array;

[0062] Instantiate a structure containing the absolute memory address and the parameter push instruction sequence as the calling context.

[0063] Preferably, the step of using standard operation instructions as input events to deduce the state transitions of the virtual state machine includes the following: If the target state after the transition is within a preset set of legal states, then:

[0064] Read the current state value of the virtual state machine. In the pre-constructed two-dimensional matrix of state transitions, the current state value is the row index, and the operator ID of the standard operation instruction is the column index. Find the value in the target cell.

[0065] The value in the target cell is used as the next state value to be changed;

[0066] Query the list of legal states and check if the next state value to be transitioned exists in the list of legal states. If it exists, the legality constraint is satisfied.

[0067] Preferably, writing the hardware return data into a mutually exclusive shared data buffer includes:

[0068] Acquire the mutex lock object for the shared data buffer and perform a locking operation to prevent concurrent write conflicts;

[0069] Calculate the byte length of the data returned by the local execution function, and check whether the remaining available space between the write pointer and the read pointer of the shared data buffer is greater than the byte length;

[0070] When there is sufficient remaining available space, the returned data will be written to the memory address pointed to by the write pointer in binary stream form, and the write pointer position will be updated to point to the end of the data.

[0071] Unlock the mutex object and trigger a data ready signal to notify the upper-layer control application to read it.

[0072] This invention solves the compatibility problem of heterogeneous hardware by performing static binary analysis on interface driver library files and establishing function fingerprint indexes, enabling the identification and access of instrument drivers with different architectures. By completing driver loading and symbol resolution within an independent logical virtual address space, memory isolation between the driver program and the main control system is achieved, avoiding address conflicts and preventing driver crashes from affecting system stability. Based on a mapping mechanism between standard instructions and local function entry points, decoupling of upper-layer control and lower-layer hardware is realized. In particular, by utilizing a virtual state machine to perform state deduction and legality verification of the operation logic before execution, coupled with a mutually exclusive buffer, illegal operations are intercepted at the logical level, avoiding hardware damage and data races caused by timing errors or misoperations, thus improving the security of the open instrument control system. Attached Figure Description

[0073] Figure 1 A flowchart of the first embodiment;

[0074] Figure 2 A structural diagram for constructing the functional feature index;

[0075] Figure 3 This is a diagram illustrating the memory mapping loading of the driver library. Detailed Implementation

[0076] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0077] In the first embodiment, the present invention proposes an open instrument controller interface adaptation method, see [link to relevant documentation]. Figure 1 This includes the following steps:

[0078] S1. Perform static binary analysis on the interface driver library file of the instrument to be adapted that is connected through the physical interface, traverse the exported function symbol table, extract the function name and parameter type list, generate a unique identifier fingerprint for each exported function, and construct a functional feature index containing the correspondence between the fingerprint and the relative offset address of the function entry.

[0079] The instruments to be adapted can be various programmable electronic devices connected to the controller via USB, serial port, Ethernet, GPIB, CAN bus, or PCIe interface, including but not limited to test and measurement instruments, industrial control equipment, medical testing equipment, scientific research experimental devices, and special production equipment. For example, the instruments to be adapted can be sensors, spectrum analyzers, data acquisition cards, temperature controllers, pressure control systems, optical measurement systems, bioanalytical instruments, or automated production line testing terminals. These instruments typically have interface driver library files provided by the manufacturers to expose control functions to upper-layer applications. This invention achieves unified control of different instrument models by adapting these interface driver libraries. The system uses the file reading functions provided by the operating system to open the interface driver library file and maps the file content to a memory buffer. Based on the PE or ELF file header specification, it locates the offset position in the export directory table. It then iterates through the function name array in the export directory to obtain the name strings of all exported functions. For function names that have been modified by the compiler, a reverse modification algorithm is used to parse out the original function name and parameter data type sequence. The parsed function name and parameter type sequence are concatenated to form a unique identifier string. The SHA256 hash algorithm is used to calculate a fixed-length hash value for this unique identifier string as a unique fingerprint. Simultaneously, the system reads the relative virtual address of each function relative to the file load base address from the address table of the export directory and creates a hash mapping table as a functional feature index. Figure 2 The generated unique identifier fingerprint is used as the key, and the corresponding relative virtual address is used as the value. These are then inserted one by one into the hash map table to complete the construction. In one possible embodiment, the parameter type or parameter type signature comes from a pre-defined interface description configuration file, such as one provided by the vendor.

[0080] The list of parameter types for the exported functions is obtained by parsing the interface description file corresponding to the interface driver library file. The interface description file can be any one of a header file, an interface definition file (IDL file), a JSON-formatted interface specification file, or an XML-formatted interface specification file. The interface description file pre-records the function name, number of parameters, parameter data types, and parameter order information. In this embodiment, after parsing the exported function names of the interface driver library file, the system retrieves the corresponding entries in the interface description file using the function name as the keyword, reads the parameter data type names and declaration order, and constructs a parameter type signature string. In this way, even if the binary file itself does not contain parameter type information, accurate parameter signature data can be obtained, thereby generating the unique identifier fingerprint. Optionally, the interface driver library file is a dynamic link library file running in user space. The dynamic link library file conforms to the executable file format specifications of the target operating system, including but not limited to PE format dynamic link library files on the Windows platform or ELF format shared object files on the Linux platform. The dynamic link library file is provided by the vendor and is used to expose instrument control interface functions to the application layer. This invention loads and calls the user-mode dynamic link library file, avoiding the involvement of kernel-mode driver loading mechanisms, thereby ensuring that interface adaptation can be achieved in a normal user privilege environment.

[0081] In an optional embodiment, the step of traversing the exported function symbol table, extracting the function name and parameter type list, and generating a unique identifier fingerprint for each exported function includes:

[0082] Read the function name string of the exported function, traverse the parameter list of the exported function to obtain the data type name of each parameter, and concatenate the data type names into a parameter type signature string according to the declaration order of the parameters in the list;

[0083] The feature metadata is obtained by concatenating the function name string with the parameter type signature string. The feature metadata is then subjected to a SHA-256 hash operation, and the first 16 bytes of the result are used as the unique identifier fingerprint of the derived function.

[0084] The export table of the interface driver library file is parsed. For C++ drivers, exported symbols typically contain type encodings, such as '_Z3Setid' indicating a function named Set with parameters of int and double. The complete parameter type list is reconstructed by calling the 'UndecorateSymbolName' or '__cxa_demangle' API. For standard C interface drivers, an XML or JSON representation file with the same name is read, and the corresponding parameter definition is found based on the function name index. A characteristic string such as "SetFrequency_double_int" is constructed and converted into a byte stream. The SHA-256 algorithm is called to calculate the hash value, and the high 128 bits are truncated as a unique identifier fingerprint. This solves the problem of standard C functions lacking parameter type information in pure binary files, ensuring the uniqueness and accuracy of the generated unique identifier fingerprint.

[0085] In an optional embodiment, constructing a functional feature index that includes the correspondence between fingerprints and the relative offset addresses of function entry points includes:

[0086] Create a hash mapping table, using the unique identifier fingerprint as the hash key and the relative offset address of the exported function within the segment of the interface driver library file as the hash value;

[0087] The open addressing method is used to resolve hash collisions. The correspondence between the fingerprints and offset addresses of all derived functions is filled into the hash mapping table, and the hash mapping table is serialized and stored as a binary index file.

[0088] A fixed-capacity hash table structure is initialized in memory. This structure contains two fields: Key and Value. The key stores a 16-byte unique identifier fingerprint, and the value stores a 4-byte relative virtual address. When a hash collision occurs, a linear probing strategy is used, traversing backward from the collision location until a free slot is found. After traversing all exported functions and filling the hash table, the memory structure is serialized into a binary data stream in little-endian order. This binary stream contains header information and key-value pair data blocks, which are written to disk as an index file for fast loading at runtime via file mapping, avoiding the overhead of repeatedly parsing interface driver library files.

[0089] S2. Based on the memory page allocation granularity of the current operating system and the segment space requirements of the interface driver library file, apply for an independent logical virtual address space, load the code segment and data segment of the interface driver library file into the space, and perform address relocation repair and external symbol dependency resolution based on the load base address to complete the memory residency of the driver library.

[0090] The system API is called to obtain the current operating system's memory page size, which is typically 4096 bytes. The section header information of the interface driver library file is traversed to calculate the total virtual memory size after aligning all sections that need to be loaded. A virtual memory allocation function is called to request a contiguous memory space with read, write, and execute permissions. The starting address of this memory space is recorded as the actual load base address. The file offset and size of each section recorded in the section table are then used... Figure 3 The contents of the code segment, data segment, and read-only data segment are copied one by one to the corresponding offset positions in the allocated memory space. The difference between the actual load base address and the preferred load base address recorded in the header of the interface driver library file is calculated to locate the section containing the relocation table. All relocation blocks are traversed, and the difference is added to each address unit that needs to be relocated to repair the absolute address of the memory reference. Then, the import table is located, and the list of external link libraries that the interface driver library file depends on is traversed. Each dependent library is loaded using the system loader, the real memory address of the dependent function is obtained and filled into the import address table, and the permissions of the memory page where the code segment is located are set to read-only and execute-only, and the permissions of the memory page where the data segment is located are set to read-only and write-only, through the memory attribute modification function. The section space requirement of the interface driver library file refers to the total memory footprint determined by the loading size, alignment granularity, and runtime expansion requirements of each section defined in the executable file format of the library file. Specifically, by parsing the section table information in the file header, the virtual size and alignment requirements of each section in memory, including the code section, data section, read-only data section, uninitialized data section (BSS), import table, relocation table, and thread-local storage area, can be obtained. This, combined with the operating system's memory page allocation granularity, calculates the actual memory space occupied by each section. Additional space can be reserved for runtime heap allocation, TLS extensions, or relocation corrections if necessary. The sum of all the above parts after alignment calculations constitutes the segment space requirement of the interface driver library file, guiding the allocation size of contiguous virtual memory regions.

[0091] In an optional embodiment, loading the code segment and data segment of the interface driver library file into the space, and performing address relocation repair and external symbol dependency resolution based on the load base address, includes:

[0092] The file header information of the interface driver library file is parsed to obtain the loading size and memory alignment requirements of each section, calculate the total target memory space size, and request a contiguous virtual memory region with read, write, and execute permissions from the operating system;

[0093] According to the section offset defined in the file header, the binary contents of the code section and data section are copied byte by byte to the corresponding relative address in the contiguous virtual memory region;

[0094] Traverse the relocation table of the interface driver library file and, based on the starting address of the contiguous virtual memory region, perform numerical correction on all instruction operands in the code segment that involve absolute address references;

[0095] Iterate through the import table of the interface driver library file, load the external libraries that the library depends on, obtain the memory addresses of the external symbols and fill them back into the import address table.

[0096] The system reads the PE / ELF header, calculates the total image size, and allocates a block of memory with 'PAGE_EXECUTE_READWRITE' permissions using 'VirtualAlloc' or 'mmap' as an "independent logical virtual address space." Sections such as '.text' and '.data' are copied to their corresponding offsets in this memory space with memory alignment granularity. Relocation is then performed; for example, if the preferred base address is 0x10000000 and the actual load base address is 0x20000000, then all hard-coded global variable addresses need to be incremented by 0x10000000. The import table is parsed, and 'LoadLibrary' / 'dlopen' is called to load dependent system libraries. The actual addresses of external functions such as 'printf' and 'malloc' are filled into the import address table to ensure that the driver code can correctly call system APIs.

[0097] In another embodiment, the step of loading the interface driver library file into the logical virtual address space is performed according to the loading process of the target operating system's dynamic linker, including the following sub-steps: parsing the file header and section table, allocating a contiguous virtual memory region that meets memory alignment requirements; copying the contents of each section to the corresponding memory location; traversing and repairing the relocation table; parsing the import table and repairing the import address table; parsing the Thread Local Storage (TLS) directory and executing the TLS initialization callback function; and calling the entry function of the interface driver library file to complete the initialization of global variables and the runtime environment. Through these steps, it is ensured that the execution environment of the interface driver library in the logical virtual address space is consistent with the standard loading process of the operating system, thereby guaranteeing the correctness and stability of function calls.

[0098] S3, receive standard operation instructions issued by the upper-layer control application, parse the operator semantics and operand sequence of the instructions, and according to the preset mapping rules between instruction semantics and function fingerprints, retrieve the corresponding local execution function entry address in the functional feature index, and construct a call context containing parameter stack rules and function entry pointers;

[0099] Specifically, a listening port or message queue is established to receive standard operation instruction data packets sent by upper-layer applications. A lexical analyzer scans the data packets to separate the operator strings representing the operation actions and the subsequent list of parameter values. A pre-configured semantic mapping file in XML or JSON format is read, and the corresponding unique identifier fingerprint is searched in the mapping file based on the operator string. This unique identifier fingerprint is used as the key to search the hash mapping table of the functional feature index. If a match is found, the corresponding relative virtual address is obtained. The relative virtual address is added to the actual load base address to obtain the absolute entry address. According to the calling convention of the target function, such as stdcall or cdecl, the parameter push order and stack cleanup responsibility are determined. A block of memory is allocated as a parameter stack. The parsed parameter value sequence is converted into corresponding binary data according to the parameter type list and written into the parameter stack in sequence. At the same time, the CPU register state is set, and the instruction pointer register is set to point to the calculated absolute entry address.

[0100] In an optional embodiment, receiving standard operation instructions from the upper-layer control application and parsing the operator semantics and operand sequence of the instructions includes:

[0101] Detect the first space delimiter in the received standard operation instruction string, and extract the substring to the left of the delimiter as the operator semantic identifier;

[0102] Detect comma delimiters in the remaining string and split the remaining string into multiple operand substrings based on the position of the comma delimiters;

[0103] Identify the numeric format of each operand substring, convert integer-formatted data to integer data, convert floating-point-formatted data to double-precision floating-point data, and store the converted data into the operand value list.

[0104] For SCPI-style instructions, such as "CONF:VOLT:DC10.5,2", the parser locates the first space, extracts "CONF:VOLT:DC", and normalizes it to uppercase as a semantic identifier. The subsequent string is then split into ["10.5", "2"] using commas as delimiters. For each substring, a regular expression or scanning function is used to determine its type: strings containing decimal points or scientific notation symbols are converted to double using 'strtod', and strings containing only numbers are converted to long or int using 'strtol'. The converted values ​​are then encapsulated in a variant container that supports multiple types, while maintaining the order of the operands.

[0105] In an optional embodiment, the step of retrieving the corresponding local execution function entry address from the functional feature index according to the preset mapping rules between instruction semantics and function fingerprints, and constructing a call context containing parameter stack rules and function entry pointers, includes:

[0106] Based on the operator semantic identifier, the corresponding target function fingerprint is searched in the preset semantic mapping configuration table;

[0107] The relative offset address of the native execution function is obtained by retrieving it from the functional feature index using the target function fingerprint, and the absolute memory address of the native execution function is calculated by combining it with the load base address of the logical virtual address space.

[0108] Based on the parameter type signature of the locally executed function, generate a parameter push instruction sequence adapted to the current CPU architecture calling convention or construct a parameter pointer array;

[0109] Instantiate a structure containing the absolute memory address and the parameter push instruction sequence as the calling context.

[0110] Operator identifiers are used as keys, and the corresponding unique fingerprint is obtained by querying the configuration table. The unique fingerprint is then used to find the relative virtual address in the index, which is added to the actual load base address to obtain the absolute entry address. Parameter passing is handled using external function interface libraries or embedded assembly logic: for example, on the x64 architecture, the first 4 or 6 integer parameters from the heterogeneous container are sequentially filled into register structures such as RCX / RDX / R8 / R9 or RDI / RSI / RDX, floating-point numbers are filled into the XMM register, and the remaining parameters are pushed onto the allocated stack memory area in reverse order. The constructed 'CallContext' object contains a complete execution environment, enabling general-purpose programs to correctly call unknown binary functions like a compiler.

[0111] S4. Maintain a virtual state machine in memory that represents the current working logic of the instrument hardware. Before triggering the local execution function through the calling context, use the operators of the standard operation instructions as input events to deduce the state transition of the virtual state machine. If the target state after the transition is within the preset set of legal states, update the virtual state machine state. Execute the local execution function through the calling context in the logical virtual address space and write the hardware return data into a shared data buffer protected by mutual exclusion.

[0112] Specifically, a structure containing current state enumeration variables and a state transition table is defined as a virtual state machine. That is, the virtual state machine is a structure or a state transition table. When a standard operation instruction is received, the control program reads the current state value, uses the operator as an event index to look up the corresponding next state in the state transition table, and updates the state to the current state. At the same time, a set of legal states or an abnormal state flag can be set for legality verification. The state transition table uses the current state and input events as indices to point to the target state. Before executing a function call, the current state variable of the virtual state machine is read, and the parsed operator is used as the input event. The corresponding entry is searched in the state transition table to determine if a corresponding target state exists and if the target state belongs to the set of legal states that are allowed to be executed. If the determination is successful, the current state variable of the virtual state machine is updated to the target state value. Assembly instructions or external function interface libraries are used to jump to the absolute entry address in the aforementioned call context to start executing the native machine code. After the function execution returns, the return value data is obtained, a system mutex is requested to lock the shared data buffer, and the return value data is serialized and written to the buffer according to a predefined data structure. After writing is completed, the mutex is released for the upper-layer application to read.

[0113] In an optional embodiment, the step of using operators of standard operation instructions as input events to deduce the state transitions of the virtual state machine, if the target state after the transition is within a preset set of legal states, includes:

[0114] Read the current state value of the virtual state machine. In the pre-constructed two-dimensional matrix of state transitions, the current state value is the row index, and the operator ID of the standard operation instruction is the column index. Find the value in the target cell.

[0115] The value in the target cell is used as the next state value to be changed;

[0116] Query the list of legal states and check if the next state value to be transitioned exists in the list of legal states. If it exists, the legality constraint is satisfied.

[0117] Maintain a 'TransitionMatrix[State_Count][Event_Count]' array. Assume the current state is IDLE (0) and the standard operation instruction ID is INIT (1). Look up the 'Matrix[0][1]' table to obtain the target state READY (1). If the lookup result is ERROR (-1), then the operation is intercepted. After obtaining the target state, verify again whether the state belongs to the set of allowed hardware operations. Only if the verification passes, update the state variable and allow subsequent execution of hardware driver code via function pointer jump; otherwise, throw a state machine exception to prevent device damage caused by executing control instructions before the hardware is ready. In one embodiment, the set of legal states is a set used to limit the stable working states allowed to enter in the instrument control process. For example, for an instrument with initialization, configuration, operation, and shutdown processes, its virtual state machine can include state values ​​such as "uninitialized state," "initialized state," "configured state," "running state," "paused state," "stopped state," and "fault state." The set of valid states can be set as {uninitialized state, initialized state, configured state, running state, paused state, stopped state}, while the "fault state" is an abnormal state that is only entered during error detection and does not belong to the valid target state in the normal control flow. When a state transition occurs, the control logic needs to determine whether the target state belongs to the set of valid states. If it does not, the corresponding local function call is refused, thereby ensuring that the instrument's operation sequence conforms to the expected control flow.

[0118] In an optional embodiment, writing the hardware return data to a mutually exclusive shared data buffer includes:

[0119] Acquire the mutex lock object for the shared data buffer and perform a locking operation to prevent concurrent write conflicts;

[0120] Calculate the byte length of the data returned by the local execution function, and check whether the remaining available space between the write pointer and the read pointer of the shared data buffer is greater than the byte length;

[0121] When there is sufficient remaining available space, the returned data will be written to the memory address pointed to by the write pointer in binary stream form, and the write pointer position will be updated to point to the end of the data.

[0122] Unlock the mutex object and trigger a data ready signal to notify the upper-layer control application to read it.

[0123] A shared data buffer using a producer-consumer model is employed. Upon completion of the local function execution, the mutex 'mutex' is locked. The remaining space in the shared data buffer is calculated as 'Space = (read pointer - write pointer - 1 + Size) % Size'. If sufficient space is available, 'memcpy' is executed to copy data to the 'write pointer' position and advance the 'write pointer'. After the write operation is complete, the buffer is unlocked, and the 'DataReady' signal is triggered. Upon receiving the signal, the upper-layer application locks the buffer and reads data from the 'read pointer' position, thus achieving lock-free and secure high-speed data acquisition between the driver layer and the application layer.

[0124] In a second embodiment, the present invention also provides an open instrument controller interface adaptation system, comprising the following modules:

[0125] The generation module is used to perform static binary analysis on the interface driver library file of the instrument to be adapted that is connected through the physical interface, traverse the exported function symbol table, extract the function name and parameter type list, generate a unique identifier fingerprint for each exported function, and construct a functional feature index containing the correspondence between the fingerprint and the relative offset address of the function entry.

[0126] The execution module is used to apply for an independent logical virtual address space according to the memory page allocation granularity of the current operating system and the segment space requirements of the interface driver library file, load the code segment and data segment of the interface driver library file into the space, and perform address relocation repair and external symbol dependency resolution based on the load base address to complete the memory residency of the driver library.

[0127] The construction module is used to receive standard operation instructions issued by the upper-layer control application, parse the operator semantics and operand sequence of the instructions, retrieve the corresponding local execution function entry address in the functional feature index according to the preset mapping rules of instruction semantics and function fingerprints, and construct a call context containing parameter stack rules and function entry pointers;

[0128] The update module is used to maintain a virtual state machine in memory that represents the current working logic of the instrument hardware. Before triggering the local execution function through the calling context, it uses the operators of standard operation instructions as input events to deduce the state transition of the virtual state machine. If the target state after the transition is within the preset set of legal states, the virtual state machine state is updated. The local execution function is executed through the calling context in the logical virtual address space, and the hardware return data is written to a shared data buffer protected by mutual exclusion.

[0129] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0130] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for adapting an open instrument controller interface, characterized in that, Includes the following steps: Static binary analysis is performed on the interface driver library file of the instrument to be adapted that is connected through the physical interface. The exported function symbol table is traversed, the function name and parameter type list are extracted, a unique fingerprint of each exported function is generated, and a functional feature index containing the correspondence between the fingerprint and the relative offset address of the function entry is constructed. Based on the memory page allocation granularity of the current operating system and the segment space requirements of the interface driver library file, an independent logical virtual address space is requested. The code segment and data segment of the interface driver library file are loaded into the space, and address relocation repair and external symbol dependency resolution are performed based on the load base address to complete the memory residency of the driver library. The system receives standard operation instructions from the upper-layer control application, parses the operator semantics and operand sequence of the instructions, retrieves the corresponding local execution function entry address in the functional feature index according to the preset mapping rules between instruction semantics and function fingerprints, and constructs a call context that includes parameter stack rules and function entry pointers. A virtual state machine representing the current working logic of the instrument hardware is maintained in memory. Before the local execution function is triggered through the calling context, the operators of the standard operation instructions are used as input events to deduce the state transition of the virtual state machine. If the target state after the transition is within the preset set of legal states, the virtual state machine state is updated. The local execution function is executed through the calling context in the logical virtual address space, and the hardware return data is written to a shared data buffer protected by mutual exclusion.

2. The method according to claim 1, characterized in that, The process involves traversing the exported function symbol table, extracting the function names and parameter type lists, and generating a unique identifier fingerprint for each exported function, including: Read the function name string of the exported function, traverse the parameter list of the exported function to obtain the data type name of each parameter, and concatenate the data type names into a parameter type signature string according to the declaration order of the parameters in the list; The feature metadata is obtained by concatenating the function name string with the parameter type signature string. The feature metadata is then subjected to a SHA-256 hash operation, and the first 16 bytes of the result are used as the unique identifier fingerprint of the derived function.

3. The method according to claim 1, characterized in that, The construction of the functional feature index, which includes the correspondence between fingerprints and the relative offset addresses of function entry points, includes: Create a hash mapping table, using the unique identifier fingerprint as the hash key and the relative offset address of the exported function within the segment of the interface driver library file as the hash value; The open addressing method is used to resolve hash collisions. The correspondence between the fingerprints and offset addresses of all derived functions is filled into the hash mapping table, and the hash mapping table is serialized and stored as a binary index file.

4. The method according to claim 1 or 3, characterized in that, The step of loading the code segment and data segment of the interface driver library file into the space, and performing address relocation repair and external symbol dependency resolution based on the load base address, includes: The file header information of the interface driver library file is parsed to obtain the loading size and memory alignment requirements of each section, calculate the total target memory space size, and request a contiguous virtual memory region with read, write, and execute permissions from the operating system; According to the section offset defined in the file header, the binary contents of the code section and data section are copied byte by byte to the corresponding relative address in the contiguous virtual memory region; Traverse the relocation table of the interface driver library file and, based on the starting address of the contiguous virtual memory region, perform numerical correction on all instruction operands in the code segment that involve absolute address references; Iterate through the import table of the interface driver library file, load the external libraries that the library depends on, obtain the memory addresses of the external symbols and fill them back into the import address table.

5. The method according to claim 1, characterized in that, The process of receiving standard operation instructions from the upper-layer control application and parsing the operator semantics and operand sequence of the instructions includes: Detect the first space delimiter in the received standard operation instruction string, and extract the substring to the left of the delimiter as the operator semantic identifier; Detect comma delimiters in the remaining string and split the remaining string into multiple operand substrings based on the position of the comma delimiters; Identify the numeric format of each operand substring, convert integer-formatted data to integer data, convert floating-point-formatted data to double-precision floating-point data, and store the converted data into the operand value list.

6. The method according to claim 1 or 5, characterized in that, The step of retrieving the corresponding local execution function entry address from the functional feature index according to the preset mapping rules between instruction semantics and function fingerprints, and constructing a call context containing parameter stack rules and function entry pointers, includes: Based on the semantic identifier of the operator, the corresponding target function fingerprint is searched in the pre-set semantic mapping configuration table; The relative offset address of the native execution function is obtained by retrieving it from the functional feature index using the target function fingerprint, and the absolute memory address of the native execution function is calculated by combining it with the load base address of the logical virtual address space. Based on the parameter type signature of the locally executed function, generate a parameter push instruction sequence adapted to the current CPU architecture calling convention or construct a parameter pointer array; Instantiate a structure containing the absolute memory address and the parameter push instruction sequence as the calling context.

7. The method according to claim 1, characterized in that, The process of using standard operation instructions as input events to deduce the state transitions of the virtual state machine includes the following: If the target state after the transition is within a preset set of legal states, it includes: Read the current state value of the virtual state machine. In the pre-constructed two-dimensional matrix of state transitions, the current state value is the row index, and the operator ID of the standard operation instruction is the column index. Find the value in the target cell. The value in the target cell is used as the next state value to be changed; Query the list of legal states and check if the next state value to be transitioned exists in the list of legal states. If it exists, the legality constraint is satisfied.

8. The method according to claim 1, characterized in that, The step of writing the hardware return data into a mutually exclusive shared data buffer includes: Acquire the mutex lock object for the shared data buffer and perform a locking operation to prevent concurrent write conflicts; Calculate the byte length of the data returned by the local execution function, and check whether the remaining available space between the write pointer and the read pointer of the shared data buffer is greater than the byte length; When there is sufficient remaining available space, the returned data will be written to the memory address pointed to by the write pointer in binary stream form, and the write pointer position will be updated to point to the end of the data. Unlock the mutex object and trigger a data ready signal to notify the upper-layer control application to read it.

9. An open instrument controller interface adapter system, characterized in that, Includes the following modules: The generation module is used to perform static binary analysis on the interface driver library file of the instrument to be adapted that is connected through the physical interface, traverse the exported function symbol table, extract the function name and parameter type list, generate a unique identifier fingerprint for each exported function, and construct a functional feature index containing the correspondence between the fingerprint and the relative offset address of the function entry. The execution module is used to apply for an independent logical virtual address space according to the memory page allocation granularity of the current operating system and the segment space requirements of the interface driver library file, load the code segment and data segment of the interface driver library file into the space, and perform address relocation repair and external symbol dependency resolution based on the load base address to complete the memory residency of the driver library. The construction module is used to receive standard operation instructions issued by the upper-layer control application, parse the operator semantics and operand sequence of the instructions, retrieve the corresponding local execution function entry address in the functional feature index according to the preset mapping rules of instruction semantics and function fingerprints, and construct a call context containing parameter stack rules and function entry pointers; The update module is used to maintain a virtual state machine in memory that represents the current working logic of the instrument hardware. Before triggering the local execution function through the calling context, it uses the operators of standard operation instructions as input events to deduce the state transition of the virtual state machine. If the target state after the transition is within the preset set of legal states, the virtual state machine state is updated. The local execution function is executed through the calling context in the logical virtual address space, and the hardware return data is written to a shared data buffer protected by mutual exclusion.

10. The system according to claim 9, characterized in that, The process involves traversing the exported function symbol table, extracting the function names and parameter type lists, and generating a unique identifier fingerprint for each exported function, including: Read the function name string of the exported function, traverse the parameter list of the exported function to obtain the data type name of each parameter, and concatenate the data type names into a parameter type signature string according to the declaration order of the parameters in the list; The feature metadata is obtained by concatenating the function name string with the parameter type signature string. The feature metadata is then subjected to a SHA-256 hash operation, and the first 16 bytes of the result are used as the unique identifier fingerprint of the derived function.

Images