Avionics bus multi-protocol module based on software definition

Abstract

The invention discloses an avionic bus multi-protocol module based on software definition, and belongs to the technical field of avionics. The hardware and the drive of the module adopt a common platform design; the hardware is based on an FPGA architecture and comprises an FPGA module, an interface circuit, an auxiliary circuit and a storage space, and an integrated hardware platform is formed. The FPGA module is configured to automatically load the mcs solidification file from the storage space after being powered on, and different avionics bus functions are achieved through software definition; and the driver is a PCIe driver, is used as an interface of logic and application software, supports message communication and access to the storage space, and adopts a uniform data format. Through a software definition mode, a single hardware platform can support multiple avionics bus protocols, the problems that in the prior art, due to deep binding of hardware and protocols, the platform cannot be reused, and testing equipment is complex are solved, and the research and development cost can be effectively saved.

Description

Technical Field

[0001] This invention relates to the field of avionics, and more specifically to a software-defined avionics bus multi-protocol module. Background Technology

[0002] The statements in this section are provided only as background information in connection with this disclosure and may not constitute prior art.

[0003] The field of avionics involves a wide variety of bus communication protocols, including the Fiber Channel (FC) bus, the Serial RapidIO (SRIO) bus, the ARINC818 bus, and the Aurora bus.

[0004] In the existing technological system, different bus protocols typically employ dedicated and independent implementation schemes. Specifically, each existing bus module consists of independent hardware circuitry, accompanying drivers, and specific protocol layer software. This architecture deeply binds each bus function to a specific hardware platform, making it impossible to achieve the generalization of hardware resources.

[0005] The existing technology of "one protocol corresponding to one set of dedicated hardware" has the following main drawbacks: because different buses are based on completely different hardware platforms, the types of test equipment required during system integration or testing are complicated and the hardware platforms cannot be reused, thereby increasing the complexity of the system and the development cost. Summary of the Invention

[0006] The purpose of this invention is to address the technical problem in the current avionics field where different types of bus protocol modules typically consist of independent hardware, drivers, and protocol layers, leading to unusable hardware platforms and complex testing equipment. This invention provides a software-defined avionics bus multi-protocol module with a shared hardware platform architecture. Different bus functions are implemented through software definition, thereby solving the problems of wasted hardware resources and high R&D costs caused by the deep binding of bus protocols to specific hardware in the prior art.

[0007] The technical solution of the present invention is as follows: A software-defined avionics bus multi-protocol module, the hardware and drivers of which adopt a common platform design; The hardware is based on an FPGA architecture and includes an FPGA module, interface circuits, auxiliary circuits, and storage space, forming an integrated hardware platform. The FPGA module is configured to automatically load the MCS firmware file from the storage space after power-on and implement different avionics bus functions through software definition. The driver is a PCIe driver, which serves as an interface between logic and application software, supports message communication and access to the storage space, and adopts a unified data format.

[0008] Furthermore, the auxiliary circuit includes a power supply, a clock, and control logic; The storage space is a Flash memory; The MCS firmware files include firmware files that support Fibre Channel bus, Serial RapidIO bus, ARINC818 bus and Aurora bus protocol types respectively, and each type of MCS firmware file has a different PCIe device number to distinguish logical versions.

[0009] Furthermore, the unified data format includes: The C2H format from the avionics bus multi-protocol module to the host computer and the H2C format from the host computer to the avionics bus multi-protocol module are both defined in little-endian. In the C2H format data interaction, the avionics bus multi-protocol module sends data to the host computer in 4K-byte units. The 4K-byte data includes one or more data packets, and invalid data is filled with 0xFF.

[0010] Furthermore, in the C2H format data, each frame consists of a time tag L, a time tag H, a custom frame header, a length, and a payload field; the time tag L and the time tag H are 32-bit low-order and high-order time tag values, respectively; the custom frame header is 32 bits and is used to distinguish between board type and interface type; the length is 32 bits, representing the length of the payload field in bytes.

