Implementation method and system of ivi-visa test instrument driver based on layered architecture

Abstract

This application discloses a method and system for implementing a driver for an aviation bus IVI-VISA test instrument based on a layered architecture, belonging to the technical field of digital information transmission and electronic data processing. The method includes: constructing a four-layer decoupled architecture and establishing a unidirectional call relationship from the standardized interface layer to the kernel driver layer; generating a complete data payload as a benchmark reference when executing the first type of working mode; obtaining data to be verified when executing the second and third types of working modes, and performing cross-verification using the data to be verified and the benchmark reference to complete the simulation and measurement of the bus communication protocol. This application independently abstracts each working mode, maintaining its own state machine and synchronization point to ensure that the operation of each mode does not interfere with each other, forming a standardized driver software that can be directly connected to an automated testing system. It features clear layering, ease of debugging and maintenance, strong scalability, and no need to modify the upper-layer code when the hardware platform is changed.

Description

Technical Field

[0001] This application relates to the technical field of digital information transmission and electronic data processing, specifically to a method and system for implementing an aviation bus IVI-VISA test instrument driver based on a hierarchical architecture. Background Technology

[0002] GJB 289A (People's Republic of China National Military Standard 289A) is equivalent to MIL-STD-1553B (US Military Standard 1553B, a time-division command / response type multiplexed data bus). GJB 289A is a highly reliable military data bus widely used in my country's aviation, aerospace, naval, and armored vehicle equipment. 1553B test instruments are core equipment for verifying bus communication, device compatibility, and fault tolerance.

[0003] The related technologies suffer from the following drawbacks: First, the driver software is tightly coupled with the hardware. The driver code directly manipulates register addresses, DMA (Direct Memory Access) descriptors, and interrupt vectors, requiring extensive code rewriting when replacing boards or interfaces, resulting in poor portability. Second, interfaces are inconsistent. Different manufacturers' test instruments provide varying APIs (Application Programming Interfaces), making automated testing system integration difficult. Each device change requires re-adaptation of the upper-layer software. Third, software layering is chaotic. The application layer directly calls the underlying driver, leading to frequent cross-layer calls, blurred responsibility boundaries, and low maintainability. Fourth, asynchronous interrupts and DMA completion events are directly exposed to the application layer. Developers must handle interrupt context, data races, and timeout retries themselves, resulting in high development complexity and poor system stability. Fifth, session, channel, and RT (Remote Terminal) resource management is not standardized, easily leading to resource conflicts and memory leaks in multi-instance scenarios.

[0004] Currently, the IVI-C (Interchangeable Virtual Instruments C Interface) and VISA (Virtual Instrument Software Architecture) standards only cover the general instrument interface encapsulation level. They have not formed a complete layered architecture for the three working modes of the 1553B bus: BC (Bus Controller), RT, and BM (Bus Monitor). This makes it impossible to solve key issues such as hardware isolation, asynchronous event handling, and state synchronization.

[0005] The relevant technologies have not yet provided effective technical solutions to the above problems and can no longer meet people's requirements, so they urgently need to be improved. Summary of the Invention

[0006] The main objective of this application is to provide a method and system for implementing IVI-VISA test instrument drivers based on a layered architecture, in order to solve problems such as strong coupling between drivers and hardware, inconsistent interfaces, chaotic software layering, direct exposure of interrupts and memory access, and non-standard resource management in related technologies.

[0007] The embodiments of this application adopt the following technical solutions:

[0008] According to one aspect of the embodiments of this application, a method for implementing an aviation bus IVI-VISA test instrument driver based on a layered architecture is provided, comprising: constructing a multi-level decoupled architecture, the multi-level decoupled architecture including: a standardized interface layer, a hardware abstraction layer, a bus access layer, and a kernel driver layer; establishing a unidirectional call relationship from the standardized interface layer to the kernel driver layer; creating a session identifier based on a session management mechanism; performing session identifier and device state machine verification before interface calls; executing the working mode corresponding to the current interface when the verification passes; when executing a first type of working mode, independently instantiating a first functional object through the hardware abstraction layer, shielding underlying hardware events within the hardware abstraction layer, and generating a synchronization completion flag; and synchronously reading the completion status based on the synchronization completion flag. The system calculates the complete data payload of the communication message frame and uses it as input data for bus protocol analysis. This data payload is then passed to either the second or third working mode as a cross-validation reference. When executing the second or third working mode, a second or third functional object is instantiated through the hardware abstraction layer to obtain the corresponding working mode function interface and generate RT synchronization events, or: batch monitoring data is obtained using the third working mode function interface. Based on the RT synchronization events or batch monitoring data, and combined with the complete data payload passed from the first working mode, data to be verified is obtained. Cross-validation is then performed using the data to be verified and the reference, completing the simulation and measurement of the bus communication protocol.

[0009] According to at least one specific embodiment of the present application, the standardized interface layer provides a standardized API interface conforming to the IVI-C specification, using ViSession as the unique instrument instance identifier; it receives the resource descriptor passed in by the initialization command, calls the viOpen interface of the VISA layer to open the device, creates a session identifier and binds it to the hardware abstract instance; when receiving the close command, it sequentially calls the stop hardware interface, unmapping interface and viClose interface of the VISA layer to complete the hardware stop, mapping unmapping and session close in sequence; before executing each API interface, it queries the corresponding hardware abstract instance according to the passed session identifier, performs legality verification on the interface parameters, performs state verification on the device state machine, and returns a standardized error code when the verification fails, without directly accessing the hardware registers and memory areas.

[0010] According to at least one specific embodiment of the present application, the hardware abstraction layer is used to perform independent functional abstraction for the bus controller mode, remote terminal mode, and bus monitor mode, and to provide a set of functional operation interfaces for each of the three modes. In the bus controller mode, the completion of message execution is used as the synchronization point. After the message scheduler completes the sending and receiving of a message, the state machine is updated and the upper layer is notified. In the remote terminal mode, command word matching and data update are used as the synchronization point. When a matching command word is received and the data update is completed, the state machine is updated. In the bus monitor mode, a circular buffer with separate read and write pointers is used to implement message storage. The number of readable messages is determined by comparing the difference between the read pointer and the write pointer.

[0011] According to at least one specific embodiment of the present application, the bus access layer performs the following operations in sequence: calling the viOpen interface to open a specified device and obtain a device handle; using the device handle as input, calling the viMapAddress interface to complete the address mapping of the base address register space and obtain a virtual address; based on the virtual address, calling the viRead interface or the viWrite interface to perform register read or write operations; in a DMA operation scenario, calling the viMapAddress interface again to establish an independent address mapping for the DMA buffer and passing the mapped buffer address to the kernel driver layer; in the shutdown process, resource release is performed in reverse order of initialization: calling viUnmapAddress to unmap the DMA buffer, calling viUnmapAddress to unmap the BAR space, and finally calling viClose to close the device session.

[0012] According to at least one specific embodiment of the present application, the kernel driver layer performs the following operations: when the operating system starts, it completes device enumeration of the PCI, PXI, PCIe or CPCI bus, obtains the base address register information and interrupt number of the device, and establishes an address mapping channel from the physical address to the bus access layer according to the base address register information; configures the descriptor of the DMA ring buffer, sets the buffer start address and length, and enables DMA transfer completion interrupt; configures the timing parameters of the 1553B protocol engine, the timing parameters including the synchronization header width, bit rate and response timeout; when an interrupt is triggered, it reads the interrupt status register, determines the interrupt type and reports the interrupt event to the bus access layer.

[0013] According to at least one specific implementation of the embodiments of this application, the multi-level decoupled architecture includes: a standardized interface layer, a hardware abstraction layer, a bus access layer, and a kernel driver layer, establishing a one-way call relationship from the standardized interface layer to the kernel driver layer; creating a session identifier based on a session management mechanism, performing session identifier and device state machine verification before interface calls, and executing the working mode corresponding to the current interface when the verification passes; further including: uniformly destroying the session identifier through a close instruction, and performing session validity and device state machine verification based on the session identifier before each interface call to obtain a legality verification result; using the legality verification result as the admission condition for the execution of all subsequent working modes, continuing execution only when the verification passes, otherwise returning a standardized error code.

[0014] According to at least one specific implementation of the embodiments of this application, the process of creating and destroying a session identifier includes: creating a session identifier using an initialization instruction based on a session management mechanism; when the initialization instruction is called, obtaining a VISA session handle by calling viOpen at the bus access layer, instantiating a hardware abstraction object at the hardware abstraction layer, and creating a session structure, the session structure including: a pointer to the VISA session handle, a pointer to the hardware abstraction object, a session state flag, and a copy of the device state machine; generating a unique session identifier as the index key value of the session structure, and returning the session identifier to the caller; when the close instruction is called, searching for the corresponding session structure based on the passed session identifier; sequentially calling the stop and close interfaces of the hardware abstraction object, calling the viClose interface of the VISA layer, releasing the session structure memory, and marking the session identifier as invalid; searching for the session structure based on the session identifier before executing all API interfaces, and returning a standardized error code if the search fails or the session state is invalid.

[0015] According to at least one specific embodiment of the present application, the following process is executed in bus controller mode: When the initialization interface is called, the hardware abstraction layer configures the message list of the message scheduler according to the input channel parameters, and sets the sending period and priority of each message; when the startup interface is called, the hardware abstraction layer calls the register write interface of the bus access layer to write the startup bit to the control register of the kernel driver layer, enabling DMA transfer and interrupts; during operation, the hardware abstraction layer receives interrupt events from the kernel driver layer, reads the completed message frame and its timestamp from the DMA ring buffer, and stores the message frame in the internal message queue; when the read interface is called, the hardware abstraction layer retrieves the message frame from the message queue in a blocking or non-blocking manner according to the timeout parameter input by the caller, copies the timestamp and data payload of the message frame to the buffer provided by the caller, and returns the message frame length.

[0016] According to at least one specific embodiment of the present application, the multi-level decoupling architecture further includes: a hardware abstraction instance corresponding to a single session identifier supports multiple logical channels, each logical channel independently maintains the state machine of the bus controller, remote terminal, and bus monitor; within the same logical channel, multiple remote terminal addresses are supported to be online in parallel, each remote terminal address independently configures a sub-address command word matching table, independently maintains a data buffer, and a status flag bit; resources, status, and error handling between different logical channels and between different remote terminal addresses within the same channel are mutually isolated.

[0017] According to another aspect of the embodiments of this application, a hierarchical architecture-based aviation bus IVI-VISA test instrument driver implementation system is provided, used to implement the hierarchical architecture-based aviation bus IVI-VISA test instrument driver implementation method, including: a multi-level decoupling architecture construction module: constructing a multi-level decoupling architecture, the multi-level decoupling architecture including: a standardized interface layer, a hardware abstraction layer, a bus access layer and a kernel driver layer, establishing a one-way call relationship from the standardized interface layer to the kernel driver layer; creating a session identifier based on a session management mechanism, performing session identifier and device state machine verification before interface call, and executing the working mode corresponding to the current interface when the verification passes; a first type of working mode execution module: when executing the first type of working mode, independently instantiating a first functional object through the hardware abstraction layer, shielding underlying hardware events inside the hardware abstraction layer, and generating a synchronization completion flag. Based on the synchronization completion flag, the completed communication message frames are read synchronously, the complete data payload of the message frame is calculated, and the complete data payload is used as input data for bus protocol analysis and passed to the second or third working mode as a benchmark reference for cross-validation; the second and third working mode execution modules: when executing the second or third working mode, the second or third functional object is instantiated through the hardware abstraction layer to obtain the corresponding working mode function interface to generate RT synchronization events, or: batch monitoring data is obtained using the third working mode function interface; the benchmark parameter cross-validation execution module: based on the RT synchronization event or batch monitoring data, combined with the complete data payload passed by the first working mode, the data to be verified is obtained, and cross-validation is performed using the data to be verified and the benchmark reference to complete the simulation and measurement of the bus communication protocol.

[0018] The beneficial technical effects of the embodiments of this application are: This application's embodiments establish a one-way call relationship from IVI-C to the kernel driver, achieving strict layering and isolation of responsibilities. When changing hardware platforms, only the underlying drivers and firmware need to be modified; the upper-layer standardized interfaces and applications remain completely unchanged, thus enabling a single codebase to adapt to multiple hardware interfaces and platforms such as PCI, PXI, PCIe, and CPCI.

[0019] This application employs ViSession's full lifecycle management and a multi-channel, multi-RT isolation extension mechanism to ensure complete isolation of resources and states between sessions, channels, and RT instances, eliminating the risks of resource conflicts and memory leaks. Simultaneously, interrupts and DMA events are handled internally within the HAL, with only synchronous APIs provided externally, significantly reducing application development complexity.

[0020] This application's embodiments abstract each working mode independently, maintaining its own state machine and synchronization point to ensure that the operation of each mode does not interfere with each other. The final result is a standardized driver software that can be directly integrated into automated testing systems, featuring clear layering, ease of debugging and maintenance, and strong scalability. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the specific implementation methods or related technologies of this application, the accompanying drawings used in the description of the specific implementation methods or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some implementation methods of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of the implementation method for driving the IVI-VISA test instrument based on a hierarchical architecture for aviation bus.

[0023] Figure 2 This is an architecture diagram of a hierarchical architecture-based aviation bus IVI-VISA test instrument driver implementation system.

[0024] Figure 3 This is a schematic diagram of a four-layer software architecture.

[0025] Figure 4 This is a schematic diagram of the IviSession context structure.

[0026] Figure 5 This is a schematic diagram of the BC mode message reading process. Detailed Implementation

[0027] To enable those skilled in the art to better understand the embodiments of this application, 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 a part of the implementation methods of the embodiments of this application, and not all of the implementation methods. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the protection scope of the embodiments of this application.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of the present application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0029] It should be noted that, unless otherwise specified, the implementation methods and features described in the embodiments of this application can be combined with each other. The embodiments of this application will now be described in detail with reference to the accompanying drawings and examples.

