An airborne health management computer operational scenario design method

Abstract

The application provides an airborne health management computer operation scheme design method, comprising the following steps: determining the to-be-loaded image type and quantity of each to-be-loaded image module in an air monitoring mode and a ground maintenance mode according to user requirements; designing a software operation flow according to the design guarantee level of each image of different modules; executing first stage boot software FSBL after power-on to initialize hardware and a minimum system; guiding different image software according to a mode selection switch: when the mode selection switch is invalid, the system is in the air monitoring mode, and then the boot function is directly performed; when the mode selection switch is valid, the system is in the ground maintenance mode, and then second stage boot software IAP is executed to execute corresponding boot or loading functions according to maintenance commands of an upper computer. The application can realize boot and maintenance of the system in different modes, improve data security and maintainability, and improve the reuse rate and expandability of the software operation architecture of the airborne computer.

Description

Technical Field

[0001] This invention relates to the field of airborne computer system software, and more specifically to a design method for an airborne health management computer operation scheme. Background Technology

[0002] Due to changes in user requirements, joint testing, upgrades, and the development of different airborne health management computer projects, it is necessary to determine the design assurance level, quantity, and operating mode of the loading images for each module according to user needs. Modules with different design assurance levels are isolated to implement boot and maintenance functions under different operating modes. The module images will also be modified and updated as needed in the future.

[0003] Most current operating architectures do not differentiate between modules with different design assurance levels, only implementing bootstrapping functionality. The architectures lack consideration for physical and logical isolation between high-security and low-security systems, failing to meet the airworthiness certification requirements of civil aircraft. This increases certification costs when multiple projects require airworthiness certification. Furthermore, the platform software for airborne health management computers based on the existing operating architecture requires development experience from maintenance personnel. It fails to consider that stakeholders of airborne equipment extend far beyond developers, including application developers, airborne equipment manufacturers, hangar maintenance personnel, and the airworthiness authorities after delivery. The maintenance and upgrade processes are complex, lack practicality, and are not truly capable of being delivered to users. Summary of the Invention

[0004] In view of this, embodiments of this application provide a design method for an airborne health management computer operation scheme to form a general airborne health management computer operation architecture, which can be used to implement system booting and maintenance in different modes, thereby improving data security and maintainability, as well as improving the reusability and scalability of the airborne computer software operation architecture.

[0005] This application provides the following technical solution: a design method for an airborne health management computer operation scheme, comprising:

[0006] The software of the airborne health management computer distinguishes between a high-security operating state and a low-security operating state, which correspond to the airborne surveillance mode and the ground maintenance mode, respectively.

[0007] Based on user requirements, determine the type and quantity of images to be loaded for each image module to run in air surveillance mode and ground maintenance mode, and then proceed with the software operation process.

[0008] The software operation flow is designed according to the design assurance level of each image of different modules. After power-on, the first-stage boot software FSBL is executed first to initialize the hardware and implement minimum system initialization, and to boot different software images according to the mode selection switch: when the mode selection switch is invalid and the system is in air surveillance mode, the boot function is directly executed to boot the corresponding module's operating system and the corresponding application software image; when the mode selection switch is valid and the system is in ground maintenance mode, the second-stage boot software IAP is executed, and the corresponding boot or loading function is executed according to the maintenance command type sent by the software loading tool in the ground support equipment.

[0009] According to one embodiment of this application, after entering the second-stage boot software IAP, if a maintenance command is received from the ground support equipment, the user mode or developer mode is selected according to the type of maintenance command, and the corresponding loading command is executed according to the user loading instruction in the user mode or the developer programming instruction in the developer mode.

[0010] According to one embodiment of this application, in the second-stage boot software IAP, if a user loading command is received from the ground support equipment, the current module waits for the previous module to complete the loading command before loading the corresponding application image. The previous module executes the module platform software image OS and executes the loading command. After loading is completed, the application image is sent to the current module for hardening.

[0011] According to one embodiment of this application, in the second-stage boot software IAP, if a developer load command is received from the ground support equipment, each module performs the image loading, downloading, and unloading functions.

[0012] According to one embodiment of this application, after entering the second-stage boot software IAP, if no maintenance command is received from the ground support equipment, the platform software image OS of the corresponding module is executed and the corresponding application image is executed.