[0011] Furthermore, the custom frame header includes: The external bus type field, located at bits 0-7, is used to identify the external bus protocol type; The internal bus type field, located at bits 8-15, is used to identify the internal bus protocol type; The instruction / data type identifier field, located at bits 16-23, is used to identify the type of the current frame; The channel number field, located at bits 24-31, is used to identify the data channel.

[0012] Furthermore, the values ​​of the instruction / data type identifier field are defined as follows: A value of 1 indicates the data packet type; A value of 2 indicates a register type; When the value is 3, different types are indicated according to the indication of the external bus type field: when the external bus type field indicates Fibre Channel bus, it indicates primitive type; when the external bus type field indicates Aurora bus, it indicates control command type.

[0013] Furthermore, the data format of the load field is determined based on the value of the instruction / data type identifier field: When the instruction / data type identifier field is set to 1, the payload field is the data packet type, and its payload contains all fields of the actual data frame from the frame header SOF to the frame tail EOF. When the instruction / data type identifier field is 2, the payload field is of register type, and the first DWORD of the payload is the number of registers, and the second DWORD is the register operation type.

[0014] Furthermore, when the instruction / data type identifier field is 2, the register operation type includes the following definition: A value of 1 indicates a register write operation; A value of 2 indicates a register read operation; When the value is 3, it indicates a register read feedback operation.

[0015] Furthermore, the specific format of the payload following the register operation type is defined as follows: When performing a write operation to a register, two fixed DWORDs are used, where [31:0] is the register address and [63:32] is the register value; When performing a register read operation, two fixed DWORDs are used, where [31:0] is the register address and [63:32] is any padding value; When performing a register read feedback operation, two fixed DWORDs are used, where [31:0] is the register address and [63:32] is the register value.

[0016] Furthermore, the avionics bus multi-protocol module is configured to support protocol switching; during protocol switching, the driver responds to the instructions of the host computer software tool, writes the MCS firmware file corresponding to the target logic version into the storage space, and reads the file from the storage space for comparison to verify whether the writing is correct. The avionics bus multi-protocol module is configured to load the updated MCS firmware file from the storage space after the comparison is correct and the power is restarted, so as to run the avionics bus protocol corresponding to the target logic version.

[0017] Compared with existing technologies, the advantages of this invention are: 1. Hardware Reuse and Cost Savings: This invention adopts a hardware common platform architecture. Through this design, a single hardware component can support different avionics protocols through software definition, saving R&D costs. Specifically, users do not need to develop dedicated hardware modules for different protocols such as Fibre Channel, SRIO, and ARINC818, thus avoiding redundant hardware design and manufacturing investments.

[0018] 2. Simplified Testing and Integration: This invention solves the problem of complex testing equipment caused by each bus being based on different hardware platforms in existing technologies. Through a unified PCIe driver interface and data interaction format, the host computer application software can interact with different protocol logics in a standardized manner, reducing the complexity of system integration and maintenance.

[0019] 3. Flexible protocol switching capability: This invention can switch logical functions by loading different MCS files, so that the same module can be flexibly configured as different bus devices according to actual mission requirements, which greatly improves the flexibility and adaptability of the avionics system. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in the embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0021] Figure 1 This is a block diagram of a software-defined avionics bus multi-protocol module. Figure 2 This is a diagram of the FPGA architecture. Figure 3 This is the C2H data exchange format; Figure 4 The data is in C2H format. Figure 5 This is the data format for the load portion. Detailed Implementation

[0022] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0023] The features and performance of the present invention will be further described in detail below with reference to embodiments.

