Partitioned real-time operating system FC-ethernet bridge network card adaptation method

Abstract

The application relates to an adaptation method of a partition real-time operating system FC-ethernet bridge network card. The application registers an FC device in a core layer user code segment as a virtual Ethernet network card by modifying a core layer related system file of a partition real-time system, configuring a related system environment, adapting and compiling a related driver library and a link library, solves the problem that an existing FC device is incompatible with an operating system, and enables upper-layer Ethernet application to directly perform fiber channel data transmission based on Ethernet interface functions. The adaptation method of the FC-ethernet bridge network card can solve the compatibility problem of a partition real-time operating system for a communication device, directly supports existing Ethernet application transplantation and system platform function expansion, and can provide an implementation idea more in line with open architecture requirements for avionics system development based on a partition real-time system and communication architecture design. Experimental results show that the application can effectively realize compatibility recognition of an operating system and application for an FC communication device, and upper-layer application can directly communicate on a fiber network based on Ethernet interface functions.

Description

Technical Field

[0001] This invention relates to the development of partitioned real-time embedded operating systems and network communication between FC protocol and Ethernet protocol, specifically to a method for implementing FC-Ethernet protocol bridging communication under a partitioned real-time operating system. Background Technology

[0002] In 1997, the American Aeronautical Electronics Engineering Committee (AEEC) defined a software security specification called ARINC 653 for integrated modular avionics systems in civil aircraft. This specification established a standard interface between the operating system layer and the application software layer, introduced the concept of partitioning, and implemented spatiotemporal isolation between applications. Currently, the ARINC 653 standard has become an important specification followed by mainstream open avionics systems. VxWorks 653 is a core component of Wind River's safety-critical ARINC 653 platform. It is an advanced isolated real-time operating system in the embedded industry. Through partitioned spatiotemporal resource allocation, it ensures the safety criticality of applications, employs a strict two-level scheduling mechanism, and exhibits excellent real-time performance and stability, fully meeting the requirements of ARINC 653 and RTCA / DO-178. Currently, VxWorks 653 has been successfully applied to over 180 subsystems in more than 40 types of aircraft from over 100 companies worldwide, including notable examples such as the Boeing 787 passenger jet and the US military's F-35 fighter jet.

[0003] Ethernet is currently the most widely used network communication protocol. It was first proposed in 1973, and in 1983, Xerox, Intel, and DEC jointly released the Ethernet II protocol. Based on its low cost, ease of networking, and strong scalability, it has become the mainstream network implementation technology. Currently, many mature applications and communication middleware are developed using this technology.

[0004] Fibre Channel (FC) is a high-speed serial transmission protocol proposed by the X3T11 group of the American Standards Committee in 1988. It solved the technical bottlenecks encountered by the parallel bus SCSI and is an effective solution for efficient transmission in large-scale, dense storage systems. While more complex than Ethernet, FC offers the advantages of both channel and network capabilities, boasting high bandwidth, high reliability, high stability, and strong resistance to electromagnetic interference. It provides highly stable and reliable communication connections, making it suitable for building large-scale data transmission and communication networks, supporting bandwidth connection rates of 1x, 2x, 4x, and 8x. Therefore, FC has been widely used in airborne avionics systems to build high-speed airborne communication networks, leading to the development of the corresponding Fibre Channel-Avionics Environment (FC-AE) series of standards, with the commonly used standard protocol being FC-AE-ASM.

[0005] Implementing FC-Ethernet bridging communication will help expand existing Ethernet applications on fiber optic networks. However, due to the significant differences between Ethernet and FC protocols, the implementation of communication solutions involves multiple aspects such as hardware drivers and operating systems. This presents challenges, particularly for FC-Ethernet bridging communication devices, where the added conversion modules require compatibility with the upper-layer operating system. For VxWorks653 systems, all related hardware and software interfaces must conform to the ARINC653 standard, which imposes strict restrictions on system API call permissions and system runtime health management. The design of bridging communication solutions must not only avoid impacting upper-layer Ethernet applications but also comply with relevant standards and specifications. Furthermore, compared to mainstream embedded operating systems such as VxWorks and Linux, there is currently limited domestic research on VxWorks653, with a severe shortage of reference materials. Therefore, research on FC-Ethernet bridging network cards for VxWorks653 systems remains incomplete.

