Aerospace platform airborne system mode management method

Abstract

The invention belongs to the field of airborne system mode management, and particularly relates to an air-space platform airborne system mode management method. Comprising the following steps: after a system is normally powered off and powered on again, entering a normal starting mode; after the system is powered off abnormally in the air and powered on again, an air starting mode is entered; after executing DIF reset, the system enters a reset starting mode; after the system is started or the system receives a comprehensive control instruction, entering a control management mode, and executing comprehensive control and in-flight self-detection test; after the system receives the PBIT instruction, entering a system PBIT mode, and executing a self-detection test before the system flies; after receiving the MBIT instruction, the system enters a system MBIT mode and executes a system maintenance test; after receiving the OFP loading instruction, the system enters an OFP loading mode, and system software online loading is executed; after receiving the ground guarantee instruction, the system enters a ground guarantee mode and executes system ground guarantee; and after the power supply is powered off, entering a system power-off mode, and executing system power-off.

Description

Technical Field

[0001] The present application belongs to the field of airborne system mode management, and in particular relates to a method for airborne system mode management of an aerospace platform. Background Art

[0002] Airborne system mode management is a crucial element in ensuring stable system operation. The operating logic, control algorithms, and system status of each airborne device are closely tied to their modes. Airborne system mode management with a complete model, clear concepts, and a closed-loop transition will effectively ensure the normal operation of aerospace platforms.

[0003] However, current airborne systems generally suffer from the problem of single-mode management: on the one hand, the system only supports a single operating mode and lacks an efficient and reliable multi-mode dynamic switching mechanism; on the other hand, it is difficult to adapt to the stringent real-time mode switching requirements of complex missions. In view of this situation, in-depth research on airborne system mode management is of great engineering significance. The relevant research results will guide designers to establish a more comprehensive and clear airborne system mode management system, thereby providing strong support for the engineering application of aerospace platform models.

[0004] Therefore, there is an urgent need for a technical solution to overcome or alleviate at least one of the above-mentioned defects of the prior art. Summary of the Invention

[0005] The purpose of this application is to provide a method for managing the airborne system mode of an aerospace platform to solve at least one problem existing in the prior art.

[0006] The technical solution of this application is: A method for managing a system mode on an aerospace platform, comprising: After the system is powered off and then powered on again, it enters the normal startup mode and starts the system. After the system is abnormally powered off in mid-air and then powered on again, it enters the mid-air boot mode and starts the system. After the system performs DIF reset, it enters reset startup mode and performs system startup; After the system is started or receives the integrated control command, it enters the control management mode to perform integrated control and in-flight self-detection tests; After receiving the PBIT command, the system enters the system PBIT mode and performs the system pre-flight self-detection test; After receiving the MBIT instruction, the system enters the system MBIT mode and performs system maintenance test; After receiving the OFP loading instruction, the system enters the OFP loading mode and performs online loading of the system software; After receiving the ground support command, the system enters the ground support mode and executes the system ground support; After power failure, the system enters power-off mode and powers off the system.

[0007] In at least one embodiment of the present application, performing system startup in normal startup mode includes: Complete hardware initialization, power-on times recording, and solidify logic judgment through the boot program; Provide driver services for applications and operating systems through the board support package, including board support package migration verification, verification failure logging, and table initialization; Complete operating system startup, operating system migration verification, and cache initialization; Complete system partition initialization, power-on self-test, and set the mode status flag to normal startup mode.

[0008] In at least one embodiment of the present application, performing system startup in the air startup mode includes: Complete hardware initialization, power-on times recording, and solidify logic judgment through the boot program; Provide driver services for applications and operating systems through the board support package, including board support package migration verification, verification failure logging, and table initialization; Complete operating system startup, operating system migration verification, and cache initialization; Complete system partition initialization, the first long synchronization between channels, and set the modal state flag to air start mode.

[0009] In at least one embodiment of the present application, performing system startup in the reset startup mode includes: Complete hardware initialization, power-on times recording, and solidify logic judgment through the boot program; Provide driver services for applications and operating systems through the board support package, including board support package migration verification, verification failure logging, and table initialization; Complete operating system startup, operating system migration verification, and cache initialization; Complete system partition initialization, read the power-down mark, and set the mode state mark to reset startup mode.