[0030] like Figure 1 The hierarchical architecture-based implementation method for avionics bus IVI-VISA test instrument drivers shown includes: Step S1: Construct a multi-level decoupled architecture, which includes: a standardized interface layer, a hardware abstraction layer, a bus access layer, and a kernel driver layer. Establish a one-way call relationship from the standardized interface layer to the kernel driver layer. Create a session identifier based on the session management mechanism. Before the interface call, verify the session identifier with the device state machine. When the verification is successful, execute the working mode corresponding to the current interface.

[0031] Step S2: When executing the first type of working mode, a first functional object is independently instantiated through the hardware abstraction layer (HAL) to shield underlying hardware events and generate a synchronization completion flag. Based on the synchronization completion flag, completed communication message frames are read synchronously, the complete data payload of the message frame is calculated, and the complete data payload is used as input data for bus protocol analysis and passed to the second or third type of working mode as a benchmark for cross-validation. In this step, shielding underlying hardware events and generating a synchronization completion flag specifically involves: obtaining the initialization instruction of the first type of working mode functional interface to complete the message scheduler initialization, starting asynchronous message transmission and reception in the buffer through the start instruction, and then shielding underlying hardware events within the hardware abstraction layer to generate a synchronization completion flag.

[0032] Step S3: When executing the second or third type of working mode, instantiate the second or third functional object through the hardware abstraction layer to obtain the corresponding working mode functional interface to generate RT synchronization events, or: obtain batch monitoring data using the third type of working mode functional interface. Specifically, in this step, batch monitoring data is obtained by using the third type of working mode functional interface through a circular buffer with separate read and write pointers.