[0013] According to one embodiment of this application, in the second-stage boot software IAP, corresponding extended instructions can be executed according to user needs to expand the bootable image, and booting can be performed through maintenance commands to adapt to different platforms.

[0014] This invention discloses a design method for an airborne health management computer operation scheme. This method controls the software's operational flow and the number and types of loading images for module booting under different operating modes and design assurance levels. In the first stage of system booting, a basic operating environment is provided for subsequent code execution, completing necessary software environment initialization and performing layer-by-layer initialization of hardware functions from the inside out. The hardware involved includes the CPU (core, internal ROM, and internal RAM), external pins, FLASH, and DDR, etc. Based on the mode selection switch, the software requiring first-stage booting is moved from non-volatile memory to DDR. The second stage of booting, via the communication bus, implements different boot behaviors based on user maintenance commands, enabling application software booting or loading in different ways. This function is independent of specific interfaces and is suitable for maintaining communication interfaces, implementing software loading, unloading, and downloading functions, and completing data interaction with ground support equipment and modules.

[0015] The method of this invention has been applied to multiple airborne computer systems, which greatly improves the reusability and scalability of airborne computer software operating architecture. It can meet the mutual isolation and compatibility of different design assurance levels, and realize that all software can only migrate from a high-security operating state to a low-security operating state, and cannot migrate from a low-security operating state to a high-security operating state, thereby reducing the difficulty of software operation and the development and airworthiness costs. Attached Figure Description

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

[0017] Figure 1 This is a flowchart of a method according to an embodiment of the present invention;

[0018] Figure 2 This is a flowchart illustrating the processing of the IAP developer mode maintenance command in this embodiment of the invention.

[0019] Figure 3 This is a flowchart of the software operation architecture in an embodiment of the present invention;

[0020] Figure 4 This is a flowchart illustrating the execution process of the first-stage software and the second-stage software in an embodiment of the present invention.

[0021] Figure 5 In this embodiment of the invention, other loading commands are executed in user mode;

[0022] Figure 6In this embodiment of the invention, the loading, downloading, and uninstallation of software are performed in developer mode.

[0023] Figure 7 This is an example of executing an extended image in the calibration mode of this invention. Detailed Implementation

[0024] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0025] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments, providing a clear and complete description of the technical solutions of the present invention. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0026] like Figure 1 As shown, this embodiment of the invention provides a method for designing an airborne health management computer operation scheme, which distinguishes between a high-security operation state and a low-security operation state for the airborne health management computer's software. The high-security operation state and the low-security operation state correspond to airborne surveillance mode and ground maintenance mode, respectively. Specifically, it includes the following steps:

[0027] The first step is to determine the types and quantities of images to be loaded for each image module in both airborne surveillance mode and ground maintenance mode, based on user requirements. See Table 1 for the images that need to be loaded for each module in both airborne surveillance mode and ground maintenance mode.

[0028] Table 1. Loading images of each module under different modes

[0029]

[0030] The second step involves designing the software operation flow according to the design assurance levels of each module and image. Specific guidance procedures for airborne surveillance mode and ground maintenance mode can be found in [reference needed]. Figure 3 Upon power-up, the first-stage boot software FSBL is executed to initialize the hardware and perform minimal system initialization, as well as to boot different software images based on the mode selection switch: when the mode selection switch is inactive and the system is in over-the-air surveillance mode, the boot function is performed directly, directly booting the corresponding module's operating system and the corresponding application software image; when the mode selection switch is active and the system is in ground maintenance mode, the second-stage boot software IAP is executed, performing the corresponding boot or loading function based on the maintenance command type sent by the software loading tool in the ground support equipment.

[0031] The third step, within the Phase 2 boot software IAP, involves executing corresponding image loading, downloading, unloading, or booting functions based on the maintenance command type sent by the software loading tool in the ground support equipment. The Phase 2 boot provides two fixed maintenance modes: Developer Mode, which maintains all software, and User Mode, which only maintains field-loadable software. When a User Mode maintenance command is received, the software loading type is determined by assessing the design level of the running module. When a Developer Mode maintenance command is received, the boot process executes online loading, unloading, and downloading functions for all loadable images. For details on the boot process in this mode, please refer to [link to documentation / reference]. Figure 2 When no maintenance command is received, the system operates in the same manner as in over-the-air surveillance mode, guiding the application software of the corresponding module to execute commands. To ensure stability and security, the second-stage guidance is implemented entirely through maintenance commands, minimizing the risk of false triggers caused by command failures. For the overall operational architecture and processing flow, please refer to [link to documentation / process]. Figure 3 .