[0006] However, for the development of airborne computers in avionics systems, implementing FC-Ethernet bridging communication on the VxWorks 653 system platform will combine the advantages of all three, helping to improve the openness, real-time performance, and reliability of the avionics system. Using the VxWorks 653 operating system ensures reliable real-time response of airborne applications, utilizing airborne fiber optic channels for efficient real-time data transmission, and employing mature applications developed based on the Ethernet protocol will reduce system development costs and improve reliability. This combination allows avionics systems, and even critical real-time systems, to greatly enrich their functionality by leveraging existing mature applications, providing them with broader development prospects under the trend of open architecture. Summary of the Invention

[0007] To address issues such as FC device identification and fiber optic communication in Ethernet applications, this invention proposes an adaptation method for a partitioned real-time operating system FC-Ethernet bridging network card. Specifically, this invention uses VxWorks653 2.5 as the partitioned real-time operating system, the P2020 RDB-PCA board as the overall hardware deployment platform, and the FCE-1221A daughter card (hereinafter referred to as the FC daughter card) as the FC-Ethernet bridging network card for specific instance construction.

[0008] This invention is based on a method for identifying an FC daughter card as a virtual Ethernet network card via PCI-E, enabling FC-Ethernet bridging communication in the VxWorks653 partitioned real-time operating system. The specific steps are as follows, and the flowchart is shown below. Figure 1 As shown:

[0009] Step S1: Modify system files to complete PCI-E environment configuration, call core layer system functions, and complete system registration for FC devices.

[0010] Step S2: Modify the FC driver library to complete the mapping association between FC protocol and Ethernet protocol addresses, and then add adaptations for the operating system.

[0011] Step S3: Complete the system device registration of the FC sub-card, recognize it as a virtual Ethernet network card, initialize the bridged network card in the system core layer, and complete the parameter configuration of the bridged network card.

[0012] This completes the setup of the FC-Ethernet bridge network card in the VxWorks 653 core layer system, recognizing the FC daughter card as a virtual Ethernet network card. Applications within the upper-layer partition can directly call the FC device to perform data transmission and reception operations on the Fibre Channel through the Ethernet function interface.

[0013] The beneficial effects of this invention are: it enables the partitioned real-time embedded operating system to be compatible with and recognize FC devices, allowing them to be directly used by upper-layer Ethernet protocol applications, and providing basic communication support for the functional expansion of safety-critical systems. The approach provided by this invention can offer universally applicable ideas and reference methods for building communication architectures based on partitioned real-time operating systems, ensuring communication protocol compatibility, and porting application components. Attached Figure Description

[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0016] Appendix Figure 1 A flowchart illustrating a method for FC-Ethernet bridging communication in a partitioned real-time operating system.

[0017] Appendix Figure 2 System platform architecture diagram of the present invention

[0018] Appendix Figure 3 A diagram illustrating the PCI-E device memory pool entry settings in the system configuration file of this invention.

[0019] Appendix Figure 4 The result diagram of PCI-E-based FC daughter card identification in this embodiment of the invention

[0020] Appendix Figure 5 Schematic diagram of the FC-Ethernet data frame encapsulation and decapsulation process according to an embodiment of the present invention

[0021] Appendix Figure 6 Schematic diagram of the modified FC driver module according to an embodiment of the present invention

[0022] Appendix Figure 7 Diagram of the compilation process of the FC driver source file executable file in this embodiment of the invention.

[0023] Appendix Figure 8 Figure showing the test results of Fibre Channel Ethernet command communication in an embodiment of the present invention. Detailed Implementation

[0024] To make the technical solution and objectives of this invention clearer and more understandable, the implementation steps of this invention will be described in detail below.