[0033] Step S4: Based on RT synchronization events or batch monitoring data, and combined with the complete data load transmitted in the first type of working mode, obtain the data to be verified. Perform cross-validation using the data to be verified and the benchmark reference to complete the simulation and measurement of the bus communication protocol. In this step, obtaining the data to be verified is achieved by synchronously reading data through the corresponding read instructions of the standardized interface layer. During cross-validation, a bus protocol consistency decision result is generated through instruction and response matching verification. The read result is then used to perform instruction and response matching verification with the complete data load to generate the bus protocol consistency decision result, thus completing the simulation and measurement of the bus communication protocol.

[0034] Definitions: First type of operating mode: BC mode (Bus Controller Mode) The second type of working mode: RT mode (Remote Terminal Mode). The third type of operating mode: BM mode (Bus Monitor Mode). Session management mechanism: The lifecycle of instrument instances is managed through unique identifiers, including creation, binding of hardware resources, status tracking and destruction, to ensure resource isolation and secure access in multi-instance scenarios.

[0035] The first functional object is a software instance in the hardware abstraction layer that specifically implements the bus controller (BC) mode, encapsulating operational logic such as message scheduling, instruction sending, and response receiving, as well as the state machine.

[0036] The second functional object is a software instance in the hardware abstraction layer that specifically implements the remote terminal (RT) mode, encapsulating operational logic and state machines such as command word matching, data update, and status word generation.

[0037] The third functional object is a software instance in the hardware abstraction layer that specifically implements the bus monitor (BM) mode, encapsulating operational logic such as bus listening, circular buffer management, and batch data reading.

[0038] Complete data payload: The complete message frame content sent or received by the Type 1 operating mode (BC mode), including instruction words, data words, and status words, which serves as the benchmark for cross-validation.

[0039] Verification data: Data that needs to be verified, obtained from the second type of working mode (RT mode) or the third type of working mode (BM mode), and is used to compare and verify with the benchmark reference.

[0040] Cross-validation: The process of comparing the data to be validated with the benchmark reference field by field (including instruction matching, data consistency and state validity) to generate a protocol consistency decision result.

[0041] The technical solutions provided in steps S1 to S4 achieve hardware independence of the bus test instrument driver by constructing a four-layer decoupled architecture and establishing a one-way call relationship: Step S1 establishes a layered architecture and session verification mechanism; Step S2 generates a complete data load as a benchmark reference from the first type of working mode; Step S3 obtains the data to be verified from the second or third type of working mode; Step S4 cross-verifies the benchmark reference and the data to be verified to complete the simulation and measurement of the bus communication protocol.

[0042] The one-way call relationship established in step S1 provides architectural assurance for the serial execution of steps S2, S3, and S4. Each layer has clearly defined responsibilities and does not interfere with the others, thus achieving complete reuse of upper-layer code when the hardware platform is replaced. Through the collaborative cooperation of steps S1 and S2, the session verification mechanism ensures that subsequent working modes can only be executed when the verification passes, while the hardware abstraction layer's shielding of underlying events allows the first type of working mode to generate clean benchmark reference data.

[0043] The complete data payload output in step S2 is used as a benchmark and directly input into step S3 or step S4 for cross-validation.

[0044] A data transfer dependency is formed between steps S2 and S3. Through the data flow mechanism that connects the two steps, the analog output of the first type of working mode and the measurement output of the second and third types of working modes can complete the matching and verification of instructions and responses in step S4.

[0045] In summary, it can be seen that the technical solutions provided in steps S1 to S4 organically unify the three modes of bus control, terminal response, and bus monitoring, ultimately achieving the technical effect of a standardized interface that can adapt to multiple hardware platforms and eliminates the need for application development to handle underlying asynchronous logic.

[0046] Preferably, the standardized interface layer provides a standardized API interface that conforms to the IVI-C specification, using ViSession as the unique instrument instance identifier.

[0047] Upon receiving the resource descriptor passed in by the initialization command, the device is opened by calling the viOpen interface of the VISA layer, a session identifier is created and bound to the hardware abstraction instance; upon receiving the close command, the device is stopped, the mapping is unmapped and the session is closed in sequence by calling the stop hardware interface, unmapping interface and viClose interface of the VISA layer in sequence.

[0048] Before each API interface is executed, the corresponding hardware abstraction instance is queried based on the passed session identifier, the interface parameters are validated for validity, the device state machine is validated for state, and a standardized error code is returned when the validation fails. Hardware registers and memory areas are not directly accessed.

[0049] In the optimization and improvement scheme of the standardized interface layer, a standardized API interface conforming to the IVI-C specification is provided through the standardized interface layer, with ViSession as the unique instrument instance identifier. Upon receiving an initialization command, the viOpen interface of the VISA layer is called to open the device, create a session identifier, and bind it to the hardware abstract instance. Upon receiving a shutdown command, the stop hardware interface, unmapping interface, and viClose interface of the VISA layer are called sequentially to complete hardware stop, unmapping, and session closure in that order. Before executing each API interface, the corresponding hardware abstract instance is queried based on the session identifier, the interface parameters are validated for validity, and the device state machine is validated for status. If validation fails, a standardized error code is returned, and hardware registers and memory areas are not directly accessed.

[0050] By providing a standardized API interface compliant with the IVI-C specification through a standardized interface layer, and using ViSession as the unique instrument instance identifier, upper-layer applications can access test instruments from different manufacturers and on different hardware platforms in a unified manner. This standardized design works synergistically with the four-layer decoupled architecture established in step S1: the standardized interface layer acts as the external portal of the entire architecture, shielding all hardware-related differences from the lower layers. The application layer only needs to call the same API interface to control different hardware, without needing to know whether the underlying interface is PCI or PXI, or which manufacturer the board is from.

