ARINC818 airborne display module test method, system and medium

Abstract

The invention relates to the technical field of electronic equipment testing, and discloses an ARINC818 airborne display module testing method and system and a medium, and the ARINC818 airborne display module testing method comprises the steps: obtaining test configuration information containing a predefined video time sequence parameter and a protocol field parameter, and to-be-sent image data; generating a transmission time sequence according to the video time sequence parameter, packaging the image data into a video excitation signal conforming to an ARINC818 protocol in combination with the protocol field parameter, and sending the video excitation signal to the tested equipment; collecting a video feedback signal of the tested equipment, and obtaining actual protocol field information, video time sequence parameters and image data through protocol analysis and data extraction; and finally, comparing the actual data with the test configuration information and the source image data to verify the consistency of the tested airborne display module. According to the invention, accurate testing and verification of the bottom-layer time sequence and the protocol level of the airborne display module can be realized.

Description

Technical Field

[0001] This application relates to the field of electronic device testing technology, specifically to the testing methods, systems and media for the ARINC818 airborne display module. Background Technology

[0002] ARINC818 (Avionics Digital Video Bus) is widely used in the airborne display systems of modern large passenger aircraft due to its high bandwidth and low latency. During the research and development and airworthiness certification of airborne display modules, rigorous testing and verification of the module's signal reception and processing capabilities and signal output quality are required to ensure that its functionality and performance meet design requirements under various operating conditions. However, existing technologies have many limitations in testing airborne display modules. At the excitation end, commercial graphics cards or general-purpose video sources are typically used. These devices output fixed video timing, making it impossible to simulate non-standard timing parameters, and it is difficult to flexibly configure the underlying fields of the ARINC818 protocol to test boundary conditions. At the acquisition end, general-purpose video capture cards often only capture the effective image area, discarding crucial VESA timing parameters such as line and field synchronization and blanking period, which are essential for avionics systems, resulting in an inability to fully analyze the electrical characteristics of the signal. Furthermore, existing equipment lacks the ability to perform closed-loop automated comparison of protocol data, timing parameters, and image content, making it difficult to meet the high-safety-level airworthiness verification requirements.

[0003] Therefore, there is an urgent need for a testing method for the ARINC818 airborne display module to solve the problem that related technologies cannot achieve closed-loop verification of all parameters of the airborne display module. Summary of the Invention

[0004] This application provides a testing method, system, and medium for the ARINC818 airborne display module to solve the problem that related technologies cannot achieve closed-loop verification of all parameters of the airborne display module.

[0005] Firstly, this application provides a testing method for the ARINC818 airborne display module, the method comprising: Obtain test configuration information and image data to be sent. Test configuration information includes predefined video timing parameters and protocol field parameters. The video frame transmission timing is generated based on the video timing parameters, and the image data to be sent is encapsulated into a video excitation signal conforming to the ARINC818 protocol in combination with the protocol field parameters. The video excitation signal is then sent to the airborne display module under test. The video feedback signal from the airborne display module under test is collected, and the video feedback signal is parsed and data is extracted to obtain the actual protocol field information, actual video timing parameters and actual image data. The actual protocol field information, actual video timing parameters, and actual image data are compared with the test configuration information and the image data to be sent to verify the consistency of the airborne display module under test.

[0006] The ARINC818 airborne display module testing method of this application achieves precise low-level control of the test signal source by acquiring configuration information containing predefined video timing parameters and protocol field parameters, and generating video excitation signals accordingly. This overcomes the shortcomings of general signal sources, such as unadjustable timing and uncontrollable protocols, and can simulate various standard or non-standard test scenarios. By acquiring video feedback signals and extracting actual protocol fields, actual video timing parameters, and actual image data, it achieves full parameter capture of the output signal of the device under test, filling the blind spots of traditional acquisition methods that lose timing and protocol details. By comparing the actual extracted data with the configuration information and source data in multiple dimensions, it achieves automated consistency verification, which can quickly and accurately determine whether the airborne display module meets the design requirements in terms of image processing, timing control, and protocol interaction, significantly improving the test coverage and efficiency.

[0007] In one optional implementation, the video timing parameters are parameters conforming to the VESA timing standard, including at least one of line synchronization, field synchronization, line front shoulder, line back shoulder, field front shoulder, field back shoulder, and pixel clock frequency.

[0008] In one optional implementation, the protocol field parameters include frame header parameters and container header parameters; The image data to be transmitted is encapsulated into a video excitation signal conforming to the ARINC818 protocol, including: The target identifier, source identifier, sequence number, container count, and video frame rate information are filled into the frame header or container header, and the image data to be sent is filled into the data frame. The combination generates a video excitation signal that conforms to the ARINC818 protocol frame format.

[0009] In one optional implementation, video feedback signals from the airborne display module under test are acquired, including: Receive the DVI video signal output from the airborne display module under test, convert the TMDS differential signal in the DVI video signal into RGB format data, and parse out the horizontal and vertical sync signals and pixel clocks. And / or, receive the ARINC818 fiber optic signal output from the airborne display module under test, perform 8B / 10B decoding and word alignment processing on the fiber optic signal, and parse out the data frame and control characters.

[0010] In one optional implementation, after the steps of protocol parsing and data extraction of the video feedback signal, the method further includes: The actual protocol field information, actual video timing parameters, and actual image data are uploaded in the form of data blocks through direct memory access and high-speed serial bus interface. The data blocks contain data tags and data payloads. The data tags encapsulate the receiving timestamp, resolution information, and line and field synchronization information.

[0011] In one optional implementation, the actual protocol field information, actual video timing parameters, and actual image data are compared with the test configuration information and the image data to be sent, respectively, including: The actual image data is restored to bitmap format and compared with the image data to be sent at the pixel level to calculate the similarity. The values ​​of the actual video timing parameters are compared with the predefined video timing parameters in the test configuration information. The frame header fields in the actual protocol field information are compared with the predefined protocol field parameters in the test configuration information for consistency.

[0012] In one optional implementation, the step of obtaining test configuration information further includes configuring the ARINC818 link rate; the steps of generating a video excitation signal conforming to the ARINC818 protocol and acquiring a video feedback signal are all based on the link rate; wherein the link rate is selected from one of 1.0625Gbps, 2.125Gbps, 3.1875Gbps and 4.25Gbps.

[0013] In one optional implementation, acquiring video feedback signals from the airborne display module under test further includes: Set a specific field in the protocol field parameters as a trigger condition. The specific field includes the start-of-frame character, end-of-frame character, idle character, or frame header data. When the data in the video feedback signal meets the triggering conditions, the capture and parsing operation of the current data frame is triggered.

[0014] Secondly, this application provides an ARINC818 airborne display module testing system, which includes an ARINC818 data transmission module, a DVI video transmission module, an ARINC818 data receiving module, a DVI video receiving module, and a data comparison module. The ARINC818 data transmission module and DVI video transmission module are used to generate video excitation signals corresponding to the test configuration information and send them to the airborne display module under test through an external interface; the video excitation signals are sent as expected data to the data comparison module. The ARINC818 data receiving module and DVI video receiving module are used to acquire video feedback signals from the airborne display module under test through an external interface, and send the video feedback signals as measured data to the data comparison module. The data comparison module is connected to the ARINC818 data transmission module, the DVI video transmission module, the ARINC818 data receiving module, and the DVI video receiving module, respectively. It is used to receive expected data and measured data, and execute the ARINC818 airborne display module test method of the first aspect or any corresponding embodiment described above. By comparing the expected data and the measured data, the consistency of the airborne display module under test is verified.