[0025] The implementation example of this invention uses a Freescale P2020 RDB-PCA hardware board running VxWorks 653 2.5 operating system; an FCE-1221A node card (FC daughter card) from Optical Fiber Optics is used to connect to the hardware board via PCI-E to provide fiber optic transmission support. A schematic diagram of the system platform architecture is attached. Figure 2 As shown. This example is a specific illustration of the present invention, used to fully demonstrate the implementation ideas of the present invention, and its implementation is not limited to this example.

[0026] This invention proposes an adaptation method for FC-Ethernet bridging network cards based on the VxWorks653 partitioned real-time operating system. The specific adaptation method is as follows:

[0027] Step S1: Complete the PCI-E environment configuration by modifying system files, and use core layer system functions to complete the system registration for FC devices.

[0028] Step S1.1: Modify the core layer system configuration file to complete the addition of the PCI-E device core IO memory pool.

[0029] First, in the system configuration file at the core layer, add the core I / O memory pool for PCI-E devices. This memory pool will provide space for data from PCI-E devices. In this example, it corresponds to the fsl_p2020_rdb.xml file. Add a "kernelIO3" entry with a size of 256MB after the existing core I / O memory pool. The configuration result is shown in the attached figure. Figure 3 As shown.

[0030] Step S1.2: Modify the core layer system configuration header file, adding or modifying macro variables related to basic PCI-E device information.

[0031] In the core layer system configuration header file, macro variable definitions need to be added regarding basic information such as the PCI-E device memory space base address, memory size, and PCI-E bridge. This information corresponds to the PCI-E device core IO memory pool information mentioned above and will be used as parameters during driver registration and PCI-E driver library function usage. In this example, the corresponding system configuration header files are config.h and fsl_p2020_rdb.h. The supplementary basic information macro variables include PCIE_LAW_BASE, PCIE_LAW_SIZE, PCIE_LAW_SIZE1, PCIE_MMU_TLB_SZ, PCIE_MMU_ADRS, PCIE_MMU_SIZE, PCIE_IO_ADRS, PCIE_IO_SIZE, PCIE_MMU_MEMIO_ADRS, and PCIE_MMU_MEMIO_SIZE. Modify these memory sizes and register addresses to ensure they are consistent with the values ​​in the description file in the board support package. Step S1.3: Modify the core layer system library function file and complete the PCI-E driver registration.

[0032] In the core layer system library function file, add the source files and header files of the referenced driver library operation functions to integrate the PCI-E driver interface into the core layer operating system. Use the corresponding initialization functions to complete the PCI-E driver registration, providing interface support for reading and writing data to FC daughter card devices based on PCI-E connections. In this example, the corresponding core layer library function file is sysLib.c, and the added header / source files include...<drv / pci / m85xxPci.h> ,<speLib.h> ,<pci / pciExConfigShow.c> ,<pci / pciExAutoConfigLib.c> ,<drv / m85xxTimer.c> ,<drv / picTmrDrv.c> Then, the sysHwInit function is used in the sysLib.c file to complete the PCI-E device driver registration, so that the system can automatically load the PCI-E driver library when loading, and data can be read and written through the FC daughter card via PCI-E.

[0033] Step S1.4: Complete the parameter configuration of the PCI-E device to realize the recognition of the FC device.

[0034] In the kernel operating system's user code segment, the corresponding parameters are set using PCI-E configuration functions. After system loading, the connected FC daughter card is identified, which is fundamental to operating FC devices. This example uses the `sysPciExpressAutoConfig` function in the user code segment of the `usrAppInit.c` file in the VxWorks653 kernel operating system to automatically configure the PCI-E device. After system loading, the `pciExDeviceShow` command is executed in the Host Shell on the host machine to query the PCI-E mounted devices. The FC daughter card with the vendor ID 0x10ee is successfully identified. The FC daughter card identification result is shown in the attached figure. Figure 4 As shown.

[0035] Step S2: Modify the FC driver library to complete the mapping association between FC protocol and Ethernet protocol addresses, and then add adaptations for the operating system.

[0036] Step S2.1: Modify the FC driver library, add a protocol encapsulation interface, and complete the address mapping association between the FC protocol and the Ethernet protocol.