[0051] Upon receiving an initialization command, the standardized interface layer calls the viOpen interface of the VISA layer to open the device, creates a session identifier, and binds it to a hardware abstraction instance. This directly corresponds to the session identifier and hardware abstraction instance binding mechanism described in step S1, realizing the association locking between the standardized interface layer and the hardware abstraction layer. Upon receiving a shutdown command, the stop hardware interface, unmapping interface, and viClose interface are called sequentially to complete hardware stop, mapping unmapping, and session shutdown in that order. This reverse-order release process forms a symmetrical management with the aforementioned creation process, echoing the serial initialization and reverse-order release mechanism described in the bus access layer, ensuring complete resource lifecycle management from the upper-layer session to the lower-layer hardware.

[0052] Before each API interface is executed, the standardized interface layer queries the corresponding hardware abstraction instance based on the input session identifier, performs validity checks on the interface parameters, and verifies the state of the device state machine. If verification fails, a standardized error code is returned. This pre-verification mechanism works in conjunction with the design of using the validity verification result in step S1 as an admission condition: the verification operation is completed at the standardized interface layer, and only after successful verification is the call passed to the lower layer. The standardized interface layer does not directly access hardware registers and memory areas; all hardware access is completed through the lower-level interface. This principle of separation of duties is consistent with the unidirectional call relationship established in step S1, ensuring the clarity and security of the layering. When verification fails, the standardized interface layer directly returns a standardized error code, without passing invalid calls down, thus preventing the consumption of underlying resources by illegal operations.

[0053] Preferably, the hardware abstraction layer is used to perform independent functional abstraction for the bus controller mode, remote terminal mode and bus monitor mode respectively, and to provide a set of functional operation interfaces for each of the three modes. The set of functional operation interfaces includes: init initialization interface, start start interface, stop stop interface, readMessage read message interface and writeMessage write message interface.

[0054] In bus controller mode, the state machine is updated and the upper layer is notified after the message scheduler completes the sending and receiving of a message, with the completion of message execution as the synchronization point.

[0055] In remote terminal mode, command word matching and data update are used as synchronization points. The state machine is updated after a matching command word is received and the data update is completed.

[0056] In bus monitor mode, message storage is implemented using a circular buffer with separate read and write pointers. The number of readable messages is determined by comparing the difference between the read pointer and the write pointer.

[0057] In the optimized hardware abstraction layer scheme, the bus controller mode, remote terminal mode, and bus monitor mode are each abstracted independently, providing a unified set of functional operation interfaces (including init, start, stop, readMessage, and writeMessage) for each mode. Based on this, differentiated synchronization strategies are adopted for each of the three modes according to their respective operating characteristics: the bus controller mode uses message execution completion as the synchronization point, the remote terminal mode uses command word matching and data update as the synchronization point, and the bus monitor mode uses a circular buffer with separate read and write pointers to implement message storage and retrieval.

[0058] The hardware abstraction layer abstracts the functions of the three modes independently and provides a unified set of function operation interfaces for each mode. This allows the upper-level standardized interface layer to call the operation interfaces of different modes in the same way without being aware of the implementation differences within each mode. The interface design and independent function abstraction work together to achieve the technical effect of isolation through a unified interface, providing a standardized calling method for upper-level applications.

[0059] The three modes employ differentiated synchronization strategies, each maintaining independent synchronization points and state machines, ensuring no interference between them. The bus controller mode uses message completion as the synchronization point, ensuring the sender accurately knows the transmission and reception status of each message. The remote terminal mode uses command matching as the synchronization point, guaranteeing the responder completes data updates within the correct time window. The bus monitor mode uses a circular buffer with separate read and write pointers, allowing data writing and reading to occur in parallel without mutual exclusion. These three synchronization strategies work independently yet collaboratively, jointly achieving accurate simulation and measurement of the entire bus communication process.

[0060] The synergistic cooperation between the unified interface and the differentiated synchronization strategy enables the embodiments of this application to meet the different real-time requirements and data throughput needs of the three modes—bus controller, remote terminal, and bus monitor—while maintaining interface standardization, thereby achieving complete encapsulation of each working mode by the hardware abstraction layer.

[0061] In the optimized hardware abstraction layer scheme, the bus controller mode, remote terminal mode, and bus monitor mode are each abstracted independently, providing a unified set of functional operation interfaces (including init, start, stop, readMessage, and writeMessage) for each mode. Based on this, differentiated synchronization strategies are adopted for each of the three modes according to their respective operating characteristics: the bus controller mode uses message execution completion as the synchronization point, the remote terminal mode uses command word matching and data update as the synchronization point, and the bus monitor mode uses a circular buffer with separate read and write pointers to implement message storage and retrieval.

[0062] The hardware abstraction layer abstracts the functions of the three modes independently and provides a unified set of function operation interfaces for each mode. This allows the upper-level standardized interface layer to call the operation interfaces of different modes in the same way without being aware of the implementation differences within each mode. The interface design and independent function abstraction work together to achieve the technical effect of isolation through a unified interface, providing a standardized calling method for upper-level applications.

[0063] The three modes employ differentiated synchronization strategies, each maintaining independent synchronization points and state machines, ensuring no interference between them. The bus controller mode uses message completion as the synchronization point, ensuring the sender accurately knows the transmission and reception status of each message. The remote terminal mode uses command matching as the synchronization point, guaranteeing the responder completes data updates within the correct time window. The bus monitor mode uses a circular buffer with separate read and write pointers, allowing data writing and reading to occur in parallel without mutual exclusion. These three synchronization strategies work independently yet collaboratively, jointly achieving accurate simulation and measurement of the entire bus communication process.

[0064] The synergistic cooperation between the unified interface and the differentiated synchronization strategy enables the embodiments of this application to meet the different real-time requirements and data throughput needs of the three modes—bus controller, remote terminal, and bus monitor—while maintaining interface standardization, thereby achieving complete encapsulation of each working mode by the hardware abstraction layer.

[0065] Preferably, the bus access layer performs the following operations in sequence: calling the viOpen interface to open the specified device and obtain the device handle; using the device handle as input, calling the viMapAddress interface to complete the address mapping of the base address register space and obtain the virtual address; and according to the virtual address, calling the viRead interface or the viWrite interface to perform register read or write operations.

[0066] In the DMA operation scenario, the viMapAddress interface is called again to establish an independent address mapping for the DMA buffer, and the mapped buffer address is passed to the kernel driver layer. The shutdown process is independent of the DMA operation scenario. In the shutdown process, resource release is performed in reverse order of initialization: viUnmapAddress is called to unmap the DMA buffer, viUnmapAddress is called to unmap the BAR space, and finally viClose is called to close the device session.

[0067] The operation of opening devices, address mapping, register reading and writing is serialized by the bus access layer, so that each subsequent operation depends on the execution result of the previous step, forming a strict timing dependency. The serial execution mechanism ensures the determinism and predictability of the resource initialization process and avoids resource access failure or system abnormality caused by disordered operation sequence.

[0068] In DMA operation scenarios, an independent address mapping is established for the DMA buffer, distinguishing it from the ordinary BAR space mapping. This ensures that the DMA data transfer channel and the register access channel are isolated from each other in the address space. The shutdown process executes resource release in reverse order of initialization, releasing resources that were requested later first and resources that were requested earlier last. This symmetrical resource management mechanism works closely with the aforementioned serial initialization process, fundamentally eliminating the risks of resource leaks and dangling pointer accesses.