[0010] In at least one embodiment of the present application, an in-flight self-detection test is performed in a control management mode. When a fault is detected, a comprehensive fault report and alarm are performed according to the fault type, and a fault logic strategy and a redundancy management strategy are executed.

[0011] In at least one embodiment of the present application, a system pre-flight self-test is performed in the system PBIT mode to detect whether the system hardware and system software functions normally.

[0012] In at least one embodiment of the present application, a system maintenance test is performed in the system MBIT mode to diagnose, verify and record the functional status of the system after maintenance.

[0013] In at least one embodiment of the present application, executing system software online loading in the OFP loading mode includes: OFP enters, and after the system software meets the online loading conditions and completes its own loading, it sends a loading signal to the secondary equipment. The online loading conditions include the ground support equipment being valid, the wheel load signal being valid, the discrete programming permission being valid, and the entry request being valid; OFP execution completes online loading of application software and operating system through the data bus, including file selection, file transfer, and file verification; OFP clear, including clear request, execution exit, and boot exit.

[0014] In at least one embodiment of the present application, performing system ground support in the ground support mode includes: Energy is provided by ground power supply vehicles, ground air source vehicles and ground hydraulic vehicles.

[0015] In at least one embodiment of the present application, performing system power-off in the system power-off mode includes: Enter power-off interrupt; Record the electrical mark; Determine whether the ground interlocking conditions are valid; If not, record the on-site data, record the fault event, and suspend the CPU; If so, record the fault event and halt the CPU.

[0016] In at least one embodiment of the present application, entering a power-off interrupt includes: When the power supply voltage is lower than 17V and the duration is greater than 10us, the power-off interrupt is triggered and the system enters the interrupt service routine.

[0017] In at least one embodiment of the present application, recording the power-off mark includes: recording the number of power-on times and the power-off time.

[0018] In at least one embodiment of the present application, when the wheel load signal is valid and the indicated airspeed meets the index requirement, the ground interlock condition is valid.

[0019] In at least one embodiment of the present application, recording field data includes: recording the last functional solution value, functional parameters, fault words and fault reporting data of redundancy management, and discrete quantity voting values.

[0020] In at least one embodiment of the present application, recording the fault event includes: recording the number and time of power-off and power-on in mid-air.

[0021] In at least one embodiment of the present application, suspending the CPU includes stopping the CPU, and the system enters a power-off state.

[0022] The invention has at least the following beneficial technical effects: The aerospace platform airborne system mode management method of this application has a complete mode, clear concepts, and a closed-loop conversion, so that the operating logic, control algorithm, system status, etc. of the airborne system can be better designed and developed, functionally improved, and engineering applied according to mission requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is a flow chart of a method for managing airborne system modes on an aerospace platform according to one embodiment of the present application; Figure 2 This is a system startup flow chart in normal startup mode according to an embodiment of the present application; Figure 3 This is a system startup flow chart in the air startup mode according to one embodiment of the present application; Figure 4 This is a system startup flow chart in the reset startup mode of an embodiment of the present application; Figure 5 This is a flowchart of executing system software online loading in OFP loading mode in one embodiment of the present application; Figure 6 This is a flowchart of executing system power-off in system power-off mode in one embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solutions and advantages of the implementation of this application clearer, the technical solutions in the embodiments of this application will be described in more detail below in conjunction with the drawings in the embodiments of this application. In the drawings, the same or similar reference numerals throughout represent the same or similar elements or elements with the same or similar functions. The described embodiments are part of the embodiments of this application, not all of the embodiments. The embodiments described below with reference to the drawings are exemplary and are intended to be used to explain this application, and should not be understood as limitations on this application. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. The embodiments of this application are described in detail below in conjunction with the drawings.

[0025] The following is combined with Figures 1 to 6 This application is described in further detail.

[0026] This application provides a method for managing airborne system modes of an aerospace platform, which is used to realize the conversion between multiple system modes, such as Figure 1As shown in the figure, the system modes include: normal startup mode, air startup mode, reset startup mode, control management mode, system PBIT (Power-Up Built-In Test) mode, system MBIT (Maintenance Built-In Test) mode, OFP (Operational Flight Program) loading mode, ground support mode, and system power-off mode.