[0015] Thirdly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute the ARINC818 airborne display module testing method of the first aspect or any corresponding embodiment described above. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this application; Figure 2 This is a schematic flowchart of the first method for testing the ARINC818 airborne display module according to an embodiment of this application; Figure 3 This is a second flowchart illustrating the ARINC818 airborne display module testing method according to an embodiment of this application; Figure 4 This is a schematic diagram of the system architecture of the ARINC818 airborne display module test system according to an embodiment of this application; Figure 5 This is a schematic diagram of the hardware composition of the ARINC818 airborne display module test system according to an embodiment of this application; Figure 6 This is a schematic diagram of the ARINC818 data receiving module according to an embodiment of this application; Figure 7 This is a schematic diagram of the overall logic architecture of the AINRC818 data receiving function according to an embodiment of this application; Figure 8 This is a schematic diagram of the FPGA block diagram of the user interface module according to an embodiment of this application; Figure 9 This is a schematic diagram of a DMA upload data format according to an embodiment of this application; Figure 10 This is a schematic diagram of the output data format according to an embodiment of this application; Figure 11 This is a schematic diagram of the FC IPcore design interface according to an embodiment of this application; Figure 12 This is a flowchart illustrating the DVI video transmission function module according to an embodiment of this application; Figure 13 This is a schematic diagram of the overall logic architecture of the DVI video data transmission function according to an embodiment of this application; Figure 14 This is a schematic diagram of the user interface module framework according to an embodiment of this application; Figure 15 This is a schematic diagram of a DMA-based data transmission format according to an embodiment of this application; Figure 16 This is a schematic diagram of the DVI transmitting module interface according to an embodiment of this application; Figure 17 This is a functional flowchart of the DVI video data receiving module according to an embodiment of this application; Figure 18 This is a schematic diagram of the overall logic framework of the DVI video data receiving function according to an embodiment of this application; Figure 19 This is a schematic diagram of another DMA upload data format according to an embodiment of this application; Figure 20 This is an interface diagram of a DVI receiving module according to an embodiment of this application; Figure 21 This is a functional flowchart of the ARINC818 data transmission module according to an embodiment of this application; Figure 22 This is a schematic diagram of the overall logic architecture of the ARINC818 data transmission function according to an embodiment of this application; Figure 23 This is a schematic diagram of another DMA-based data delivery format according to an embodiment of this application; Figure 24 This is a schematic diagram of the 818_IPcore module interface according to an embodiment of this application; Figure 25 This is a schematic diagram of the FC_IPcore module design according to an embodiment of this application; Figure 26 This is a schematic diagram of the software framework according to an embodiment of this application; Figure 27 This is a schematic diagram of the DVI video transmission interface according to an embodiment of this application; Figure 28 This is a schematic diagram of a drop-down selection according to an embodiment of this application; Figure 29This is a schematic diagram illustrating video resolution selection according to an embodiment of this application; Figure 30 This is a schematic diagram of the ARINC818 data transmission interface according to an embodiment of this application; Figure 31 This is a schematic diagram of the DVI video data receiving and setting interface according to an embodiment of this application; Figure 32 This is a schematic diagram of the ARINC818 data receiving and setting interface according to an embodiment of this application; Figure 33 This is a schematic diagram illustrating the comparison mode settings according to an embodiment of this application; Figure 34 This is a schematic diagram of the communication function interface design according to an embodiment of this application; Figure 35 This is a schematic diagram of the communication data interaction interface according to an embodiment of this application; Figure 36 This is a structural block diagram of the ARINC818 airborne display module testing device according to an embodiment of this application; Figure 37 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, 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.

[0019] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0020] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained.

[0021] ARINC 818 (Avionics Digital Video Bus): An avionics digital video bus, a high-bandwidth, low-latency digital video transmission protocol based on the Fibre Channel (FC) physical layer, widely used in avionics display systems.

[0022] DVI (Digital Visual Interface): A video display interface standard used to transmit uncompressed digital video data.

[0023] HDMI (High Definition Multimedia Interface): A fully digital video and audio transmission interface.

[0024] VESA (Video Electronics Standards Association): In this case, it specifically refers to the video timing standards developed by the association, including parameters such as horizontal synchronization, vertical synchronization, and blanking period (front shoulder / back shoulder).

[0025] FPGA (Field Programmable Gate Array): A semiconductor device that contains programmable logic components and interconnects, allowing it to be configured after manufacturing to implement specific hardware functions.

[0026] PCIE (PCI-Express): A high-speed serial computer expansion bus standard used to connect motherboards and external devices (such as graphics cards and capture cards).

[0027] DMA (Direct Memory Access): Direct memory access allows hardware subsystems to read and write system memory directly, independently of the central processing unit (CPU), for high-speed, large-scale data transfer.

[0028] RS-232: A serial communication interface standard commonly used for industrial equipment control and debugging.

[0029] VCM (Video Control Module): In this embodiment, it refers to the airborne display device or processing unit under test.

[0030] TMDS (Transition Minimized Differential Signaling): A high-speed differential signal transmission technology used in DVI and HDMI interfaces, characterized by minimizing the transmission of differential signals.

[0031] 8B / 10B: A line coding mechanism that maps 8-bit data to 10-bit symbols to maintain DC balance and clock recovery. It is the basis of the ARINC 818 physical layer.

[0032] CRC (Cyclic Redundancy Check): A verification method used to detect data transmission errors in a communication link.

[0033] SOF (Start of Frame) / EOF (End of Frame): Frame start symbol / frame end symbol, delimiters used in the ARINC 818 protocol to identify the boundaries of data frames.

[0034] IDLE: Idle character (or idle ordered set), a padding character transmitted between ARINC 818 frames to maintain link synchronization.

[0035] GTX: High-speed serial transceiver hard core inside Xilinx FPGA, used to implement high-speed data transmission and reception at the physical layer.

[0036] MMCM (Mixed-Mode Clock Manager): A module inside an FPGA used to generate, divide, and adjust clock signals.

[0037] DDR (Double Data Rate SDRAM): Double Data Rate Synchronous Dynamic Random Access Memory.

[0038] As one optional application scenario in the embodiments of this application, such as Figure 1 As shown, the terminal device 110 (such as a test host computer / high-performance processor) has an application 101 (ARINC818 test software) installed in it. The user 130 can interact with the application 101 through the terminal device 110 and / or the access device of the terminal device 110.

[0039] For example, application 101 could be an application specifically designed for testing and verifying airborne display modules. Figure 1 In the application scenario shown, if application 101 is running, terminal device 110 can display interface 102 for testing application 101. Interface 102 may include various functional pages provided by application 101, such as parameter configuration page (for setting ARINC818 rate, VESA timing parameters, etc.), excitation transmission control page (for selecting image data to be transmitted), data acquisition monitoring page (for displaying the acquired video feedback signal in real time), and data comparison analysis page (for displaying the comparison results between the actual protocol fields and the expected values).

[0040] In some embodiments, the terminal device 110 communicates with the underlying hardware acquisition / excitation module via a high-speed bus interface (such as a PCIe interface) to transmit and receive test signals from the airborne display module under test (DUT). Specifically, the terminal device 110 can be a high-performance desktop computer, an industrial control computer, or a portable test fixture, possessing sufficient data storage and processing capabilities to handle the real-time analysis of massive amounts of video data. In some embodiments, the terminal device 110 can also interact with the airborne display module under test via a serial port (RS-232) to achieve auxiliary control functions.

[0041] It should be noted that, Figure 1 This is merely an example of an application scenario and does not limit the scope of protection of this application.

[0042] The embodiments of this application will be described below with reference to the accompanying drawings. It should be understood that the pages shown in the drawings are merely examples, and various page designs are possible in practice. The various graphical elements in the interface (such as waveforms, parameter lists, and status indicators) can have different arrangements and different visual representations. One or more elements may be omitted or replaced, and one or more other elements may also exist; no limitations are made in this disclosure. Furthermore, the embodiments described below primarily pertain to terminal device 110. It should be understood that the actions described relative to terminal device 110 (such as acquiring configuration, generating timing sequences, and comparing data) can be jointly executed by the test application 101 on terminal device 110 in conjunction with its internally integrated programmable logic hardware (such as an FPGA module).

[0043] In related technologies, existing testing methods for verifying airborne display modules often focus on simple image display function checks, lacking mechanisms that can simultaneously and precisely control and verify both low-level video timing and high-level protocol details. Addressing the technical problems faced by users when performing in-depth consistency verification of airborne display modules, such as uncontrollable test parameters, limited verification dimensions, and the inability to form a closed loop, this disclosure provides a testing method for the ARINC818 airborne display module. This method achieves a comprehensive, accurate, and dynamically verifiable technical effect regarding the protocol processing capabilities, timing response characteristics, and image processing quality of the airborne display module.

[0044] According to an embodiment of this application, an embodiment of a testing method for the ARINC818 airborne display module is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0045] This embodiment provides a testing method for the ARINC818 airborne display module. Figure 2 This is a flowchart of the ARINC818 airborne display module testing method according to an embodiment of this application, as follows: Figure 2 As shown, the process includes the following steps: Step S201: Obtain test configuration information and image data to be sent. The test configuration information includes predefined video timing parameters and protocol field parameters.

[0046] Test configuration information refers to a set of parameters set to perform a specific test task, defining how the test system should generate signals and how the response of the device under test should be expected. For example, test configuration information can be a configuration file containing settings such as resolution, refresh rate, and link speed, or a set of user-input commands.