[0069] The coordinated operation of serial initialization and reverse release enables the bus access layer to complete the safe management and release of device resources in a defined timing sequence with limited computing resources. This provides a stable and reliable low-level access interface for the upper hardware abstraction layer, thereby ensuring the resource security of the entire test instrument driver in long-term operation and multi-session concurrent scenarios.

[0070] Preferably, the kernel driver layer performs the following operations: when the operating system starts, it completes device enumeration of the PCI, PXI, PCIe or CPCI bus, obtains the base address register information and interrupt number of the device, and establishes an address mapping channel from the physical address to the bus access layer based on the base address register information.

[0071] Configure the descriptor of the DMA ring buffer, set the buffer start address and length, and enable DMA transfer completion interrupt; configure the timing parameters of the 1553B protocol engine, including the synchronization header width, bit rate and response timeout.

[0072] When an interrupt is triggered, the interrupt status register is read, the interrupt type is determined, and the interrupt event is reported to the bus access layer. The kernel driver layer does not contain the business logic of the bus controller, remote terminal, and bus monitor, nor does it contain session management logic.

[0073] In the optimized kernel driver layer scheme, the kernel driver layer completes bus device enumeration during operating system startup, obtains base address register information and interrupt numbers, and establishes an address mapping channel from physical address to bus access layer. It configures the DMA ring buffer descriptor and timing parameters of the 1553B protocol engine (including synchronization header width, bit rate, and response timeout). When an interrupt is triggered, it reads the interrupt status register and reports the interrupt event to the upper layer. The kernel driver layer does not contain any business logic or session management logic.

[0074] By establishing device enumeration and address mapping channels during the startup phase through the kernel driver layer, the bus access layer can access hardware registers through a unified virtual address without being aware of the differences in the distribution of underlying physical addresses. By using the address mapping mechanism in conjunction with the aforementioned serial initialization process of the bus access layer, a standardized access path decoupled from the hardware is provided for the upper layer.

[0075] By configuring the DMA ring buffer descriptor and the 1553B protocol engine timing parameters, the kernel driver layer pushes the establishment of data channels and the control of protocol timing down to the lowest level. The coordinated operation of the DMA ring buffer and the interrupt mechanism enables high-speed data transfer without CPU intervention, triggering an interrupt only when the transfer is complete to notify the upper layer. This achieves hardware acceleration of data transfer and protocol processing, reducing CPU load.

[0076] The kernel driver layer strictly defines its responsibilities, containing no business logic or session management logic. It is solely responsible for hardware register operations, DMA transfer control, and interrupt reporting, achieving a clearly defined architectural design and establishing a clear division of labor with the hardware abstraction layer and bus access layer. The kernel driver layer only handles hardware timing and data movement, while business logic is entirely handled by the upper layers. When changing hardware platforms, only the implementation code of this layer and the hardware abstraction layer needs to be modified; the upper-layer interfaces and application layer remain completely unaffected, thus achieving true hardware independence and portability.

[0077] Preferably, step S1 involves constructing a multi-level decoupled architecture, which includes: a standardized interface layer, a hardware abstraction layer, a bus access layer, and a kernel driver layer. A unidirectional call relationship is established from the standardized interface layer to the kernel driver layer. Based on a session management mechanism, an initialization instruction is used to create a session identifier, which is used to uniquely bind the hardware abstraction instance to the bus access session. Before the interface call, the session identifier and device state machine are verified. If the verification passes, the working mode corresponding to the current interface is executed. This further includes: The session identifier is destroyed uniformly by closing the command, and the session validity and device state machine verification are performed based on the session identifier before each interface call to obtain the legality verification result. The legality verification result is used as the admission condition for all subsequent working modes, and execution continues only when the verification passes, otherwise a standardized error code is returned.

[0078] As an example, the process of creating and destroying the session identifier in step S1 includes: Based on the session management mechanism, a session identifier is created using initialization instructions. When the initialization instructions are called, viOpen is called in the bus access layer to obtain the VISA session handle, and a hardware abstraction object is instantiated in the hardware abstraction layer to create a session structure. The session structure includes: a pointer to the VISA session handle, a pointer to the hardware abstraction object, a session state flag, and a copy of the device state machine. A unique session identifier is generated as the index key value of the session structure, and the session identifier is returned to the caller; when the close command is invoked, the corresponding session structure is found based on the passed session identifier; The stop and close interfaces of the hardware abstraction object are called in sequence, the viClose interface of the VISA layer is called, the memory of the session structure is released, and the session identifier is marked as invalid. Before executing any API interface, the session structure is searched based on the session identifier. If the search fails or the session state is invalid, a standardized error code is returned.

[0079] In the optimization and improvement scheme for constructing a multi-level decoupled architecture, this specific implementation mainly targets the application scenario of lifecycle management, specifically how a session is securely created and destroyed. Step S1 constructs a four-layer decoupled architecture and establishes a one-way call relationship. Based on the session management mechanism, an initialization instruction creates a session identifier, which uniquely binds to the hardware abstraction instance and the bus access session. Before interface calls, the session identifier and device state machine are verified, and the validity verification result serves as the admission condition for all subsequent working modes. The session identifier is uniformly destroyed using a close instruction. During destruction, the stop and close interfaces of the hardware abstraction object and the viClose interface of the VISA layer are called sequentially to release the session structure memory and mark the session identifier as invalid.

[0080] By uniquely binding the hardware abstraction instance to the bus access session using a session identifier, an association and locking mechanism is established between the session layer, the hardware abstraction layer, and the bus access layer. This binding mechanism works in conjunction with the execution of the working modes in subsequent steps S2 and S3: when the application layer calls the interface of any working mode, the system first finds the corresponding hardware abstraction instance based on the session identifier, then performs state verification based on the device state machine copy in that instance. Only after the verification passes can the specific operation be executed, ensuring that all operations under the same session are executed in the correct resource context and avoiding resource confusion in multi-session scenarios.

[0081] The validity verification result serves as the entry condition for all subsequent working modes, forming a seamless control link with the generation of the synchronization completion flag in step S2 and the data acquisition in step S3. Passing the verification is a necessary prerequisite for the execution of subsequent steps; any verification failure will immediately return a standardized error code and prevent further processing. This pre-verification mechanism, working in conjunction with the serial execution logic, implements a security control paradigm of verification before execution, fundamentally preventing illegal operations caused by invalid sessions or incorrect states.

[0082] By executing a reverse-order destruction process through the shutdown command, the stop and close interfaces of the hardware abstraction object and the viClose interface of the VISA layer are called sequentially, forming a strict symmetrical management with the forward initialization process during session creation. This symmetrical lifecycle management mechanism echoes the reverse-order resource release described in the bus access layer, ensuring that all resources from the session layer to the hardware layer are correctly released. When multiple sessions exist concurrently, the session identifiers of each session are independent, and the session structures are isolated from each other. Together with the aforementioned admission verification mechanism, this achieves secure resource isolation in multi-instance scenarios, eliminating the risk of resource leakage and conflicts.