[0027] Specifically, after a normal system power cycle, the system enters normal startup mode, where system startup operations are performed. Normal startup mode is the initialization process before real-time tasks are performed after a normal system power cycle. This process creates an initialization list for software variables, initializes and resets hardware units, and establishes the required system environment for subsequent activities.

[0028] In a preferred embodiment of the present application, the process of executing system startup in normal startup mode includes: Complete hardware initialization, power-on times recording, and solidify logic judgment through the boot program; Provide driver services for applications and operating systems through the board support package, including board support package migration verification, verification failure logging, and table initialization; Complete operating system startup, operating system migration verification, and cache initialization; Complete system partition initialization, power-on self-test, and set the mode status flag to normal startup mode.

[0029] In this embodiment, Figure 2As shown, the bootloader (BOOT) completes software power-on and initialization of basic hardware resources and channel fault logic, enabling software to access hardware resources normally. This includes hardware initialization, including initialization of various CPU registers; power-on count tracking, which counts the number of times the storage device (NVM) is powered on. This count is typically recorded by the storage device's firmware and can be read using specialized tools; fixed logic judgment, which solidifies specific logical rules or decision-making processes in the system, ensuring they are immune to external interference or dynamic changes and always execute according to preset conditions. The board support package (BSP) provides driver services for the application (TA) and operating system (OS). After startup, the BSP completes the terminal instruction jump to the Flash entry address. This includes BSP migration verification, which verifies the move from Flash to RAM (random access memory); verification failure logging, which records verification failures caused by errors during hardware initialization, firmware loading, or data verification; table initialization, which completes the jump from Flash to RAM address for execution; and level 1 interrupt initialization, including initialization of the level 1 interrupt for high-performance processors such as the Phytium processor. The operating system (OS) completes system partition migration and application partition migration, as well as cache initialization. This includes: OS startup, OS migration in Flash; OS migration verification, migration and verification; cache initialization, cache enabling, etc. The system partition (SSM) completes system startup / shutdown logic solution and power-on self-test (PUBIT). This includes: SSM initialization, PSV (Permanent Storage Volume) validity determination; power-on self-test, CPU self-test through PUBIT; and mode state flag setting, setting the mode state flag to normal boot mode.

[0030] After an unexpected power-off and power-on in mid-flight, the system enters over-the-air boot mode, where system startup operations are performed. Over-the-air boot mode is the initialization process for the software before real-time tasks are performed after an unexpected power-off and power-on in mid-flight. This process creates an initialization list for software variables, initializes and resets hardware units, and establishes the required system environment for subsequent activities.

[0031] In a preferred embodiment of the present application, the process of executing system startup in the air startup mode includes: Complete hardware initialization, power-on times recording, and solidify logic judgment through the boot program; Provide driver services for applications and operating systems through the board support package, including board support package migration verification, verification failure logging, and table initialization; Complete operating system startup, operating system migration verification, and cache initialization; Complete system partition initialization, the first long synchronization between channels, and set the modal state flag to air start mode.

[0032] In this embodiment, Figure 3 As shown, the bootloader (BOOT) completes software power-on and initialization of basic hardware resources and channel fault logic, enabling software to access hardware resources normally. This includes hardware initialization, which initializes various CPU registers; power-on count tracking, which counts the number of times the storage device (NVM) is powered on, typically recorded by the storage device's firmware and readable through specialized tools; fixed logic judgment, which solidifies specific logical rules or decision-making processes in the system, ensuring they are immune to external interference or dynamic changes and always execute according to preset conditions. The board support package (BSP) provides driver services for the application program (TA) and operating system (OS). After startup, the BSP completes the terminal instruction jump to the Flash entry address. This includes: BSP migration verification, which verifies the move from Flash to RAM; verification failure logging, which records verification failures caused by errors during hardware initialization, firmware loading, or data verification; table initialization, which completes the jump from Flash to RAM for execution; and level 1 interrupt initialization, including initialization of the level 1 interrupt for high-performance processors in the system, such as the Phytium processor. The operating system (OS) completes system partition migration and application partition migration, as well as cache initialization. This includes: OS startup, OS migration in Flash; OS migration verification, migration and verification; cache initialization, cache enabling, etc. The system partition (SSM) completes system startup / shutdown logic, including: SSM initialization, PSV validity determination, etc.; the first long inter-channel synchronization, used to eliminate the accumulated time error during the power-on reset process of redundant computers; and the setting of the modal state flag, completing the setting of the modal state flag to over-the-air boot mode.