[0047] The image data to be sent refers to the original still images or dynamic video frames used as the test source, serving as a benchmark for the visual content. For example, it could be a bitmap file (.bmp) of a standard test chart (such as a color bar image or a grayscale image).

[0048] Video timing parameters are parameters that define the characteristics of a video signal in the time dimension and determine the precise rhythm of image scanning. Examples include the pulse width of the horizontal sync signal, the pulse width of the vertical sync signal, the duration of the horizontal / vertical blanking period, and the pixel clock frequency.

[0049] Protocol field parameters refer to specific bits or byte segments used in the ARINC818 communication protocol to control data transmission format and identify data attributes. Examples include the source ID, destination ID, sequence number, and container format definition in the frame header.

[0050] Acquisition refers to the process of reading the aforementioned information from storage media, receiving it from a user interface, or downloading it from an upper-level management system.

[0051] For example, before the test begins, the user selects a configuration file named "1080p_60Hz_Standard Test" on the test software interface and imports a "Checkerboard.bmp" image. In response to this operation, the test system reads the VESA standard timing parameters (as video timing parameters) corresponding to a resolution of 1920x1080 and a refresh rate of 60Hz, as well as the standard frame header format specified by the ARINC818 protocol (as protocol field parameters) into memory. Simultaneously, it loads the bitmap data (as image data to be transmitted) to prepare for subsequent signal generation.

[0052] Step S202: Generate video frame transmission timing based on video timing parameters, and encapsulate the image data to be sent into a video excitation signal conforming to the ARINC818 protocol in combination with protocol field parameters, and send the video excitation signal to the airborne display module under test.

[0053] Video frame transmission timing refers to a time reference signal constructed based on timing parameters to control the start and end times of transmission for each frame of image and the horizontal and vertical scanning intervals. For example, it determines when to send the first line of pixels and how many clock cycles to wait between two lines of pixels.

[0054] Video excitation signals refer to the physical signals generated and output by the test system to the device under test. They not only contain image content but also strictly adhere to specific timing and protocol specifications. For example, it is a high-speed serial data stream transmitted through optical fiber.

[0055] The airborne display module under test (DUT) refers to the avionics equipment to be verified. For example, it could be the cockpit display unit (CDU) or video processing computer of an aircraft.

[0056] Generation refers to the process of constructing basic timing logic based on parameters; encapsulation refers to the process of packaging payload data into frames according to protocol rules; transmission refers to the process of converting digital signals into physical signals and transmitting them.

[0057] For example, the logic unit inside the test system first establishes a precise timeline (generating video frame transmission timing) based on video timing parameters such as the line synchronization pulse width (e.g., 44 clock cycles) and the back shoulder (e.g., 148 clock cycles) obtained in step S201. Then, the pixel data of "checkerboard.bmp" is filled into the data payload area of ​​the ARINC818, and the source ID and sequence number set in step S101 are added to the header of each frame. Finally, this data is encoded into a high-speed optical signal (video excitation signal) and transmitted via fiber optic cable to the aircraft display screen connected to the test bench (sent to the airborne display module under test).

[0058] Step S203: Collect video feedback signals from the airborne display module under test, perform protocol parsing and data extraction on the video feedback signals to obtain actual protocol field information, actual video timing parameters and actual image data.

[0059] The video feedback signal refers to the video signal output by the airborne display module under test after receiving the excitation signal and undergoing internal processing (such as conversion, rendering, and driving). This can be the driving signal (such as a DVI signal) output by the module to the screen, or it can be the ARINC818 signal that it forwards or transmits back.

[0060] Actual protocol field information refers to the actual protocol header values ​​parsed from the feedback signals. Examples include the actual received frame sequence number or checksum (CRC).

[0061] Actual video timing parameters refer to the electrical timing characteristics of the feedback signal obtained through measurement. For example, the measured duration of the horizontal synchronization signal level.

[0062] Actual image data refers to the visualized pixel content reconstructed from the feedback signal. For example, the final frame output by the device under test.

[0063] Acquisition refers to the process of capturing physical signals; protocol parsing refers to the process of interpreting the data stream structure according to the protocol specification; data extraction refers to the process of separating the key information of interest from the data stream.

[0064] For example, the test system's acquisition port receives the signal output by the module under test (acquiring the video feedback signal). First, the frame boundaries of the signal are identified, and the serial data stream is restored to parallel data (protocol parsing). Next, using an internal high-precision counter, the number of clock cycles occupied by the horizontal synchronization pulse of the signal is measured (obtaining the actual video timing parameters); simultaneously, the control bits in the data packet header are read (obtaining the actual protocol field information); finally, the pixel data of the payload area is saved to form a screenshot (obtaining the actual image data).

[0065] Step S204: The actual protocol field information, actual video timing parameters, and actual image data are compared with the test configuration information and the image data to be sent, respectively, to verify the consistency of the airborne display module under test.

[0066] Comparison refers to the operation of comparing and analyzing measured values ​​with theoretical values ​​(or expected values).

[0067] Consistency refers to whether the actual output of the device under test completely matches the design expectation, including functional correctness and parameter accuracy.

[0068] For example, the test system performs comparisons across the following three dimensions: Protocol comparison: Compare the "actual protocol field information" (such as CRC checksum) extracted from S203 with the "protocol field parameters" (expected checksum) from S101. If they match, it indicates that the protocol encapsulation function of the module under test is normal.

[0069] Timing Comparison: Subtract the "actual video timing parameters" measured in S203 (e.g., the measured horizontal synchronization width is 44 clock cycles) from the "video timing parameters" in S201 (the preset value is 44 clock cycles). If the difference is zero or within the allowable error range, it indicates that the timing control of the module under test is accurate.

[0070] Image comparison: The "actual image data" (screenshot) restored in S203 is compared with the "image data to be sent" (original image) in S201 at the pixel level for similarity calculation. If the similarity reaches 100%, it means that the image transmission is distortion-free. Based on the above three comparison results, the final determination is made as to whether the tested airborne display module has consistency, thus completing the verification process.

[0071] In summary, the ARINC818 airborne display module testing method of this embodiment achieves precise low-level control of the test signal source by acquiring configuration information containing predefined video timing parameters and protocol field parameters, and generating video excitation signals accordingly. This overcomes the shortcomings of general signal sources, such as unadjustable timing and uncontrollable protocols, and can simulate various standard or non-standard test scenarios. By acquiring video feedback signals and extracting actual protocol fields, actual video timing parameters, and actual image data, it achieves full parameter capture of the output signal of the device under test, filling the blind spots of traditional acquisition methods that lose timing and protocol details. By comparing the actual extracted data with the configuration information and source data in multiple dimensions, it achieves automated consistency verification, which can quickly and accurately determine whether the airborne display module meets the design requirements in terms of image processing, timing control, and protocol interaction, significantly improving the test coverage and efficiency.

[0072] This embodiment provides a testing method for the ARINC818 airborne display module. Figure 3 This is a flowchart of the ARINC818 airborne display module testing method according to an embodiment of this application, as follows: Figure 3 As shown, the process includes the following steps: Step S301: Obtain test configuration information and image data to be sent. The test configuration information includes predefined video timing parameters and protocol field parameters.

[0073] This step is the initialization phase of the test. It involves not only loading the images but also specifying the speed and frame size at which these images will be sent.

[0074] Test configuration information refers to the set of parameters set by the test system to simulate specific working environments or fault scenarios. This information first includes the ARINC818 link rate configuration, which defines the physical bandwidth for signal transmission, selected from 1.0625Gbps, 2.125Gbps, 3.1875Gbps, and 4.25Gbps. For example, for high-definition display testing, the user can select 4.25Gbps as the link rate.

[0075] Secondly, video timing parameters specifically refer to micro-time parameters conforming to VESA (Video Electronics Standards Association) standards, including at least horizontal synchronization (H-Sync), vertical synchronization (V-Sync), front porch, back porch, front porch, back porch, and pixel clock frequency. These parameters determine the precise rhythm of image scanning.

[0076] Step S302: Generate video frame transmission timing based on video timing parameters, and encapsulate the image data to be sent into a video excitation signal conforming to the ARINC818 protocol in combination with protocol field parameters, and send the video excitation signal to the airborne display module under test.

[0077] The core actions in this step are encapsulation and generation. This process involves the meticulous construction of the ARINC818 protocol frame structure. Protocol field parameters include frame header parameters and container header parameters. Specifically, key control information such as target identifier, source identifier, sequence number, container count, and video frame rate information are filled into the frame header or container header of the data packet. Subsequently, the image pixel data to be sent is filled into the payload area of ​​the data frame.