[0083] Preferably, the following process is executed in bus controller mode: When the initialization interface is called, the hardware abstraction layer configures the message list of the message scheduler according to the incoming channel parameters, and sets the sending period and priority of each message; when the startup interface is called, the hardware abstraction layer calls the register write interface of the bus access layer to write the startup bit to the control register of the kernel driver layer, enabling DMA transfer and interrupts. During operation, the hardware abstraction layer receives interrupt events from the kernel driver layer, reads completed message frames and their timestamps from the DMA ring buffer, and stores the message frames in the internal message queue. When the read interface is called, the hardware abstraction layer retrieves the message frame from the message queue in a blocking or non-blocking manner according to the timeout parameter passed by the caller, copies the timestamp and data payload of the message frame to the buffer provided by the caller, and returns the message frame length.

[0084] In the optimized bus controller module, the message list, sending cycle, and priority of the message scheduler are configured during the initialization phase through the hardware abstraction layer, decoupling the message scheduling strategy in bus controller mode from the underlying hardware implementation. This configuration mechanism works in conjunction with the subsequent boot process: after configuration, the boot interface writes the boot bit to the kernel driver layer through the bus access layer, enabling DMA transfer and interrupts, thus achieving timing integration between software configuration and hardware execution. The hardware abstraction layer does not need to be aware of the specific layout of the DMA descriptor or the bit definition of the interrupt register; it can complete the boot operation simply through the standardized register write interface.

[0085] During operation, the Hardware Abstraction Layer (HAL) receives interrupt events from the kernel driver layer, reads completed message frames and their timestamps from the DMA circular buffer, and stores them in an internal message queue. Through the coordination mechanism between interrupt handling and the message queue, the HAL can quickly complete data transfer within the interrupt context, handing over message frame parsing and waiting to the upper layer for processing. The interrupt event reporting mechanism works in conjunction with the one-way call relationship established in step S1. The interrupt flow is upward from the kernel driver layer to the bus access layer to the HAL, forming an asynchronous channel in the opposite direction to the control flow (standardized interface layer → hardware abstraction layer → bus access layer → kernel driver layer), thus realizing bidirectional flow of control and data.

[0086] When the read interface is invoked, the hardware abstraction layer retrieves message frames from the message queue in either a blocking or non-blocking manner based on the timeout parameter passed by the caller. This synchronous API design works in conjunction with the aforementioned internal mechanism for asynchronous interrupt handling: the asynchronous complexity of interrupts is completely encapsulated within the hardware abstraction layer, presenting a simple synchronous read interface to the outside world. The blocking mode is suitable for scenarios with low real-time requirements, while the non-blocking mode is suitable for high real-time scenarios requiring polling. These two modes, together with the aforementioned message queue storage mechanism, constitute a flexible data read strategy, allowing upper-layer application developers to avoid handling interrupt context, DMA completion flags, or the management of read / write pointers for the circular buffer.

[0087] Preferably, the multi-level decoupling architecture further includes: A single session identifier corresponds to a hardware abstraction instance that supports multiple logical channels. Each logical channel independently maintains the state machine of the bus controller, remote terminals, and bus monitor. Within the same logical channel, multiple remote terminal addresses can be online in parallel. Each remote terminal address independently configures a sub-address command word matching table, independently maintains a data buffer, and maintains status flags. Resources, status, and error handling are isolated between different logical channels and between different remote terminal addresses within the same channel.

[0088] An anomaly in a single channel or a single remote terminal does not affect the normal operation of other channels and other remote terminals; when changing the hardware platform, only the implementation code of the hardware abstraction layer and the kernel driver layer needs to be modified, while the API interface of the standardized interface layer and the upper-layer application code remain unchanged.

[0089] This implementation primarily addresses an improved solution for supporting the parallel operation of multiple channels and multiple remote terminal instances within a single session without interference. The multi-layered decoupling architecture further supports isolation between multiple channels and multiple remote terminal instances: a single session's corresponding hardware abstraction instance supports multiple logical channels, each channel independently maintaining a state machine for three working modes; multiple remote terminal addresses can operate online in parallel within the same channel, with each terminal independently configuring a command word matching table, maintaining its own data buffer, and status flags. Resources, states, and error handling are isolated between different channels and between different terminals within the same channel; an anomaly in a single channel or terminal does not affect the normal operation of other channels and terminals. When changing the hardware platform, only the hardware abstraction layer and kernel driver layer need to be modified; the standardized interface layer and upper-layer application code remain unchanged.

[0090] Multiple logical channels are supported by a single hardware abstraction instance corresponding to a single session identifier, and each logical channel independently maintains the state machine of the bus controller, remote terminal, and bus monitor, achieving channel-level resource isolation. This multi-channel support mechanism works in conjunction with the session identifier binding mechanism established in step S1: one session identifier can manage multiple logical channels, each channel has its own independent copy of the state machine, and state transitions between channels do not interfere with each other. When a channel performs a start or stop operation, the operating state of other channels is not affected in any way, thus realizing the ability to simulate multiple independent bus networks in parallel on the same hardware device.

[0091] Multiple remote terminal addresses can operate online in parallel within the same logical channel. Each remote terminal address independently configures its sub-address command word matching table, maintains its own data buffer, and manages its status flags. This multi-terminal isolation mechanism works in conjunction with the remote terminal mode synchronization strategy described in step S3: each remote terminal has its own independent command matching synchronization point and independent data update buffer. When the bus controller sends a command, the hardware abstraction layer routes the command to the corresponding remote terminal instance for processing based on the terminal address in the command. Multiple remote terminals can simultaneously respond to commands from different sub-addresses, and their data buffers, status flags, and error handling are completely isolated from each other. Configuration errors or data anomalies in a single terminal will not propagate to other terminals within the same channel.

[0092] Resources, states, and error handling are isolated between different logical channels and between different remote terminal addresses within the same channel. An anomaly in a single channel or a single remote terminal does not affect the normal operation of other channels and other terminals. A complete fault-tolerant chain is formed through multi-level isolation mechanisms and the legality verification in step S1 and the cross-validation in step S4: when any channel or terminal fails, the fault is confined to the smallest isolation domain and will not cause the entire system to crash. When changing the hardware platform, only the implementation code of the hardware abstraction layer and the kernel driver layer needs to be modified. The API interface of the standardized interface layer and the upper-layer application code remain unchanged. This isolation mechanism works in conjunction with the four-layer decoupled architecture established in step S1, enabling the embodiments of this application to support large-scale expansion from single-channel single-terminal to multi-channel multi-terminal while maintaining interface standardization, and ensuring stable operation of the system in complex scenarios.