[0033] After a DIF (Data Interface Fault) reset, the system enters reset startup mode, where system startup operations are performed. Reset startup mode is the initialization process before real-time tasks are performed after a DIF reset. This process creates an initialization list for software variables, initializes and resets hardware units, and establishes the required system environment for subsequent activities.

[0034] In a preferred embodiment of the present application, the process of executing system startup in the reset startup mode includes: Complete hardware initialization, power-on times recording, and solidify logic judgment through the boot program; Provide driver services for applications and operating systems through the board support package, including board support package migration verification, verification failure logging, and table initialization; Complete operating system startup, operating system migration verification, and cache initialization; Complete system partition initialization, read the power-down mark, and set the mode state mark to reset startup mode.

[0035] In this embodiment, Figure 4 As shown, the bootloader (BOOT) completes software power-on and initialization of basic hardware resources and channel fault logic, enabling software to access hardware resources normally. This includes hardware initialization, which initializes various CPU registers; power-on count tracking, which counts the number of times the storage device (NVM) is powered on, typically recorded by the storage device's firmware and readable through specialized tools; fixed logic judgment, which solidifies specific logical rules or decision-making processes in the system, ensuring they are immune to external interference or dynamic changes and always execute according to preset conditions. The board support package (BSP) provides driver services for the application program (TA) and operating system (OS). After startup, the BSP completes the terminal instruction jump to the Flash entry address. This includes: BSP migration verification, which verifies the move from Flash to RAM; verification failure logging, which records verification failures caused by errors during hardware initialization, firmware loading, or data verification; table initialization, which completes the jump from Flash to RAM for execution; and level 1 interrupt initialization, including initialization of the level 1 interrupt for high-performance processors in the system, such as the Phytium processor. The operating system (OS) completes system partition migration and application partition migration, as well as cache initialization. This includes: OS startup, OS migration in Flash; OS migration verification, migration and verification; cache initialization, cache enabling, etc. The system partition (SSM) completes system startup / shutdown logic, including: SSM initialization, PSV validity determination, etc.; power-down flag reading, if successful, enters reset startup mode determination; modal state flag setting, completing the setting of the modal state flag to reset startup mode.

[0036] After the system completes startup or receives integrated control commands, it enters control management mode. In this mode, integrated control and in-flight self-test (IFBIT) operations are performed. This is the system's primary operating mode, implementing integrated control functions and performing in-flight self-tests. When a fault is detected, comprehensive fault reporting and alarms are generated based on the fault type, and fault logic strategies and redundancy management strategies are implemented.

[0037] After receiving the PBIT command, the system enters System PBIT Mode, where it performs pre-flight self-tests. System PBIT Mode automatically executes built-in test procedures upon power-up after manual activation on the ground, checking the proper functioning of system hardware and software, completing pre-flight self-tests of all onboard systems.

[0038] After receiving the MBIT command, the system enters MBIT mode, where system maintenance testing is performed. MBIT mode is a built-in test procedure manually triggered by engineers or maintenance personnel during ground maintenance of aircraft systems. It is used to diagnose, verify, and record the functional status of the system after maintenance, assisting ground crew members in completing system maintenance tests.

[0039] In one embodiment of the present application, typical signals of the system PBIT mode and the system MBIT mode are shown in Table 1.

[0040] Table 1

[0041] After receiving the OFP loading command, the system enters OFP loading mode; in OFP loading mode, the system software is loaded online. OFP loading mode enables online loading of system software for the primary, secondary, and tertiary controllers of the airborne system. The relevant product uses a bus such as 1394B or RS422 / 485 to obtain the system software image and load its own software configuration items and bus configuration table. During the entire loading process, the airborne product does not need to be moved, the test port cover does not need to be opened, and power is supplied uniformly by the aircraft.