[0024] Example 1 Please see Figure 1 The core of this invention, a software-defined avionics bus multi-protocol module, lies in achieving flexible protocol reconfiguration through a hardware-software collaborative architecture. In practical implementation, the system architecture and functional implementation of this module mainly involve collaborative work at four levels. Specifically, the design consists of five parts: hardware design, logic design, PCIe driver design, dynamic library interface design, and protocol switching design. These parts are described below: I. Hardware Design The multi-protocol board is based on an FPGA architecture and can be functionally divided into three parts: the FPGA module, interface circuits, and auxiliary circuits such as power supply, clock, and control logic. Combined with necessary drivers for the FPGA and PCIe, and the on-board control logic, it forms a complete, integrated hardware platform. For example... Figure 2 As shown.

[0025] After the board is powered on, it will automatically load the FPGA program from the Flash memory.

[0026] II. Logic Design Different MCS (Multi-Card System) files are generated for Fiber Channel (FC), SRIO (Serial RapidIO), ARINC818, and Auraro buses. Each file supports different protocol types. To facilitate application differentiation of logical versions, each MCS file has a different PCIe device number. MCS files can be stored in Flash memory.

[0027] III. PCIe Driver Design PCIe drivers serve as the interface between logic and application software, supporting message communication and Flash access. A unified format is used to ensure data consistency.

[0028] The data format includes two formats: card to host (C2H) and host to card (H2C); the following definitions are given in little-endian.

[0029] C2H data format is as follows: Figure 3 As shown, the board sends data to the host in 4KB units. Depending on the actual situation, 4KB may include one or more data packets, and invalid data is filled with 0xFF.

[0030] Each frame consists of a time stamp L, a time stamp H, a custom header, a length, and a payload field, such as... Figure 4 As shown in the table below: Table 1 Data Format Definition

[0031] The board type and interface type are distinguished by a custom frame header. The custom frame header is defined as follows: Table 2 Custom Frame Header Definitions

[0032] Table 3 Instruction / Data Type Identifiers

[0033] Table 4 Length Field Definition

[0034] Please see Figure 5 Load description: When cmd_type = 1, the payload data packet contains all fields from SOF to EOF of the actual data (FC, SRIO, UDP) frame.

[0035] When cmd_type = 2, the register type is defined as follows: the first DWORD indicates the number of registers in the payload, and the second DWORD indicates the type. Type 1 indicates register write; type 2 indicates register read; and type 3 indicates register read feedback. Register write: The payload occupies two fixed DWORDs, [31:0] is the register address, and [63:32] is the register value; Register read: The payload occupies two fixed DWORDs, [31:0] is the register address, and [63:32] is any fill value; Register read feedback: The payload occupies two fixed DWORDs, [31:0] is the register address, and [63:32] is the register value.

[0036] IV. Dynamic Library Interface Design The dynamic library is designed with five modules: FC protocol module, SRIO protocol module, ARINC818, Auraro protocol module, and Flash read / write module. The FC protocol module, SRIO protocol module, ARINC818, and Auraro protocol module correspond to different protocol types, while the Flash read / write module is used to control Flash reading and writing.

[0037] V. Protocol Switching Design When a user needs to switch protocols, they should first open the software tool provided with this product. The tool will first scan the hardware board. Then, the user selects the logic version to switch to and clicks "Confirm." After confirmation, the driver interface will be called to embed the corresponding MCS file into the flash memory. The driver then reads the flash file for comparison. If the comparison is correct, the switch is successful.

[0038] Example 2 Based on the design scheme proposed in Example 1, a software-defined avionics bus multi-protocol module was designed, specifically including: The hardware and drivers of this module adopt a common platform design; The hardware is based on an FPGA architecture and includes an FPGA module, interface circuits, auxiliary circuits, and storage space, forming an integrated hardware platform. The FPGA module is configured to automatically load the MCS firmware file from the storage space after power-on and implement different avionics bus functions through software definition. The driver is a PCIe driver, which serves as an interface between logic and application software, supports message communication and access to the storage space, and adopts a unified data format.

[0039] In this embodiment, specifically, the auxiliary circuit includes a power supply, a clock, and control logic; The storage space is a Flash memory; The MCS firmware files include firmware files that support Fibre Channel bus, Serial RapidIO bus, ARINC818 bus and Aurora bus protocol types respectively, and each type of MCS firmware file has a different PCIe device number to distinguish logical versions.