[0093] like Figure 2 The hierarchical architecture-based aviation bus IVI-VISA test instrument driver implementation system shown herein is used to implement the hierarchical architecture-based aviation bus IVI-VISA test instrument driver implementation method described in any specific embodiment of this application, including: Multi-level decoupling architecture construction module: Constructs a multi-level decoupling architecture, which includes: a standardized interface layer, a hardware abstraction layer, a bus access layer, and a kernel driver layer; establishes a one-way call relationship from the standardized interface layer to the kernel driver layer; creates a session identifier based on the session management mechanism; performs session identifier and device state machine verification before interface call; and executes the working mode corresponding to the current interface when the verification passes. The first type of working mode execution module: When executing the first type of working mode, the first functional object is independently instantiated through the hardware abstraction layer. The underlying hardware events are shielded inside the hardware abstraction layer, and a synchronization completion flag is generated. Based on the synchronization completion flag, the completed communication message frame is read synchronously, the complete data payload of the message frame is calculated, and the complete data payload is used as the input data for bus protocol analysis and passed to the second type of working mode or the third type of working mode as a benchmark reference for cross-validation. The second and third working mode execution modules: When executing the second or third working mode, the second or third functional object is instantiated through the hardware abstraction layer to obtain the corresponding working mode function interface to generate RT synchronization events, or: the third working mode function interface is used to obtain batch monitoring data. The benchmark parameter cross-validation execution module obtains the data to be verified based on RT synchronous events or batch monitoring data, combined with the complete data load transmitted by the first type of working mode. It then performs cross-validation with the benchmark reference using the data to be verified to complete the simulation and measurement of the bus communication protocol.

[0094] The implementation methods of the system described above are merely illustrative. For example, the various functional modules, units, or subsystems within the system may or may not be physically separate, or they may or may not be physical units; that is, they may be located in the same place or distributed across multiple different systems and their subsystems or modules. Those skilled in the art can select some or all of the functional modules, units, or subsystems to achieve the objectives of the embodiments of the present invention according to actual needs. Those skilled in the art can understand and implement the above-described situations without any creative effort.

[0095] like Figure 3 , 4 As shown in Figures 5 and 6, the specific content of the embodiments of this application will be further explained through the implementation methods of the embodiments of this application in specific application scenarios: This application proposes a four-layer decoupled software architecture to implement a standardized, hardware-independent, and highly reliable 1553B test instrument driver, wherein: 3.1 Four-layer architecture: 1. IVI-C Driver Layer: Standardized API, Session Management, State Machine, Error Codes.

[0096] 2. HAL Hardware Abstraction Layer: BC / RT / BM function abstraction, event digestion, hardware shielding.

[0097] 3. VISA Access Layer: Device opening, memory mapping, register access, interrupt management.

[0098] 4. Kernel driver / firmware layer: registers, DMA, interrupts, 1553B underlying timing.

[0099] 3.2 Core Innovations: 1. Strict hierarchical structure and unidirectional dependency The call relationship is fixed: IVI-C → HAL → VISA → Kernel, and the lower layer does not call back to the upper layer.

[0100] 2. ViSession Session Lifecycle Management Session binding to HAL and VISA, multi-instance isolation, secure creation and destruction.

[0101] 3. Asynchronous sinking + synchronous API Interrupts and DMA are handled internally by HAL; applications only call the synchronization interface.

[0102] 4. Independent Abstraction and Synchronization Strategies for BC / RT / BM Each mode operates independently, with its own state machine and synchronization point, and they do not interfere with each other.

[0103] 5. Multi-channel, multi-RT isolation expansion Supports multiple channels on a single device and multiple RTs on a single channel, with complete resource isolation.

[0104] 3.3 Beneficial effects: It achieves a single codebase that adapts to multiple hardware, interfaces, and platforms. Through interface standards, it can be directly integrated into automated testing systems. It features clear layering, making it easy to debug, maintain, and upgrade. It simplifies the application development process, eliminates the need to handle underlying asynchronous logic, and is leak-free, conflict-free, and highly stable, ensuring resource security. It also has strong scalability, supporting channels, RT, and other methods, allowing for rapid functional expansion. 4. Detailed Implementation: 4.1 IVI-C Driver Layer supply: CAV1553_init, CAV1553_close, CAV1553ConfigureBcInit / Start / Stop、 CAV1553_BcRead / Write, CAV1553_RtRead / Write, CAV1553_BmRead, Status query, diagnosis, and information query interfaces.

[0106] 4.2 HAL Hardware Abstraction Layer Implement the Hal1553Device, Hal1553Bc, Hal1553Rt, and Hal1553Bm classes to encapsulate messages, buffers, timestamps, and state synchronization.

[0107] 4.3 VISA Access Layer Implement device opening, address mapping, register reading and writing, and event handling.

[0108] 4.4 Kernel Driver / Firmware Layer Implement PCI enumeration, BAR mapping, DMA, interrupts, and 1553B timing logic.

[0109] 4.5 Typical BC Model Process 1. Call CAV1553_init to open the device and create a session; 2. Call CAV1553ConfigureBcInit to initialize BC; 3. Call CAV1553ConfigureBcStart to start the schedule; 4. Call CAV1553_BcRead to synchronously read messages; 5. Call CAV1553_close to stop BC, release resources, and close the session.

[0110] 4.6 Hardware Adaptation Methods Replacing the hardware only requires updating the HAL + kernel driver; the IVI-C and application layers remain completely unchanged.

[0111] All features disclosed in the embodiments of this application, or all steps in the disclosed methods or processes, may be combined in any way, except for mutually exclusive features and / or steps. Any feature disclosed in the specification of the embodiments of this application, unless specifically stated otherwise, may be replaced by other equivalent or similar alternative features. That is, unless specifically stated otherwise, each feature is merely one example of a series of equivalent or similar features. Throughout the specification, the same reference numerals indicate the same elements.