[0042] In a preferred embodiment of the present application, the process of performing online loading of system software in OFP loading mode includes: OFP enters, and after the system software meets the online loading conditions and completes its own loading, it sends a loading signal to the secondary equipment. The online loading conditions include the ground support equipment being valid, the wheel load signal being valid, the discrete programming permission being valid, and the entry request being valid; OFP execution completes online loading of application software and operating system through the data bus, including file selection, file transfer, and file verification; OFP clear, including clear request, execution exit, and boot exit.

[0043] In this embodiment, Figure 5As shown, the system software determines whether it meets the online loading conditions. Online loading conditions include: valid ground support equipment (GSE), that is, discrete ground debugging is valid; valid wheel load signal (WOW); valid discrete programming permission (ISPL); and valid entry request, that is, discrete ground debugging is valid. After the system software meets the online loading conditions and completes its own loading, it sends loading signals such as GSE, WOW, ISPL, and entry request to the secondary equipment. During OFP execution, online loading of application software, operating system software, etc. is completed via the data bus, including: file selection, selecting the file to be loaded; file transfer, sequentially transferring the files to be loaded; and file verification, verifying the correctness of the transferred files. The OFP clearing process includes clearing requests, executing exits, and booting exits.

[0044] After receiving ground support commands, the system enters ground support mode, where system ground support operations are executed. Ground support mode is a mode in which the system is powered by ground power trucks, ground air trucks, and ground hydraulic trucks during the ground support phase of the aerospace platform, ensuring normal operation.

[0045] After a power outage, the system enters power-down mode, where the system performs power-down operations. System power-down mode is a non-maskable interrupt processing process when the power voltage drops below 17V and the system receives a power-down signal.

[0046] In a preferred embodiment of the present application, Figure 6 As shown in the figure, the system power-off process in system power-off mode includes: Enter power-off interrupt; Record the electrical mark; Determine whether the ground interlocking conditions are valid; If not, record the on-site data, record the fault event, and suspend the CPU; If so, record the fault event and halt the CPU.

[0047] In this embodiment, entering the power-off interrupt specifically includes: when the power supply voltage is lower than 17V and the duration is greater than 10us, the power-off interrupt is triggered and the system enters the interrupt service routine. Recording the power-off mark includes: recording the number of power-on and power-off times through NVM. When the wheel load signal is valid and the indicated airspeed meets the index requirements, the ground interlock condition is valid. Recording field data includes: recording the last functional solution value, functional parameters, fault word and fault reporting data of redundancy management, and discrete quantity voting value. Recording fault events includes: recording the number and time of power-off and power-on in the air in NVM. Pausing the CPU includes stopping the CPU and the system enters the power-off state.

[0048] The aerospace platform airborne system mode management method of the present application provides the entry logic and execution logic of each mode of the airborne system, making the system mode design process clear and operational, and laying the foundation for the application of the aerospace platform airborne system; the airborne system mode has expansion capabilities, and through reserved interfaces, the airborne system mode can be expanded as the airborne system functions are improved.

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

Claims

1. A method for managing airborne system modes of an aerospace platform, characterized in that: include: After the system is powered off and then powered on again, it enters the normal startup mode and starts the system. After the system is abnormally powered off in mid-air and then powered on again, it enters the mid-air boot mode and starts the system. After the system performs DIF reset, it enters reset startup mode and performs system startup; After the system is started or receives the integrated control command, it enters the control management mode to perform integrated control and in-flight self-detection tests; After receiving the PBIT command, the system enters the system PBIT mode and performs the system pre-flight self-detection test; After receiving the MBIT instruction, the system enters the system MBIT mode and performs system maintenance test; After receiving the OFP loading instruction, the system enters the OFP loading mode and performs online loading of the system software; After receiving the ground support command, the system enters the ground support mode and executes the system ground support; After power failure, the system enters power-off mode and powers off the system.