[0078] For example, based on the timing set in step S301, a precise horizontal and vertical scanning reference is established on the timeline. Simultaneously, a tag with "Source ID=0x01, Target ID=0x02" is added to the beginning of each frame of video data (i.e., frame header padding), and the color bar image data is placed in the payload area. Finally, these are combined to generate a fiber optic signal (video excitation signal) conforming to the ARINC818 protocol specification, which is then transmitted to the airborne display module under test via optical cable. This process ensures that the transmitted signal not only contains the image but also carries strictly defined identity information and timing.

[0079] Step S303: Collect video feedback signals from the airborne display module under test, perform protocol parsing and data extraction on the video feedback signals to obtain actual protocol field information, actual video timing parameters and actual image data.

[0080] This step is crucial for obtaining the response from the device under test. The acquisition process encompasses two different signal physical forms: For electrical interface signals: Receive the DVI video signal output by the module under test, convert the internal TMDS (Transmission Minimized Differential) into parallel RGB format data, and parse the field synchronization signal and pixel clock from the level transitions.

[0081] For optical interface signals: Receive the ARINC818 fiber optic signal output by the module under test, perform 8B / 10B decoding (a type of line encoding conversion) and word alignment processing on it, thereby parsing out the complete data frame structure and control characters.

[0082] To achieve precise capture, this step also introduces a triggering mechanism. Users can set specific fields in the protocol parameters (such as the Start of Frame (SOF), End of Frame (EOF), Idle Character (IDLE), or specific frame header data) as trigger conditions. Capture and parsing of the current frame is only triggered when data matching this condition is detected in the data stream. For example, setting the trigger to occur when the frame header source ID is ERROR will automatically lock onto and capture that abnormal frame from massive amounts of data.

[0083] After data extraction, the extracted actual protocol fields, timing parameters, and images are uploaded to the host computer in the form of data blocks via Direct Memory Access (DMA) and a high-speed serial bus interface (such as PCIe). Each data block contains a data tag and a data payload, where the tag encapsulates the reception timestamp, resolution information, and line and field synchronization information.

[0084] Step S304: Compare the actual protocol field information, actual video timing parameters, and actual image data with the test configuration information and the image data to be sent, respectively, to verify the consistency of the airborne display module under test.

[0085] This step verifies product quality through multi-dimensional comparisons. The comparison process is specifically divided into three levels: Step S3041, Image consistency comparison.

[0086] The uploaded actual image data is restored to bitmap format and compared pixel-by-pixel with the image data to be sent (source image) to calculate similarity. For example, if the tested module causes a dead pixel on the screen, the similarity will no longer be 100%.

[0087] Step S3042: Timing value comparison.

[0088] The system will subtract the actual video timing parameters (such as the measured line sync width) from the predefined values ​​in the test configuration information or determine their range. For example, if the preset line sync width is 44 and the measured width is 43, the system will mark the timing as drifted.

[0089] Step S3043: Protocol field consistency comparison.

[0090] The frame header fields (such as CRC check bits and sequence numbers) in the actual protocol field information are compared with the predefined protocol field parameters for consistency. For example, the sequence numbers of received frames are checked to verify whether there is any frame loss.

[0091] In summary, the ARINC818 airborne display module testing method provided in this embodiment utilizes configurable VESA parameters and protocol fields to generate stimuli, combines low-level decoding and trigger capture of optical / electrical signals, and sends the actual signal containing rich metadata to the host computer for multi-dimensional automated comparison via high-speed DMA transmission. This organic combination of various technical features not only breaks through the limitations of traditional black-box testing equipment, achieving full-stack perspective and verification of the airborne display module from physical layer timing to link layer protocol to application layer image, but also significantly reduces the complexity and error rate of manual testing.

[0092] This embodiment also provides an ARINC818 airborne display module testing system, which includes an ARINC818 data transmission module, a DVI video transmission module, an ARINC818 data receiving module, a DVI video receiving module, and a data comparison module; The ARINC818 data transmission module and DVI video transmission module are used to generate video excitation signals corresponding to the test configuration information and send them to the airborne display module under test through an external interface; the video excitation signals are sent as expected data to the data comparison module. The ARINC818 data receiving module and DVI video receiving module are used to acquire video feedback signals from the airborne display module under test through an external interface, and send the video feedback signals as measured data to the data comparison module. The data comparison module is connected to the ARINC818 data transmission module, the DVI video transmission module, the ARINC818 data receiving module, and the DVI video receiving module, respectively. It is used to receive expected data and measured data, and execute the ARINC818 airborne display module test method described in the above embodiment. By comparing the expected data and the measured data, the consistency of the airborne display module under test is verified.

[0093] To better illustrate the ARINC818 airborne display module testing system of the embodiments, a preferred embodiment will be provided below. This embodiment is intended to describe the implementation process of this disclosure in detail, but is not intended to limit the scope of protection of this disclosure.

[0094] This embodiment provides an ARINC818 airborne display module testing system. This system integrates data transmission, reception, and comparison functions, enabling fully closed-loop automated testing of airborne display modules.

[0095] Figure 4 The system architecture diagram for the ARINC818 airborne display module test system is as follows: Figure 4 As shown, this system mainly consists of a high-performance processor (Host) and an embedded FPGA functional module.

[0096] High-performance processor: As the main control unit, it is equipped with a processor, hard disk (for storing .bmp / .dat files), and interfaces such as RS232, USB, and network port.

[0097] Hardware modules include an ARINC 818 data transmission module, an ARINC 818 data reception module, a DVI video transmission module, and a DVI video reception module. These modules connect to the processor via a PCIe interface to enable control command issuance and DMA data exchange.

[0098] This system connects to the airborne display module (DUT) under test via a dedicated test cable (fiber optic or DVI copper cable) to form a test closed loop.

[0099] This system primarily connects to the device under test (DUT) via test cables to receive and transmit data, enabling the debugging and testing of the DUT. The ARINC818 data receiving module, ARINC818 data transmitting module, DVI video receiving module, and DVI video transmitting module are housed in a high-performance processor and connected via a PCIe interface. This allows for data reception and transmission, as well as software operation. The software allows for the configuration of various module functions and the setting of transmission parameters. The high-performance processor also features an RS-232 interface for communication with the DUT.

[0100] The ARINC818 video bus test and verification device software can achieve the following: Supports ARINC818 link rates of 1.0625 / 2.125 / 3.1875 / 4.25Gbps; Supports custom resolution video configuration and generation; Supports continuous capture, analysis, and result comparison of 2 channels of ARINC818 data; Supports continuous transmission of 2 ARINC818 data streams; Supports continuous capture, analysis, and result comparison of 2-channel DVI data; Supports continuous transmission of 2-channel DVI data; Supports one RS-232 communication channel.

[0101] Hardware composition diagram as follows Figure 5 As shown, the high-performance processor is housed in a rack and contains four modules that interact with the software via a PCIe interface. These modules, in conjunction with the software, enable the functions of the ARINC818 data receiving module, ARINC818 data sending module, DVI video data receiving module, and DVI video data sending module.

[0102] High-performance processors are high-performance computers or servers with hard disk space and processors, and have more than four PCIe interfaces.

[0103] Figure 6 Here is the flowchart for the ARINC818 data receiving module, as follows: Figure 6 As shown, the ARINC818 data receiving module has two ARINC818 acquisition ports, enabling dual-channel ARINC818 video reception. Through software configuration of the optical port reception rate, operating on the GT core, it can achieve different optical port link rates of 1.0625Gbps, 2.125Gbps, 3.1875Gbps, and 4.25Gbps. It parses the received ARINC818 data and sends the ARINC818 data and information to the software via the PCIe interface. With the software, it can display the received ARINC818 data in its complete format and store it as .bmp images and .dat files. It supports multiple resolutions, including at least 1920x1080@60hz, 1680x1050@60hz, 1400x1050@60hz, 1280x1024@60hz, 1024x768@60hz, and 800x600@60hz.

[0104] The hardware functionality of the AINRC818 data receiving module is implemented through FPGA chip logic design. The overall logic architecture diagram of the AINRC818 data receiving function is shown below. Figure 7 As shown: The main functions of each module in the AINRC818 data receiving function logic design are as follows: (1) PCIe interface module: for data transmission between software and FPGA; (2) User interface module: Configures the optical port receiving rate and time, and receives data and information from the AINRC818; (3) Time Management Module: Statistically tracks the time of data reception; (4) DDR management module: caches data; (5) Channel Management Module: Schedules two input data streams; (6) Data Management Module: Parses AINRC818 data frames and counts the number of IDLEs; (7) FC_IPcore module: Implements the configuration of optical port rate.