[0037] By mapping the Domain ID, Area ID, and Port ID in the FC-ID to the MAC, IP, and Port addresses in the Ethernet address, a one-to-one address mapping relationship between FC and Ethernet is established. Subsequently, a corresponding interface is added to the FC driver to encapsulate Ethernet data frames from the upper-layer system as data segments into FC frames, thereby achieving FC-Ethernet bridging communication. In this example, the TCP / IP four-layer network protocol model is used as the basis for Ethernet data frame encapsulation, and its protocol encapsulation process is shown in the appendix. Figure 5 As shown in the attached diagram, the modified FC driver module is as follows. Figure 6 As shown.

[0038] Step S2.2: Complete the adaptation and modification of the FC driver library functions, and compile them into a static link library using the corresponding compiler of the operating system.

[0039] Verify that the FC driver library functions match the operating system's PCI-E and Ethernet function interfaces to ensure consistency, enabling the system's Ethernet applications to operate FC devices via PCI-E. Then, compile the FC driver library source files into several executable files using the operating system's compiler. Next, use the appropriate compilation tools to compile these executable files into static link libraries and add them to the system for runtime. System configuration will then enable the FC driver library's functionality. This example utilizes the VxWorks653 2.5 Development Shell in the Workbench to run GNU-related commands and complete the compilation of the FC driver library executable files. The compilation results of the source files are attached. Figure 7 As shown; then, the arrpc and ranlibppc tools are used to integrate several executable files into the FC driver static link library PCI_6553.a.

[0040] Step S2.3: Add the FC driver static link library to the system image.

[0041] In the system compilation configuration options, set the corresponding parameters to include the FC driver static link library in the system image compilation process. In this example, in the Workbench core layer project compilation properties tab, by adding the statement EXTRA_LIBS+=$(PRJ_DIR) / PCI_6553.a to the Build Command box, the compiled FC driver static link library is added to the system runtime image.

[0042] Step S3: Complete the system device registration of the FC sub-card, recognize it as a virtual Ethernet network card, initialize the bridged network card in the system core layer, and complete the parameter configuration of the bridged network card.

[0043] Step S3.1: Uninstall the existing Ethernet network card in the core layer system.

[0044] In the core layer system user code segment, corresponding functions are used to unload the existing Ethernet network card's device and protocol stack configurations, reserving space for mounting the FC daughter card. This example uses the `ipDetach` and `muxDevUnload` functions in the user code segment of the core layer's `usrAppInit.c` file to unload the existing Ethernet network card, and the `hostDelete` and `routeDelete` functions to unload the Ethernet host and path-related configuration information.

[0045] Step S3.2: Complete the parameter configuration of the FC device and initialize the virtual network card.

[0046] In the core layer system user code segment, corresponding functions are used to configure the parameters of the FC device and establish the mapping relationship between the FC-ID and the Ethernet address. The FC device is then recognized as an Ethernet network card via PCI-E, thus enabling the virtual network card to be mounted and directly used by upper-layer Ethernet applications. In this example, the user code segment of the core layer file usrAppInit.c uses the ipAttach and usrNetIfConfig functions to configure the user-defined network card (virtual network card), and the netInit and pciConfig interfaces to initialize the FC device and read the configuration file storing the FC-ID Ethernet address mapping relationship. This completes the entire adaptation process for the FC-bridged network card. Two P2020 RDB boards are connected to the FCE-1221A daughter card on the Fibre Channel, running the VxWorks 653 2.5 partitioned real-time operating system. Communication tests are performed by running Ethernet ping commands between the boards in the host shell. The test results are attached. Figure 8 As shown, the results prove that the present invention successfully adapts the FC-Ethernet bridging network card, and can directly run Ethernet commands on the Fibre Channel.

[0047] As described above, this invention, through modifying system configuration and adapting the corresponding driver library, identifies an FC daughter card with FC-Ethernet bridging function as a virtual Ethernet network card based on PCI-E, enabling upper-layer Ethernet applications to communicate directly on the Fibre Channel. This solves the FC device identification compatibility problem and achieves the adaptation of the FC-Ethernet bridging network card for the partitioned real-time operating system.