2. The method for managing airborne system modes of an aerospace platform according to claim 1, characterized in that: Perform system startup in normal startup mode, including: Complete hardware initialization, power-on times recording, and solidify logic judgment through the boot program; Provide driver services for applications and operating systems through the board support package, including board support package migration verification, verification failure logging, and table initialization; Complete operating system startup, operating system migration verification, and cache initialization; Complete system partition initialization, power-on self-test, and set the mode status flag to normal startup mode.

3. The method for managing airborne system modes of an aerospace platform according to claim 2, characterized in that: Perform system startup in air boot mode, including: Complete hardware initialization, power-on times recording, and solidify logic judgment through the boot program; Provide driver services for applications and operating systems through the board support package, including board support package migration verification, verification failure logging, and table initialization; Complete operating system startup, operating system migration verification, and cache initialization; Complete system partition initialization, the first long synchronization between channels, and set the modal state flag to air start mode.

4. The method for managing airborne system modes of an aerospace platform according to claim 3, characterized in that: System startup is performed in reset startup mode, including: Complete hardware initialization, power-on times recording, and solidify logic judgment through the boot program; Provide driver services for applications and operating systems through the board support package, including board support package migration verification, verification failure logging, and table initialization; Complete operating system startup, operating system migration verification, and cache initialization; Complete system partition initialization, read the power-down mark, and set the mode state mark to reset startup mode.

5. The method for managing airborne system modes of an aerospace platform according to claim 4, characterized in that: In the control management mode, in-flight self-detection tests are performed. When a fault is detected, comprehensive fault reporting and alarms are performed according to the fault type, and fault logic strategies and redundancy management strategies are implemented.

6. The method for managing airborne system modes of an aerospace platform according to claim 5, characterized in that: In the system PBIT mode, the system pre-flight self-test is performed to check whether the system hardware and system software functions are normal.

7. The method for managing airborne system modes of an aerospace platform according to claim 6, characterized in that: Perform system maintenance tests in the system MBIT mode to diagnose, verify and record the functional status of the system after maintenance.

8. The method for managing airborne system modes of an aerospace platform according to claim 7, characterized in that: In OFP loading mode, system software is loaded online, including: OFP enters, and after the system software meets the online loading conditions and completes its own loading, it sends a loading signal to the secondary equipment. The online loading conditions include the ground support equipment being valid, the wheel load signal being valid, the discrete programming permission being valid, and the entry request being valid; OFP execution completes online loading of application software and operating system through the data bus, including file selection, file transfer, and file verification; OFP clear, including clear request, execution exit, and boot exit.

9. The method for managing airborne system modes of an aerospace platform according to claim 8, characterized in that: System ground support is performed in ground support mode, including: Energy is provided by ground power supply vehicles, ground air source vehicles and ground hydraulic vehicles.

10. The method for managing airborne system modes of an aerospace platform according to claim 9, characterized in that: In system power-off mode, power off the system, including: Enter power-off interrupt; Record the electrical mark; Determine whether the ground interlocking conditions are valid; If not, record the on-site data, record the fault event, and suspend the CPU; If so, record the fault event and halt the CPU.

11. The method for managing airborne system modes of an aerospace platform according to claim 10, characterized in that: Entering the power-down interrupt includes: When the power supply voltage is lower than 17V and the duration is greater than 10us, the power-off interrupt is triggered and the system enters the interrupt service routine.

12. The method for managing airborne system modes of an aerospace platform according to claim 11, characterized in that: Recording power-off marks includes: recording power-on times and power-off time.

13. The method for managing airborne system modes of an aerospace platform according to claim 12, characterized in that: When the wheel load signal is valid and the indicated airspeed meets the index requirements, the ground interlock condition is valid.

14. The method for managing airborne system modes of an aerospace platform according to claim 13, characterized in that: Recording of on-site data includes: recording the last functional solution value, functional parameters, fault word and fault reporting data of redundancy management, and discrete quantity voting value.

15. The method for managing airborne system modes of an aerospace platform according to claim 14, characterized in that: Recording fault events includes: recording the number and time of power-off and power-on in the air.

16. The method for managing airborne system modes of an aerospace platform according to claim 15, characterized in that: Pausing the CPU includes stopping the CPU and the system enters a power-off state.

Images