[0105] The design of each module of the AINRC818 data receiving function logic is as follows: The PCIe interface module uses the FPGA's IPCore xdma and pcie_dma_bridge to read and write registers and receive data frames from the user end.

[0106] The FPGA block diagram of the user interface module is as follows: Figure 8 As shown, the user interface module receives configuration information from the host via register write through the PCIe interface module, forwards it to the corresponding functional modules, and simultaneously reports the status and MIB information of each module to the host via PCIe register read. It also completes DMA data transfer between the PCIe interface module and the DDR management module.

[0107] The configuration management module configures internal control parameters through the PCIe interface module. The main configurations include module reset, fiber optic rate, time, DDR management module data upload time threshold, and storage block number threshold.

[0108] The status management module reads the internal status parameters of the logic through the PCIE interface module. The main parameters include FPGA version information, FPGA loading success status, current optical port rate, total number of data frames received by AINRC818, and total number of bytes of data frames received by AINRC818.

[0109] The DMA processing module implements the transfer of DMA data from internal logic to software. PCIe DMA upload format is block-based. When the time threshold or block threshold configured for DDR by the high-performance processor is reached, the logic generates an interrupt. The CPU reads how many blocks of data are stored in DDR, then initiates a DMA transfer command. Simultaneously, it continues to respond to the DMA transfer ready signal before starting the actual data transfer. The data format within a block consists of a tag and a data frame. The AINRC818 data frame includes sof, frame header, date field header, eof, etc. The DMA upload data format is as follows: Figure 9 As shown.

[0110] The time management module calculates the system time based on the initial time configured in the software and the clock frequency, thereby enabling the statistics of data frame reception time.

[0111] The main function of the DDR management module is to receive data from the data management module, store the data, read it out, send the data to the user interface module, and then send the data to the software through the PCIe interface.

[0112] The channel management module mainly includes two sub-modules: the bit width conversion module and the data scheduling module.

[0113] The bit-width conversion module uses a FIFO buffer and a state machine to combine 32-bit data from every four clock cycles into 128-bit data and store it in the FIFO, thereby converting the output 32-bit data into 128-bit data for output.

[0114] The data scheduling module mainly implements the two-way scheduling function, which uses a state machine to control two inputs to achieve one output.

[0115] The data management module is divided into two sub-modules: the data frame processing module and the tag header processing module. It mainly implements the processing of data frames and the filling of tag headers.

[0116] The data frame processing module handles oversized and erroneous frames in the received data frames. It identifies data frames based on their sof (Software Override) and evoked override (EOF) values. If a data frame lacks a sof, it discards it. If a sof exists but an EOF is missing, it waits for the EOF of the next data frame, or uploads an erroneous data packet when the data frame length reaches the maximum byte count (2112 bytes). The module counts the number of idle frames between processed data frames and between images, and outputs the idle frame count and frame length to the tag header processing module.

[0117] Tag header processing module: This module pads the tag header of the data frame. It adds the data frame length, number of invalid bytes (padding is required if the end of a frame is less than 128 bits), channel identifier, CRC identifier, number of IDLEs, and input time to the tag header. The data is then output to the data receiving module in a format of one tag header + one data frame. The output data format is as follows: Figure 10 As shown.

[0118] The FC_IPcore module uses the GTX architecture to implement the IP core, mainly to convert the fiber data received by the optical module into 32-bit data frames for output, as well as to configure the optical port link rate.

[0119] FC IPcore design interface such as Figure 11 As shown, the FC IPcore design includes two sub-modules, FC_RX and GTX_TOP, which respectively implement the following functions: The FC_RX function sends all received data to the upstream module.

[0120] GTX_TOP implements word alignment, 8B / 10B encoding / decoding, link activation, and configurable speeds of 1.0625Gbps, 2.125Gbps, 3.1875Gbps, and 4.25Gbps.

[0121] Two FC_IPcore modules, along with two optical ports, are used to achieve independent reception of two ARINC818 channels.

[0122] Figure 12This is a flowchart of the DVI video transmission module. The DVI video data transmission module has two HDMI interfaces and provides an HDMI-to-DVI straight-through cable, enabling independent transmission of two DVI video streams. Data and configuration information are sent to the FPGA via the PCIe interface. The FPGA, in conjunction with software, can configurably load local images and DVI video feature values. It supports multiple resolutions, including at least 1920x1080@60Hz, 1680x1050@60Hz, 1400x1050@60Hz, 1280x1024@60Hz, 1024x768@60Hz, and 800x600@60Hz.

[0123] The hardware functionality of the DVI video data transmission module is implemented through FPGA chip logic design. The overall logic architecture diagram of the DVI video data transmission function is shown below. Figure 13 As shown.

[0124] The main functions of each module in the DVI video data transmission function logic design are as follows: (1) PCIe interface module: for data transmission between software and FPGA; (2) User interface module: Configure line and field synchronization information, pixel clock, polarity, and send image data and information; (3) Clock management module: Enables configurable pixel clock; (4) DDR management module: caches data; (5) Row splitting module: Splits image data by row; (6) DVI Transmission Module: Based on the configured line and field synchronization information, the image data is reassembled and output according to the timing standard; (7) rgb2dvi module: converts rgb format data into TMDS differential signal.

[0125] The design of each module in the DVI video data transmission function logic design is as follows: The PCIe interface module receives .bmp format images sent by software via the PCIe interface. This module is implemented using the FPGA's IPCore xdma. This module handles register read / write operations and DMA data transmission to the user terminal.

[0126] Figure 14 For the user interface module framework diagram, such as Figure 14 As shown, the user interface module receives configuration information from the host via register write through the PCIe interface module, enabling the configuration of DVI video parameters. Simultaneously, it reports the status of each module and MIB information to the host via PCIe register read. It also receives DMA data from the PCIe interface module, completing DMA image data transfer between the PCIe interface module and the DDR management module.

[0127] The configuration management module configures the internal control parameters of the logic through the PCIe interface module. The main configurations include module reset, image line and field synchronization headers, front and rear shoulders, pixel clock, and polarity.

[0128] The status management module reads the internal status parameters of the logic through the PCIe interface module. The main parameters include: FPGA version information, FPGA loading success status, number of images sent, and number of images sent via PCIe.

[0129] The DMA processing module sends image data and information to the FPGA chip via DMA.

[0130] PCIe's DMA (Direct Memory Access) delivery format is data tag + image payload. The data tag contains image information such as refresh rate, resolution, and image size. DMA data delivery requires splitting each image into its own payload within this module. The DMA delivery data format is as follows: Figure 15 As shown.

[0131] The clock management module receives the pixel clock configuration from the user interface module and applies it to the MMCM clock manager to enable the pixel clock to be configured.

[0132] The main function of the DDR management module is to receive DMA data from the software, cache the data in the DDR, and then read the data stored in the DDR according to the signals from the downstream modules and send it to the row splitting module for processing.

[0133] The row splitting module reads data from the DDR3 storage management module, which stores data in a tag + image data format. The DVI transmission module, however, requires data input row by row; therefore, row splitting is implemented within this module. The row splitting module primarily performs the following functions: converting 128-bit input to 24-bit output, and splitting an image into row-by-row outputs based on resolution information.

[0134] Figure 16 Send the DVI module interface diagram, such as Figure 16 As shown, the DVI transmitting module receives image data and information from the line splitting module. It performs cross-clock domain conversion and outputs image data, enable, line and field synchronization, and pixel clock. This module contains two sub-modules: a DVI data buffer module and a DVI data transmitting module.

[0135] The data first enters the DVI data buffer module, where its main function is to buffer the received data across clock domains. This module only begins sending data once a full line of data has been buffered, and it only starts receiving buffered data when the data marks the beginning of an image. The data is then output to the DVI data sending module.

[0136] The DVI data transmission module receives data from the DVI data buffer module. Based on the received resolution and refresh rate information, and the horizontal and vertical sync headers and front and back shoulder information configured by the user interface module through registers, the image data is reassembled and output according to the timing standard. The polarity settings for VSYNC and HSVYNC are configured to be active low or active high.

[0137] The rgb2dvi module receives 24-bit RGB video data and pixel clock signals from the DVI transmitter module and converts them into TMDS differential signals for output.