[0048] The adaptation method for FC-Ethernet bridging network cards in the partitioned real-time operating system proposed in this invention is based on bus devices to achieve compatibility recognition of FC communication devices. Through corresponding system configuration and code modification, upper-layer applications can directly call the FC communication device interface. Based on this invention, compatibility recognition of FC protocol communication devices can be achieved on different hardware platforms, providing basic support for the porting of Ethernet applications and the expansion of system platform functions.

[0049] Any obvious modifications, equivalent substitutions, or further optimizations made to the above details without departing from the basic technical concept and spirit of the present invention shall be included within the scope of the claims of the present invention.

Claims

1. A method for adapting a partitioned real-time operating system FC-Ethernet bridging network card, used to implement FC-Ethernet bridging communication on the VxWorks653 system platform, characterized in that, By modifying system files and configuring the system environment, the FC communication device is recognized as a virtual Ethernet network card using the hardware bus, achieving compatibility with FC bridging communication network cards and enabling upper-layer Ethernet applications to directly call the corresponding interfaces. This method can be customized and adjusted for different application scenarios and requirements to achieve bridging communication in different hardware and software environments. The adaptation method includes the following steps: Step S1: Modify system files to complete the PCI-E environment configuration, call core layer system functions, and complete system registration for the FC device; the specific steps in step S1 are as follows: Step S1.1: Modify the core layer system configuration file to add the PCI-E device core I / O memory pool; First, in the core layer system configuration file, add the PCI-E device core I / O memory pool, which will provide space for data from the PCI-E device; In the corresponding fsl_p2020_rdb.xml file, add a "kernelIO3" entry with a size of 256M after the existing core I / O memory pool; Step S1.2: Modify the core layer system configuration header file, adding or modifying macro variables related to basic PCI-E device information. In the core layer system configuration header file, macro variable definitions need to be added regarding the PCI-E device memory space base address, memory size, and basic PCI-E bridge information. This information corresponds to the PCI-E device core IO memory pool information and will be used as parameters during driver registration and PCI-E driver library function usage. The corresponding system configuration header files are config.h and fsl_p2020_rdb.h, supplementing the added basic information macros. The variables include PCIE_LAW_BASE, PCIE_LAW_SIZE, PCIE_LAW_SIZE1, PCIE_MMU_TLB_SZ, PCIE_MMU_ADRS, PCIE_MMU_SIZE, PCIE_IO_ADRS, PCIE_IO_SIZE, PCIE_MMU_MEMIO_ADRS, and PCIE_MMU_MEMIO_SIZE. Modify these memory sizes and register addresses to make them consistent with the values ​​in the description file in the board support package. Step S1.3: Modify the core layer system library function files and complete the PCI-E driver registration; Step S1.4: Complete the parameter configuration of the PCI-E device to achieve FC device recognition; Step S2: Modify the FC driver library to complete the mapping association between FC protocol and Ethernet protocol addresses, and then add adaptations for the operating system; Step S3: Complete the system device registration of the FC sub-card, recognize it as a virtual Ethernet network card, initialize the bridge network card in the system core layer, and complete the parameter configuration of the bridge network card.

2. The partitioned real-time operating system FC-Ethernet bridging network card adaptation method according to claim 1, characterized in that, In step S2, the specific steps are as follows: Step S2.1: Modify the FC driver library, add a protocol encapsulation interface, and complete the address mapping association between the FC protocol and the Ethernet protocol; Step S2.2: Complete the adaptation and modification of the FC driver library functions, and compile them into a static link library using the corresponding compiler of the operating system; Step S2.3: Add the FC driver static link library to the system image.

3. The method for adapting a partitioned real-time operating system FC-Ethernet bridging network card according to claim 1, characterized in that, In step S3, the specific steps are as follows: Step S3.1: Uninstall the existing Ethernet network card in the core layer system; Step S3.2: Complete the parameter configuration of the FC device and initialize the virtual network card.

Images