[0112] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification of embodiments (including the corresponding claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification of embodiments (including the corresponding claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0113] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of this application, and are not intended to limit them. Although the embodiments of this application have been described in detail with reference to the foregoing specific embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing specific embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions provided by the specific embodiments of this application.

Claims

1. A method for implementing IVI-VISA test instrument driver based on layered architecture, characterized in that, include: A multi-level decoupled architecture is constructed, which includes: a standardized interface layer, a hardware abstraction layer, a bus access layer, and a kernel driver layer. A one-way call relationship is established from the standardized interface layer to the kernel driver layer. A session identifier is created based on the session management mechanism. Before the interface call, the session identifier is verified with the device state machine. When the verification is successful, the working mode corresponding to the current interface is executed. When executing the first type of working mode, the first functional object is independently instantiated through the hardware abstraction layer. The underlying hardware events are shielded inside the hardware abstraction layer, and a synchronization completion flag is generated. Based on the synchronization completion flag, the completed communication message frame is read synchronously, the complete data payload of the message frame is calculated, and the complete data payload is used as the input data for bus protocol analysis and passed to the second type of working mode or the third type of working mode as a benchmark for cross-validation. When executing the second or third type of working mode, the second or third functional object is instantiated through the hardware abstraction layer to obtain the corresponding working mode function interface to generate RT synchronization events, or: the third type of working mode function interface is used to obtain batch monitoring data. Based on RT synchronous events or batch monitoring data, and combined with the complete data load transmitted in the first type of working mode, the data to be verified is obtained. Cross-verification is performed using the data to be verified and the benchmark reference to complete the simulation and measurement of the bus communication protocol.

2. The layered architecture based avionics bus IVI-VISA tester instrument driver implementation method according to claim 1, wherein, The standardized interface layer provides a standardized API interface that conforms to the IVI-C specification, using ViSession as the unique instrument instance identifier; Upon receiving the resource descriptor passed in by the initialization command, the device is opened by calling the viOpen interface of the VISA layer, a session identifier is created and bound to the hardware abstraction instance; upon receiving the close command, the device is stopped, the mapping is unmapped and the session is closed in sequence by calling the stop hardware interface, unmapping interface and viClose interface of the VISA layer in sequence. Before each API interface is executed, the corresponding hardware abstraction instance is queried based on the passed session identifier, the interface parameters are validated for validity, the device state machine is validated for state, and a standardized error code is returned when the validation fails. Hardware registers and memory areas are not directly accessed.

3. The layered architecture based avionics bus IVI-VISA tester instrument driver implementation method according to claim 1, wherein, The hardware abstraction layer is used to perform independent functional abstraction for the bus controller mode, remote terminal mode and bus monitor mode respectively, and to provide a set of functional operation interfaces for each of the three modes. In bus controller mode, the state machine is updated and the upper layer is notified after the message scheduler completes the sending and receiving of a message, with the completion of message execution as the synchronization point. In remote terminal mode, command word matching and data update are used as synchronization points. When a matching command word is received and the data update is completed, the state machine is updated. In bus monitor mode, message storage is implemented using a circular buffer with separate read and write pointers. The number of readable messages is determined by comparing the difference between the read pointer and the write pointer.

4. The layered architecture based avionics bus IVI-VISA tester instrument driver implementation method according to claim 1, wherein, The bus access layer performs the following operations in sequence: calls the viOpen interface to open the specified device and obtain the device handle; uses the device handle as input, calls the viMapAddress interface to complete the address mapping of the base address register space and obtain the virtual address; Based on the virtual address, call the viRead or viWrite interface to perform register read or write operations; In the DMA operation scenario, the viMapAddress interface is called again to establish an independent address mapping for the DMA buffer, and the mapped buffer address is passed to the kernel driver layer. In the shutdown process, resource release is performed in reverse order of initialization: viUnmapAddress is called to unmap the DMA buffer, viUnmapAddress is called to unmap the BAR space, and finally viClose is called to close the device session.

5. The layered architecture based avionics bus IVI-VISA tester instrument driver implementation method according to claim 1, wherein, The kernel driver layer performs the following operations: when the operating system starts, it completes device enumeration of the PCI, PXI, PCIe or CPCI bus, obtains the base address register information and interrupt number of the device, and establishes an address mapping channel from the physical address to the bus access layer based on the base address register information. Configure the descriptor of the DMA ring buffer, set the buffer start address and length, and enable DMA transfer completion interrupt; configure the timing parameters of the 1553B protocol engine, including the synchronization header width, bit rate and response timeout. When an interrupt is triggered, the interrupt status register is read, the interrupt type is determined, and the interrupt event is reported to the bus access layer.

6. The layered architecture based avionics bus IVI-VISA tester instrument driver implementation method according to claim 1, wherein, The multi-level decoupled architecture includes: a standardized interface layer, a hardware abstraction layer, a bus access layer, and a kernel driver layer, establishing a unidirectional call relationship from the standardized interface layer to the kernel driver layer; creating a session identifier based on a session management mechanism, verifying the session identifier against the device state machine before interface calls, and executing the working mode corresponding to the current interface when the verification passes, further including: The session identifier is destroyed uniformly by closing the command, and the session validity and device state machine verification are performed based on the session identifier before each interface call to obtain the legality verification result. The legality verification result is used as the admission condition for all subsequent working modes, and execution continues only when the verification passes, otherwise a standardized error code is returned.

7. The layered architecture based avionics bus IVI-VISA tester instrument driver implementation method according to claim 6, wherein, The creation and destruction of session identifiers include: Based on the session management mechanism, a session identifier is created using initialization instructions. When the initialization instructions are called, viOpen is called in the bus access layer to obtain the VISA session handle, and a hardware abstraction object is instantiated in the hardware abstraction layer to create a session structure. The session structure includes: a pointer to the VISA session handle, a pointer to the hardware abstraction object, a session state flag, and a copy of the device state machine. A unique session identifier is generated as the index key value of the session structure, and the session identifier is returned to the caller; when the close command is invoked, the corresponding session structure is found based on the passed session identifier; The stop and close interfaces of the hardware abstraction object are called in sequence, the viClose interface of the VISA layer is called, the memory of the session structure is released, and the session identifier is marked as invalid. Before executing any API interface, the session structure is searched based on the session identifier. If the search fails or the session state is invalid, a standardized error code is returned.

8. The layered architecture based avionics bus IVI-VISA tester instrument driver implementation method according to claim 1, wherein, Execute the following procedure in bus controller mode: When the initialization interface is called, the hardware abstraction layer configures the message list of the message scheduler according to the incoming channel parameters, and sets the sending period and priority of each message; when the startup interface is called, the hardware abstraction layer calls the register write interface of the bus access layer to write the startup bit to the control register of the kernel driver layer, enabling DMA transfer and interrupts. During operation, the hardware abstraction layer receives interrupt events from the kernel driver layer, reads completed message frames and their timestamps from the DMA ring buffer, and stores the message frames in the internal message queue. When the read interface is called, the hardware abstraction layer retrieves the message frame from the message queue in a blocking or non-blocking manner according to the timeout parameter passed by the caller, copies the timestamp and data payload of the message frame to the buffer provided by the caller, and returns the message frame length.

9. The layered architecture based avionics bus IVI-VISA tester instrument driver implementation method according to claim 1, wherein, The multi-level decoupling architecture further includes: A single session identifier corresponds to a hardware abstraction instance that supports multiple logical channels. Each logical channel independently maintains the state machine of the bus controller, remote terminals, and bus monitor. Within the same logical channel, multiple remote terminal addresses can be online in parallel. Each remote terminal address independently configures a sub-address command word matching table, independently maintains a data buffer, and maintains status flags. Resources, status, and error handling are isolated between different logical channels and between different remote terminal addresses within the same channel.

10. The system for implementing the method for implementing the IVI-VISA test instrument driver based on the layered architecture of the aviation bus according to any one of claims 1 to 9, characterized in that, include: Multi-level decoupling architecture construction module: Constructs a multi-level decoupling architecture, which includes: a standardized interface layer, a hardware abstraction layer, a bus access layer, and a kernel driver layer; establishes a one-way call relationship from the standardized interface layer to the kernel driver layer; creates a session identifier based on the session management mechanism; performs session identifier and device state machine verification before interface call; and executes the working mode corresponding to the current interface when the verification passes. The first type of working mode execution module: When executing the first type of working mode, the first functional object is independently instantiated through the hardware abstraction layer. The underlying hardware events are shielded inside the hardware abstraction layer, and a synchronization completion flag is generated. Based on the synchronization completion flag, the completed communication message frame is read synchronously, the complete data payload of the message frame is calculated, and the complete data payload is used as the input data for bus protocol analysis and passed to the second type of working mode or the third type of working mode as a benchmark reference for cross-validation. The second and third working mode execution modules: When executing the second or third working mode, the second or third functional object is instantiated through the hardware abstraction layer to obtain the corresponding working mode function interface to generate RT synchronization events, or: the third working mode function interface is used to obtain batch monitoring data. The benchmark parameter cross-validation execution module obtains the data to be verified based on RT synchronous events or batch monitoring data, combined with the complete data load transmitted by the first type of working mode. It then performs cross-validation with the benchmark reference using the data to be verified to complete the simulation and measurement of the bus communication protocol.

Images