[0138] Figure 17 Here is a flowchart of the DVI video data receiving module's functions, such as... Figure 17 As shown, the DVI video data receiving module has an HDMI interface. When paired with an HDMI to DVI straight-through cable, it can receive one DVI video stream. The module parses the received DVI video data and sends the DVI video data and information to the software via the PCIe interface. With the software, the received DVI video data frames can be displayed in real time and stored as .bmp images and .dat files. It supports multiple resolutions, including at least 1920x1080@60hz, 1680x1050@60hz, 1400x1050@60hz, 1280x1024@60hz, 1024x768@60hz, and 800x600@60hz.

[0139] The hardware functionality of the video data receiving module is implemented through FPGA chip logic design. The overall logic framework diagram for the DVI video data receiving function is shown below. Figure 18 As shown: The main functions of each module in the DVI video data receiving function logic design are as follows: (1) PCIe interface module: for data transmission between software and FPGA; (2) User interface module: Configure time, receive image data and information; (3) Time Management Module: This module tracks the time it takes to receive images. (4) DDR management module: caches data; (5) Data Management Module: Adds line and field synchronization information, time, etc. to the image data header; (6) DVI receiving module: parses the line and field synchronization information of the image; (7) dvi2rgb module: converts TMDS differential signals into rgb format data.

[0140] The logic design of each module for the DVI video data receiving function is as follows: The PCIe interface module transmits received image information to the high-performance processor via the PCIe interface. This module is implemented using the FPGA's IPCore xdma. It handles DMA data reception from the user interface module and read / write operations to the user's registers.

[0141] The user management module receives configuration information from the host via register write through the PCIe interface module, forwards it to the corresponding functional modules, and simultaneously reports the status and MIB information of each module to the host via PCIe register read. It also completes DMA data transfer between the PCIe interface module and the DDR management module.

[0142] The configuration management module configures internal control parameters through the PCIe interface module. The main configurations include module reset, time, DDR management module data upload time threshold, and storage block number threshold.

[0143] The status management module reads the internal status parameters of the logic through the PCIe interface module. The main parameters include: FPGA version information, FPGA loading success status, and total number of received images.

[0144] The DMA receive management module is responsible for transferring DMA data from internal logic to software.

[0145] PCIe's DMA upload format is block-based. When the time or block threshold configured for DDR by the high-performance processor is reached, an interrupt is generated. The CPU reads how many blocks of data are stored in DDR, then initiates a DMA transfer command. Simultaneously, it continues to respond to the DMA transfer ready signal before actually transferring data. The data format within a block is data tag + data payload. The received data tag contains information such as the received system time, resolution, refresh rate, and image line and field synchronization information. The DMA upload data format is as follows: Figure 19 As shown.

[0146] The time management module calculates the system time based on the initial time configured in the software and the clock frequency, thereby enabling the statistics of image reception time.

[0147] The main function of the DDR management module is to receive data from the data management module, store the data, read it out, send the DMA data to the user interface module, and then send the data to the software through the PCIe interface.

[0148] The data management module receives the input image data, image information, and time. Its main functions include: Bit width conversion: The DVI receiving module inputs 24 bits, while the DDR storage module inputs 128 bits. Therefore, this module also needs to implement the bit width conversion function from 24 bits to 128 bits. Add tag header: Receive data output from the DVI receiver module, convert the image line and field synchronization information and time semaphore into tags, and add them to the header of a line when outputting data.

[0149] Supplementing invalid bytes: The input data timing is that the data between sof and eof is the data of one graph, not the data of one row when input. Therefore, when the input graph end signal is detected, the current data may not be enough to be converted into a complete 128-bit output. Therefore, several 24-bit invalid bytes need to be supplemented at this time. Finally, a complete 128-bit output with invalid data is output, which corresponds to the data eof signal and the graph eof signal.

[0150] The interface diagram of the DVI receiver module is as follows: Figure 20 As shown, the DVI receiving module parses the received RGB image data based on the horizontal and vertical synchronization information. It outputs information such as the image refresh rate, resolution, number of images, horizontal and vertical synchronization, and front / back shoulder values ​​as semaphores. This data is then stored in an asynchronous FIFO, completing the cross-clock domain conversion, and finally outputting the data frame information to the data management module.

[0151] The dvi2rgb module receives the clock and data from the TMDS input via the HDMI port, decodes it, and outputs 24-bit video data, horizontal and vertical sync, and pixel clock. This video data is then sent to the DVI receiver module.

[0152] Figure 21 This is a functional flowchart of the ARINC818 data transmission module. The ARINC818 data transmission module has two ARINC818 acquisition ports, enabling independent video transmission from a single ARINC818 channel. The optical port transmission rate can be configured via software, operating on the GT core, achieving different optical port link rates of 1.0625Gbps, 2.125Gbps, 3.1875Gbps, and 4.25Gbps. The software sends data and configuration information to the FPGA via the PCIe interface. The FPGA, in conjunction with the software, can load local .bmp images and support ARINC818 data configuration. It supports multiple resolutions, including at least 1920x1080@60hz, 1680x1050@60hz, 1400x1050@60hz, 1280x1024@60hz, 1024x768@60hz, and 800x600@60hz.

[0153] The hardware functionality of the AINRC818 data transmission module is implemented through FPGA chip logic design. The overall logic architecture diagram of the AINRC818 data transmission module is shown below. Figure 22 As shown: The main functions of each module in the AINRC818 data transmission function logic design are as follows: (1) PCIe interface module: for data transmission between software and FPGA; (2) User interface module: Configures the optical port transmission rate and transmits ARINC818 data frames and parameters; (3) Clock management module: generates the clock required by the internal logic modules; (4) DDR management module: caches data; (5) Data processing module: Parses the parameter information of the data frame header in the tag header; (6) 818_IPcore module: fills the parsed parameter information into the ARINC818 data frame header; (7) FC_IPcore module: Implements the configuration of optical port rate.

[0154] The design of each module of the AINRC818 data transmission function logic is as follows: The PCIe interface module provides a PCIe interface to transmit received image information to the high-performance processor. This module is implemented using the FPGA's IPCore xdma. It handles the transmission of DMA data and the reading and writing of the interface module registers.

[0155] The user interface management module receives configuration information from the host via register write through the PCIe interface module, forwards it to the corresponding functional modules, and simultaneously reports the status and MIB information of each module to the host via PCIe register read. It also receives DMA data from PCIe, breaks it down into individual images, and sends them to the DDR3 memory management transceiver module.

[0156] The configuration management module configures internal control parameters through the PCIe interface module. The main configurations include module reset, fiber optic speed, and refresh rate.

[0157] The status management module reads the internal status parameters of the logic through the PCIe interface module. The main parameters include: FPGA version information, FPGA loading success status, current optical port rate, current refresh rate of ARINC818, and ARINC818 image transmission statistics.

[0158] The DMA receive and processing module is mainly software that sends data frames and parameter information to the FPGA via DMA.

[0159] The PCIe DMA send format is data tag + data. The data tag stores the frame header information from the ARINC 818 data frame, including refresh rate, resolution, etc. DMA data sending requires splitting each image into its own send block within this module. The DMA send data format is as follows: Figure 23 As shown.

[0160] The clock management module generates the clocks required by all modules based on externally input clocks and resets all modules based on external resets. This includes the PCIe clock domain, FC clock domain, system clock domain, DDR3 clock domain, and IRIGB clock domain, each with its corresponding reset mechanism.

[0161] The DDR management module receives DMA data input from the user interface module, stores the data in DDR, and then reads the data out based on signals received by subsequent modules.

[0162] The data processing module receives data read from the DDR, parses the parameters from the data fields in the tag header, and transmits them to the 818-IPCore module in the form of semaphores. This module then performs bit-width conversion, converting 128 bits to 32 bits and outputting the data to the 818-IPCore module. This module controls the video transmission rate and other parameters based on the configured refresh rate and data frame interval information.

[0163] Figure 24 The interface diagram for the 818_IPcore module is as follows: Figure 24 As shown, the 818_IPcore module implements the 818 packet sending and assembly function. It receives data frames and image information from the line splitting module, and fills the container header and data frame with parameters from the tag header, such as Desination ID, SEQ_ID, Source ID, Container Count, Video Frame Rate, Transmission Rate, Object2Size, Video Resolution, Color Information, ancillary date2, and ancillary date3 (the Container Count is automatically incremented; if the initial value changes, it can continue to be incremented based on the initial value), forming a frame format conforming to the 818 protocol for transmission. The output is then sent to the FC_IPcore module.