[0032] Fourth, in the second-stage boot software (IAP), other maintenance modes are provided according to user needs, and the application execution supported by boot permissions is also provided. Here, the bootable image can be flexibly expanded according to the actual needs of the user. Booting is carried out through specific maintenance commands. In the developer maintenance command mode, the calibration mode is set. The maintenance command definition in the calibration mode is shown in Table 2, so as to adapt to different platforms.

[0033] Table 2 Definition of maintenance commands in calibration mode

[0034]

[0035] This invention enables the boot function in normal working mode: it enables minimum system initialization, mode selection, and boot functions.

[0036] This invention enables software loading, unloading, and downloading in maintenance mode: it receives and processes maintenance commands from ground maintenance equipment, determines the type of operation and maintenance mode, loads, unloads, and downloads images, and completes data interaction with ground support equipment or modules.

[0037] This invention enables flexible expansion of bootable images: it has field scalability, no longer limits the number of loadable and runnable software images, and allows users to freely add additional images according to their different usage scenarios without affecting existing software images, thereby enabling other maintenance functions.

[0038] This invention enables physical and logical isolation between high-security and low-security modules: it satisfies the mutual isolation of images with different design assurance levels, and all software can only migrate from a high-security operating state to a low-security operating state, but cannot migrate from a low-security operating state to a high-security operating state, thus possessing airworthiness operability and reducing airworthiness costs.

[0039] The present invention will be further described below with reference to the accompanying drawings and embodiments. Figures 2 to 7 , Figure 2 This is a flowchart of the processing commands under the IAP developer mode maintenance command. Figure 3 It is a software architecture operation flowchart. Figure 4 This is a flowchart of the execution process for the first and second phases of the software. Figure 5 This executes other loading commands in user mode. Figure 6 This is the developer mode for loading, downloading, and uninstalling software. Figure 7 This executes the extended image in calibration mode.

[0040] Among them, such as Figure 2 As shown, when the target machine receives the pairing command from the ground maintenance equipment, if the command is a load command, it executes the equipment pairing function. After successful pairing, it obtains the area of ​​the program to be loaded, sends the file header, clears the media of the corresponding area in the FLASH, and executes the data loading function. If the command is an unload command, it executes the equipment pairing function. After successful pairing, it obtains the area to be cleared and clears the media of the corresponding area in the FLASH. If the command is a download command, it executes the equipment pairing function. After successful pairing, it obtains the area to be downloaded and executes the download function.

[0041] like Figure 3As shown, after the target machine powers on, it first executes the FSBL first-stage boot software to complete the initialization of the hardware and minimum system. Based on the user's system plan and the security level requirements for the images running in different modes of each module, physical and logical isolation is used to enable FSBL to boot images of different security levels to execute corresponding functions. When the mode selection is invalid and it is a high-security module, FSBL boots the high-security image; when the mode selection is valid or it is a low-security module, the IAP boot function is executed. Since in ground maintenance mode, in addition to performing image loading, unloading, and download functions, it is also necessary to directly boot the image to determine if its functionality is correct. Therefore, whether the host computer sends a maintenance command determines whether IAP directly boots the image or performs image loading, unloading, and download functions. Because there are differences between the development environment and the actual field environment, it is necessary to adapt to different actual environments to implement image loading, unloading, and download functions. Therefore, upon receiving a maintenance command, different loading, unloading, and download functions are executed according to user mode or developer mode. Furthermore, to expand and accommodate subsequent user needs, other maintenance commands can be added to extend the image functionality.

[0042] like Figure 4 As shown, during FSBL operation, the discrete values ​​of the mode switch are read to determine whether to guide the image execution in ground maintenance mode or air surveillance mode. When running in ground maintenance mode, it is determined whether a maintenance command has been received from the ground maintenance equipment within 3 seconds. If the command is an online loading command (developer mode), the corresponding loading, downloading, and unloading functions are executed. If the command is another loading command (user mode), different functions are executed according to the module requirements. If the command times out or is an interface maintenance command, the corresponding image is guided to execute.