[0040] In this embodiment, specifically, the unified data format includes: The C2H format from the avionics bus multi-protocol module to the host computer and the H2C format from the host computer to the avionics bus multi-protocol module are both defined in little-endian. In the C2H format data interaction, the avionics bus multi-protocol module sends data to the host computer in 4K-byte units. The 4K-byte data includes one or more data packets, and invalid data is filled with 0xFF.

[0041] In this embodiment, specifically, in the C2H format data, each frame consists of a time tag L, a time tag H, a custom frame header, a length, and a payload field; the time tag L and the time tag H are 32-bit low-order and high-order time tag values, respectively; the custom frame header is 32 bits and is used to distinguish between board type and interface type; the length is 32 bits, representing the length of the payload field in bytes.

[0042] In this embodiment, specifically, the custom frame header includes: The external bus type field, located at bits 0-7, is used to identify the external bus protocol type; The internal bus type field, located at bits 8-15, is used to identify the internal bus protocol type; The instruction / data type identifier field, located at bits 16-23, is used to identify the type of the current frame; The channel number field, located at bits 24-31, is used to identify the data channel.

[0043] In this embodiment, the specific values ​​of the instruction / data type identifier field are defined as follows: A value of 1 indicates the data packet type; A value of 2 indicates a register type; When the value is 3, different types are indicated according to the indication of the external bus type field: when the external bus type field indicates Fibre Channel bus, it indicates primitive type; when the external bus type field indicates Aurora bus, it indicates control command type.

[0044] In this embodiment, specifically, the data format of the load field is determined based on the value of the instruction / data type identifier field: When the instruction / data type identifier field is set to 1, the payload field is the data packet type, and its payload contains all fields of the actual data frame from the frame header SOF to the frame tail EOF. When the instruction / data type identifier field is 2, the payload field is of register type, and the first DWORD of the payload is the number of registers, and the second DWORD is the register operation type.

[0045] In this embodiment, specifically, when the instruction / data type identifier field is 2, the register operation type includes the following definition: A value of 1 indicates a register write operation; A value of 2 indicates a register read operation; When the value is 3, it indicates a register read feedback operation.

[0046] Furthermore, the specific format of the payload following the register operation type is defined as follows: When performing a write operation to a register, two fixed DWORDs are used, where [31:0] is the register address and [63:32] is the register value; When performing a register read operation, two fixed DWORDs are used, where [31:0] is the register address and [63:32] is any padding value; When performing a register read feedback operation, two fixed DWORDs are used, where [31:0] is the register address and [63:32] is the register value.

[0047] In this embodiment, specifically, the avionics bus multi-protocol module is configured to support protocol switching; during protocol switching, the driver responds to the instructions of the host computer software tool, writes the MCS firmware file corresponding to the target logic version into the storage space, and reads the file from the storage space for comparison to verify whether the writing is correct; The avionics bus multi-protocol module is configured to load the updated MCS firmware file from the storage space after the comparison is correct and the power is restarted, so as to run the avionics bus protocol corresponding to the target logic version.

[0048] The embodiments described above merely illustrate specific implementation methods of this application, and while the descriptions are detailed and specific, they should not be construed as limiting the scope of protection of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the technical solution of this application, and these modifications and improvements all fall within the scope of protection of this application.

[0049] This background section is provided to generally present the context of the invention. The work of the currently named inventors, the work to the extent described in this background section, and aspects of this section that did not constitute prior art at the time of application are neither expressly nor impliedly acknowledged as prior art to the invention.

Claims

1. A software defined avionics bus multiprotocol module, comprising: The hardware and driver of the module adopt a common platform design; The hardware is based on an FPGA architecture, and comprises an FPGA module, an interface circuit, an auxiliary circuit and a storage space, forming an integrated hardware platform; The FPGA module is configured to automatically load an mcs solidification file from the storage space after power-on, and to realize different avionics bus functions through software definition; The driver is a PCIe driver, which serves as an interface of logic and application software, supports message communication and access to the storage space, and adopts a unified data format.