[0164] Figure 25 Design the FC_IPcore module diagram, such as Figure 25 As shown, the FC_IPcore module mainly converts 32-bit parallel signals into serial signals for underlying fiber optic transmission and enables optical port rate configuration.

[0165] The FC IPcore consists of two sub-modules, FC_TX and GTX_TOP, which implement the following functions respectively: FC_TX receives upstream data in the link active state and sends the data with a CRC check value to the GTX_top module, with at least 6 IDLEs between two complete frames.

[0166] GTX_TOP enables word alignment, 8B / 10B encoding / decoding, link activation, and configurable optical port rates of 1.0625Gbps, 2.125Gbps, 3.1875Gbps, and 4.25Gbps.

[0167] Figure 26 For software framework diagrams, such as Figure 26 As shown, the software design specifically includes: the ARINC818 airborne display module test equipment sends DVI / HDMI video data and ARINC818 data, and receives DVI / HDMI video data and ARINC818 data. It has a data comparison function and can execute, debug, and store test cases for debugging and physical testing of the device under test.

[0168] DVI video data transmission module: The configuration parameters selected by the user are sent to the module, and the module sends out the data according to the configuration.

[0169] DVI video data receiving module: The module sends the acquired data to the software, which then parses the received data and displays it on the software interface.

[0170] ARINC818 data sending module: The configuration parameters selected by the user are sent to the module, and the module sends out the data according to the configuration.

[0171] ARINC818 Data Receiving Module: The module sends the collected data to the software, which then parses the received data and displays it on the software interface.

[0172] Data comparison function module: The software will save the received data as images. Users can select the saved images in the data comparison view and compare them with the images sent by the user. The images will then be displayed in the image comparison area.

[0173] RS-232 communication module functions: By controlling the built-in serial port module on the machine, configuration is sent to the serial port, user input data is sent to the serial port module, and the data collected by the serial port module is displayed on the software interface.

[0174] The DVI video data transmission module functions as follows: The ARINC818 data bus test and verification device supports DVI / HDMI video data transmission. The transmission parameters need to be configured first. After clicking the "Start Sending" button, the software sends the user-selected configuration to the module. The software loads the image from the selected path and converts the image to a format supported by the module, also sending the converted image to the module. When DVI video transmission is selected, the DVI video transmission interface looks like this. Figure 27 As shown.

[0175] The interface consists of three parts: a hardware resource tree, playback image resources, and a sending settings interface. The sending settings interface supports the following attribute settings: Supports independent transmission of video data from two DVI channels. Select either DVI-1 or DVI-2 via a dropdown menu. Figure 28 As shown.

[0176] Supports configuration of feature values ​​for each DVI video channel. Resolution can be selected via a dropdown menu, and refresh rate can be entered in the input box. Figure 29 As shown, the video resolution must meet at least 1680x1050@60hz, 1400x1050@60hz, 1280x1024@60hz, or 1024x768@60hz.

[0177] The system provides configurable VS (vertical synchronization) start and end times, HS (horizontal synchronization) start and end times, and pixel clock. The system will provide default data. If you need to modify them, you can modify the corresponding parameters in the input box. The configurable parameters are as follows: 1680x1050@60hz: The sum of the row synchronization header, the number of valid points in the row, and the total number of rows before and after the header equals 1840; the sum of the column synchronization header, the number of valid points in the column, and the total number of columns before and after the header equals 1080. 1400x1050@60hz: The sum of the row synchronization header, the number of valid points in the row, and the total number of rows before and after the header equals 1864; the sum of the column synchronization header, the number of valid points in the column, and the total number of columns before and after the header equals 1089. 1280x1024@60hz: The sum of the row synchronization header, the number of valid points in the row, and the total number of rows before and after the header equals 1688; the sum of the column synchronization header, the number of valid points in the column, and the total number of columns before and after the header equals 1066. 1024x768@60hz: Row synchronization header, row valid points, and row front and back shoulders total 1344; Column synchronization header, column valid points, and column front and back shoulders total 806.

[0178] It supports loading local .bmp format images and can send them in DVI video data format.

[0179] The ARINC818 data transmission module allows the software to view the real-time video source, enabling users to intuitively monitor and adjust the test feed to better adapt to different testing needs. Users can adjust the transmitted test feed in real time, including resolution, refresh rate, and speed, ensuring flexibility and adaptability in the testing environment.

[0180] The ARINC818 data bus test and verification device supports ARINC818 data transmission. First, the transmission parameters need to be configured. Clicking the "Start Transmission" button sends the user-selected configuration to the module. The software loads the image from the selected path, converts the image to a format supported by the module, and then sends it to the module. When the ARINC818 data transmission view is selected, the ARINC818 data transmission interface looks like this. Figure 30 As shown.

[0181] The interface consists of three parts: the hardware resource tree, the image resources to be played, and the sending settings interface. The sending settings interface supports the following attribute settings: Supports one-channel ARINC818 video data transmission; It supports configurable ARINC818 data transmission rate, allowing users to select different transmission rates via a drop-down menu, supporting link rates of 1.0625Gbps, 2.125 Gbps, 3.1875Gbps, and 4.25Gbps. It supports ARINC818 data format configuration, allowing modification of parameters such as Frame Header and Data Field Header. It supports selecting .bmp format images with user-specified resolutions and sending them as ARINC818 video data; it supports configuring both RGB and grayscale modes; and the video resolution must meet at least 1680x1050@60hz, 1400x1050@60hz, 1280x1024@60hz, and 1024x768@60hz.

[0182] The ARINC818 airborne display module test equipment supports DVI video data reception. The software interface is divided into three parts: a menu bar at the top, a video data display area on the left, and a video content display area on the right. The user selects the receiving channel and clicks the "Start Reception" button. The software then sends a start acquisition command to the module and begins parsing the acquired data according to the protocol, displaying it in real-time on the interface. When DVI video reception is selected, the DVI video data reception settings interface looks like this. Figure 31 As shown.

[0183] The interface consists of three parts: a hardware resource tree, playback image resources, and a receiver settings interface. It supports the following attribute settings: It supports receiving video data from one DVI port; it supports parsing and real-time display of the received DVI video data; and it can store the data as BMP images and DAT files.

[0184] The ARINC818 data receiving module supports ARINC818 data receiving functionality. The ARINC818 airborne display module test equipment has two sub-modules: a protocol analysis sub-module and a video analysis sub-module.

[0185] Protocol Analysis Module: The software sends user configurations to the module, and the software displays the data collected by the module in real time on the interface in the form of data frames.

[0186] Video analytics module: The software sends user configurations to the module, and the software displays the data collected by the module in real time as video on the interface.

[0187] When ARINC818 data reception is selected, the ARINC818 data reception settings interface is as follows: Figure 32 As shown.

[0188] The interface consists of three parts: a hardware resource tree, playback image resources, and a settings interface. It supports the following attribute settings: Supports dual-channel ARINC818 video data reception, with selectable channel 1 or channel 2; supports parsing and displaying received ARINC818 data in ARINC818 format, and supports conversion between BMP images and DAT files; also supports storing the above data as BMP images and DAT files. The number of data items and IDLEs stored in the DAT file is distinguished by the filename. Configurable ARINC818 data reception rates are supported, including link rates of 1.0625 Gbps, 2.125 Gbps, 3.1875 Gbps, and 4.25 Gbps. Configurable ARINC818 received data formats are supported, including SOFi, SOFn, FrameHeader, Container Header, Obj0 Ancillary Data, CRC, EOFn, EOFt, and IDEL. These parameters can be used as trigger conditions in data frame monitoring.

[0189] The ARINC818 data bus test and verification device supports a data comparison module. The software saves received data as images, which users can compare with user-specified transmitted images in the data comparison view. The comparison is then displayed in the image comparison area. The interface design includes four parts: the first area on the left is the transmitted data display area; the second area on the left is the received data display area; the second area on the right displays the comparison results (the left side shows the transmitted results, the middle shows the received results, and the right side shows the comparison of transmitted and received data; double-clicking the results displays the comparison effect); and the first area on the right is for setting data comparison attributes, as follows: It supports comparing the sent DVI video with the received ARINC818 data (Data Payload) converted from VCM, and provides the comparison results.