[0043] The specific implementation will be explained using the operation scheme of a certain airborne device as an example.

[0044] The first step is to determine the images to be loaded for each module (Module 1, Module 2) in both airborne and ground maintenance modes based on user requirements. The architecture's operational flow is then determined according to the design assurance level of each image. (See [link to relevant documentation]). Figure 3 .

[0045] The second step involves the FSBL bootloader running first after power-on to perform minimal system initialization. Once loaded, it boots different software images based on the mode selection switch. (See also...) Figure 4 When the operating module is Module 2 and the mode selection switch is invalid (i.e., air surveillance mode), the operating module 2 platform software image (OS) is run and the corresponding application image is executed, with a design assurance level of high security. When the mode selection switch is valid (i.e., ground maintenance mode), the design assurance level is low security, and the second-stage loading software IAP is executed.

[0046] The third step involves entering IAP. If no maintenance command is received from ground support equipment, the corresponding module's platform software image (OS) and application image are executed. If a user loading command is received from ground support equipment, module 2 waits for module 1 to complete other loading commands before loading the corresponding application image. Module 1 executes module 1's platform software image (OS) and other loading commands. After loading is complete, the application image is sent to module 2 for hardening. (See [link to relevant documentation]). Figure 5 If a developer load command is received from ground support equipment, both Module 1 and Module 2 will perform image loading, downloading, and unloading functions, as detailed in the documentation. Figure 6 .

[0047] Fourthly, in IAP, based on user needs, other maintenance mode types are also provided when running module 1. When the maintenance command is in calibration mode, its format can be found in Table 2. This guides the execution of applications with supported permissions, enabling image expansion. (See also...) Figure 7 .

[0048] The software operation scheme designed in this invention can not only meet the mutual isolation and compatibility of different design assurance levels, and support software maintenance, software loading, uninstallation and download, but also flexibly expand the bootable image according to the user's usage scenario, and adapt to the software of airborne health management computers and other airborne equipment on different platforms.

[0049] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A design method for an airborne health management computer operation scheme, characterized in that, include: The software of the airborne health management computer distinguishes between a high-security operating state and a low-security operating state, which correspond to the airborne surveillance mode and the ground maintenance mode, respectively. Based on user requirements, determine the type and quantity of images to be loaded for each image module to run in air surveillance mode and ground maintenance mode, and then proceed with the software operation process. The software operation flow is designed according to the design assurance level of each image of different modules. After power-on, the first-stage boot software FSBL is executed first to initialize the hardware and implement minimum system initialization, and to boot different software images according to the mode selection switch: when the mode selection switch is invalid and it is in air surveillance mode, the boot function is directly executed to directly boot the operating system of the corresponding module and the corresponding application software image; when the mode selection switch is valid and it is in ground maintenance mode, the second-stage boot software IAP is executed, and the corresponding boot or loading function is executed according to the maintenance command type sent by the software loading tool in the ground support equipment. In particular, after entering the second stage of the IAP (Initial Access Programming) software, if a maintenance command is received from the ground support equipment, the user mode or developer mode is selected according to the type of maintenance command, and the corresponding loading command is executed according to the user loading instruction in the user mode or the developer programming instruction in the developer mode. In the second phase of the IAP (In-Application Programming) software, if a user loading command is received from the ground support equipment, the current module waits for the previous module to complete the loading command before loading the corresponding application image. The previous module executes its platform software image (OS) and executes the loading command. After loading is complete, the application image is sent to the current module for hardening.

2. The airborne health management computer operation scheme design method according to claim 1, characterized in that, In the second phase of the IAP (In-Application Programming) software, if a developer load command is received from ground support equipment, each module performs the image loading, downloading, and unloading functions.

3. The airborne health management computer operation scheme design method according to claim 1, characterized in that, After entering the second phase of the boot software IAP, if no maintenance command is received from the ground support equipment, the platform software image OS of the corresponding module is executed and the corresponding application image is executed.

4. The design method for an airborne health management computer operation scheme according to claim 1, characterized in that, In the second stage of the boot software IAP, corresponding extended instructions are executed according to user needs to expand the bootable image, and the image is booted through maintenance commands to adapt to different platforms.

Images