2. The software defined avionics bus multiprotocol module according to claim 1, wherein, The auxiliary circuit comprises a power supply, a clock and control logic; The storage space is a Flash memory; The mcs solidification file comprises solidification files respectively supporting fiber channel bus, serial RapidIO bus, ARINC818 bus and Aurora bus protocol types, and each type of the mcs solidification file has a different PCIe device number for distinguishing logic versions.

3. The software defined avionics bus multi-protocol module of claim 2, wherein, The unified data format comprises: C2H format from the avionics bus multi-protocol module to a host computer and H2C format from the host computer to the avionics bus multi-protocol module, and both are defined in a little-endian mode; in data interaction of the C2H format, the avionics bus multi-protocol module sends data to the host computer in units of 4K bytes, and the 4K bytes of data include one or more data packets, with invalid data filled with 0xFF.

4. The software-defined multi-protocol avionics bus module of claim 3, wherein, Each frame in the C2H format data is composed of a time tag L, a time tag H, a custom frame header, a length and a payload field; the time tag L and the time tag H are respectively a 32-bit low time tag value and a high time tag value; the custom frame header is 32 bits, used for distinguishing card type and interface type; and the length is 32 bits, representing the length of the payload field in bytes.

5. The software defined avionics bus multi-protocol module of claim 4, wherein, The custom frame header comprises: an external bus type field located at bit0-bit7, used for identifying an external bus protocol type; an internal bus type field located at bit8-bit15, used for identifying an internal bus protocol type; an instruction / data type identification field located at bit16-bit23, used for identifying the type of a current frame; a channel number field located at bit24-bit31, used for identifying a data channel.

6. The software defined avionics bus multi-protocol module of Claim 5, wherein, The instruction / data type identification field has the following value definitions: when the value is 1, it represents a data packet type; when the value is 2, it represents a register type; when the value is 3, it represents different types according to the indication of the external bus type field: when the external bus type field indicates a fiber channel bus, it represents a primitive type; and when the external bus type field indicates an Aurora bus, it represents a control command type.

7. The software defined avionics bus multi-protocol module of Claim 6, wherein, The data format of the payload field is determined according to the value of the instruction / data type identification field: when the instruction / data type identification field has a value of 1, the payload field is of a data packet type, and its payload contains all fields of an actual data frame from a frame header SOF to a frame trailer EOF; When the instruction / data type identification field takes value 2, the load field is a register type, the first DWORD of the payload is the number of registers, and the second DWORD is a register operation type.

8. The software defined avionics bus multi-protocol module of claim 7, wherein, When the instruction / data type identification field takes value 2, the register operation type includes the following definitions: Value 1 represents a register write operation; Value 2 represents a register read operation; Value 3 represents a register read feedback operation.

9. The software defined avionics bus multi-protocol module of claim 8, wherein, The specific format of the payload after the register operation type is defined as follows: When it is a register write operation, two fixed DWORDs are occupied, wherein [31:0] is a register address, and [63:32] is a register value; When it is a register read operation, two fixed DWORDs are occupied, wherein [31:0] is a register address, and [63:32] is an arbitrary fill value; When it is a register read feedback operation, two fixed DWORDs are occupied, wherein [31:0] is a register address, and [63:32] is a register value.

10. The software defined avionics bus multi-protocol module of claim 9, wherein, The avionics bus multi-protocol module is configured to support a protocol switching function; when the protocol is switched, the driver writes an mcs firmware file corresponding to a target logic version into the storage space in response to an instruction of a host computer software tool, and reads a file from the storage space to perform comparison to verify whether the writing is correct; The avionics bus multi-protocol module is configured to load the updated mcs firmware file from the storage space after the comparison is correct and a power supply is re-applied, to run an avionics bus protocol corresponding to the target logic version.

Images