[0190] It supports comparing the received ARINC818 other data (SOFi, SOFn, Frame Header, Container Header, Obj0 AncillaryData, CRC, EOFn, EOFt, IDEL) with the expected result (content provided by the user). The receiving module converts the received data into image format and then displays the comparison result through the interface below. It supports comparing the sent ARINC818 data (Data Payload) with the DVI video data (valid data) converted from VCM, and provides the comparison results; It supports comparing DVI video data (VST, HST, HBP, VBP, HFP, VFP) converted from VCM with the expected result (content provided by the user). The receiving module converts the received data into image format and then displays the comparison result through the interface below.

[0191] The software sets the four comparison methods above into four comparison modes, such as... Figure 33 As shown, by selecting a comparison mode and the objects to be compared within the software, the comparison method will be selected based on the comparison mode. The third column displays the similarity results; clicking on the results allows for a visual display of the comparison findings.

[0192] The ARINC818 airborne display module test equipment supports RS-232 communication. By controlling the built-in serial port module, configuration settings are sent to the serial port, user input data is sent to the serial port module, and the data collected through the serial port module is displayed on the software interface. The functional interface design is as follows: Figure 34As shown in the image. It supports one RS-232 communication channel; the RS-232 communication baud rate is configurable, with a minimum support of 115200 baud rate; it also supports setting both receive and transmit parameters; and it supports receiving and displaying RS-232 communication data. After setting the communication baud rate and data length, commands are sent in the send box of the interactive interface to initiate communication. The communication data interaction interface is shown below. Figure 35 As shown, interactive information is displayed in the window above the send box.

[0193] In summary, this embodiment, through the adoption of an FPGA-based hardware and software architecture, enables arbitrary configuration and fault injection of ARINC818 protocol fields and VESA underlying video timing, effectively overcoming the shortcomings of existing graphics cards or converters with fixed and uncustomizable timing. Simultaneously, it possesses full-parameter acquisition and analysis capabilities and automated data closed-loop comparison functions, enabling precise quantitative analysis of image quality and timing data, thereby efficiently and accurately verifying the product's functionality, performance, and protocol consistency.

[0194] This embodiment also provides an ARINC818 airborne display module testing device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0195] This embodiment provides a testing device for the ARINC818 airborne display module, such as... Figure 36 As shown, it includes: The acquisition module 3601 is used to acquire test configuration information and image data to be sent. The test configuration information includes predefined video timing parameters and protocol field parameters. The generation module 3602 is used to generate video frame transmission timing according to the video timing parameters, and encapsulate the image data to be sent into a video excitation signal conforming to the ARINC818 protocol in combination with the protocol field parameters, and send the video excitation signal to the airborne display module under test. The parsing module 3603 is used to collect video feedback signals from the airborne display module under test, perform protocol parsing and data extraction on the video feedback signals, and obtain actual protocol field information, actual video timing parameters and actual image data. The verification module 3604 is used to compare the actual protocol field information, actual video timing parameters and actual image data with the test configuration information and the image data to be sent, respectively, to verify the consistency of the airborne display module under test.

[0196] The ARINC818 airborne display module testing device provided in this application can execute the ARINC818 airborne display module testing method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the above modules and units are the same as in the corresponding embodiments described above, and will not be repeated here.

[0197] Figure 37 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0198] The following is a detailed reference. Figure 37 The diagram illustrates a structural schematic suitable for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 3701, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 3702 or a program loaded from memory 3708 into random access memory (RAM) 3703. The RAM 3703 also stores various programs and data required for the operation of the electronic device. The processor 3701, ROM 3702, and RAM 3703 are interconnected via a bus 3704. An input / output (I / O) interface 3705 is also connected to the bus 3704.

[0199] Typically, the following devices can be connected to I / O interface 3705: input devices 3706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 3707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 3708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 3709. Communication device 3709 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 37 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0200] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 3709, or installed from memory 3708, or installed from ROM 3702. When the computer program is executed by processor 3701, it performs the functions defined in the ARINC818 airborne display module testing method of embodiments of this application.

[0201] Figure 37 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0202] This application also provides a computer-readable storage medium. The methods described above according to this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the ARINC818 airborne display module testing method shown in the above embodiments is implemented.

[0203] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0204] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A testing method for the ARINC818 airborne display module, characterized in that, The method includes: Obtain test configuration information and image data to be sent, wherein the test configuration information includes predefined video timing parameters and protocol field parameters; The video frame transmission timing is generated according to the video timing parameters, and the image data to be sent is encapsulated into a video excitation signal conforming to the ARINC818 protocol in combination with the protocol field parameters. The video excitation signal is then sent to the airborne display module under test. The video feedback signal from the airborne display module under test is collected, and the video feedback signal is parsed and data is extracted to obtain the actual protocol field information, actual video timing parameters and actual image data. The actual protocol field information, actual video timing parameters, and actual image data are compared with the test configuration information and the image data to be sent, respectively, to verify the consistency of the airborne display module under test.

2. The method according to claim 1, characterized in that, The video timing parameters are parameters that conform to the VESA timing standard, including at least one of the following: horizontal synchronization, vertical synchronization, front shoulder of horizontal line, back shoulder of horizontal line, front shoulder of vertical line, back shoulder of vertical line, and pixel clock frequency.

3. The method according to claim 1, characterized in that, The protocol field parameters include frame header parameters and container header parameters; The step of encapsulating the image data to be transmitted into a video excitation signal conforming to the ARINC818 protocol includes: The target identifier, source identifier, sequence number, container count, and video frame rate information are filled into the frame header or container header, and the image data to be sent is filled into the data frame, and combined to generate a video excitation signal that conforms to the ARINC818 protocol frame format.

4. The method according to claim 1, characterized in that, The acquisition of video feedback signals from the airborne display module under test includes: Receive the DVI video signal output by the airborne display module under test, convert the TMDS differential signal in the DVI video signal into RGB format data, and parse out the horizontal and vertical sync signals and pixel clocks. And / or, receive the ARINC818 fiber optic signal output by the airborne display module under test, perform 8B / 10B decoding and word alignment processing on the fiber optic signal, and parse out the data frame and control characters.

5. The method according to claim 1, characterized in that, After the steps of protocol parsing and data extraction of the video feedback signal, the method further includes: The actual protocol field information, actual video timing parameters, and actual image data are uploaded in the form of data blocks via direct memory access and a high-speed serial bus interface; wherein, the data block contains a data tag and a data payload, and the data tag encapsulates the receiving timestamp, resolution information, and line and field synchronization information.

6. The method according to claim 1, characterized in that, The step of comparing the actual protocol field information, actual video timing parameters, and actual image data with the test configuration information and the image data to be sent includes: The actual image data is restored to bitmap format and compared with the image data to be sent at the pixel level to calculate the similarity. The values ​​of the actual video timing parameters are compared with the predefined video timing parameters in the test configuration information. The frame header field in the actual protocol field information is compared with the predefined protocol field parameters in the test configuration information for consistency.

7. The method according to claim 1, characterized in that, The step of obtaining test configuration information also includes configuring the ARINC818 link rate; the steps of generating video excitation signals conforming to the ARINC818 protocol and collecting video feedback signals are all based on the link rate; wherein, the link rate is selected from one of 1.0625Gbps, 2.125Gbps, 3.1875Gbps and 4.25Gbps.

8. The method according to claim 1, characterized in that, The acquisition of video feedback signals from the airborne display module under test also includes: Set a specific field in the protocol field parameters as a trigger condition. The specific field includes a frame start character, a frame end character, a free character, or frame header data. When the data in the video feedback signal is detected to meet the triggering condition, the capture and parsing operation of the current data frame is triggered.

9. A test system for an ARINC818 airborne display module, characterized in that, The system includes an ARINC818 data transmission module, a DVI video transmission module, an ARINC818 data reception module, a DVI video reception module, and a data comparison module; The ARINC818 data transmission module and the DVI video transmission module are used to generate video excitation signals corresponding to the test configuration information and send them to the airborne display module under test through an external interface; and send the video excitation signals as expected data to the data comparison module. The ARINC818 data receiving module and the DVI video receiving module are used to collect video feedback signals from the airborne display module under test through an external interface, and send the video feedback signals as measured data to the data comparison module. The data comparison module is connected to the ARINC818 data sending module, the DVI video sending module, the ARINC818 data receiving module, and the DVI video receiving module, respectively. It is used to receive the expected data and the measured data, and to execute the ARINC818 airborne display module test method as described in any one of claims 1 to 8. By comparing the expected data with the measured data, the consistency of the airborne display module under test is verified.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the ARINC818 airborne display module test method according to any one of claims 1 to 8.

Images