An IMA recovery method compliant with AC 20-170

Abstract

The present invention belongs to the technical field of IMA for airborne avionics systems, and particularly relates to an IMA recovery method conforming to AC 20-170. It includes: Step 1: Trigger automatic recovery functions of different levels and different module types according to fault classification. The fault classification includes: resident application faults, hardware module resource faults, and platform resource faults; Step 2: If the automatic recovery function fails to eliminate the faults of the resident application or the hardware module, and the safety level of the functions related to the faulty resident application or hardware module is high, then report the current fault to the flight crew in the cockpit; Step 3: Receive the external trigger from the flight crew to complete the IMA recovery. It enhances the availability of the IMA system, improves the safety of the IMA system, and provides guarantee for the airworthiness review of the IMA system.

Description

Technical Field

[0001] The present invention belongs to the technical field of airborne avionics system IMA, and particularly relates to an IMA recovery method conforming to AC 20-170. Background Art

[0002] During the flight of an aircraft, the IMA system may experience abnormal operation of resident functions or IMA cabinet failures, but the actual installed IMA hardware components are in a non-permanent failure situation. AC 20-170 stipulates that for functions that must continuously operate for system safety assessment, the IMA system must have the ability to restart these resident functions.

[0003] Advisory Circular AC 20-170, "Integrated Modular Avionics Development, Verification, Integration, and Approval Using RTCA DO-297 and Technical Standard Order-Cl53", is an advisory circular issued by the Federal Aviation Administration (FAA) of the United States for DO-297, stating that DO-297 is a compliance method acceptable to the airworthiness review department. For any applicant using an IMA system in a TSOA, TC, or STC, compliance with the RTCADO-297 standard can be considered as a method for the IMA system to obtain FAA approval (but DO-297 is not the only method); AC 20-170 supplements the content not covered in DO-297 and provides guidance on how to apply this document in the TSO, TC / STC certification process. Among them, Chapter 6 of AC 20-170 puts forward specific requirements for the IMA system recovery function. The present invention complies with the above requirements and aims to design a recovery function that meets the requirements of AC 20-170, which not only improves the safety of the IMA system but also provides guarantee for the airworthiness review of the IMA system. Summary of the Invention

[0004] The object of the present invention is to provide an IMA recovery method conforming to AC 20-170, aiming to meet the recovery function requirements of AC20-170, improve the safety of the IMA system, and provide guarantee for the airworthiness review of the IMA system.

[0005] The technical solution of the present invention:

[0006] An IMA recovery method conforming to AC 20-170 includes:

[0007] Step 1: Trigger the automatic recovery functions of different levels and different module types according to the fault classification. The fault classification includes: resident application faults, hardware module resource faults, and platform resource faults;

[0008] Step 2: If the automatic recovery function fails to eliminate the faults of the resident application or the hardware module, and the security level of the functions related to the resident application or the hardware module with the fault is high, then report the current fault to the flight crew in the cockpit;

[0009] Step 3: Receive the external trigger from the flight crew to complete the IMA recovery.

[0010] Further, reporting the current fault to the flight crew in the cockpit specifically includes:

[0011] Report the current fault to the flight crew in the cockpit through warning messages, voice warnings, or warning lights.

[0012] Further, Step 1 specifically includes:

[0013] Step 11: When only resident application faults exist, perform the partition-level recovery of the resident application;

[0014] Step 12: When there are no platform resource faults and there are hardware module resource faults, perform the module-level recovery;

[0015] Step 13: When there are platform resource faults, perform the platform-level recovery.

[0016] Further, the partition-level recovery of the resident application in Step 11 specifically includes:

[0017] When a resident application fault occurs, independently start the partition recovery operation for each partition.

[0018] Further, the module-level recovery in Step 12 specifically includes:

[0019] Obtain the restart count of the hardware module with the current fault;

[0020] Compare the restart count with the configuration data of the module fault management;

[0021] When the restart count is less than the limit count, start a soft reset of the hardware module with the current fault to restart the module; if the restart count exceeds the limit count, report the module failure information to the platform and suspend the hardware module with the current fault. The module failure information includes: module ID and fault type.

[0022] Further, the platform-level recovery in Step 13 specifically includes:

[0023] Receive all the module failure information within the platform;

[0024] Compare the module IDs in the failure information of each module with the configuration data of the platform fault management respectively to determine the safety levels of each faulty module;

[0025] In the case of a faulty hardware module with a high safety level, compare the number of restart times of the platform for the faulty hardware module with the configuration data of the platform fault management;

[0026] When the number of restart times is less than the specified number, recover the faulty hardware module with a high safety level through platform operations; if the number of restart times exceeds the specified number, report the current fault to the flight crew in the cockpit.

[0027] Furthermore, recovering the faulty hardware module with a high safety level through platform operations specifically includes:

[0028] Input a command of "cut off the power supply of the faulty hardware module with a high safety level for a predetermined time" to the power module to perform a cold restart of the module.

[0029] Furthermore, the predetermined time is 3 seconds.

[0030] Advantages of the present invention: A combined design method based on classified and graded automatic recovery supplemented by manual recovery, which proposes different countermeasures for different (resident function) fault types, enhances the usability of the IMA system, and improves the safety of the IMA system; The recovery function design is carried out based on the requirements of AC 20-170, providing guarantee for the airworthiness review of the IMA system. Brief Description of the Drawings

[0031] Figure 1 is a schematic diagram of the module automatic recovery operation process;

[0032] Figure 2 is a schematic diagram of manual recovery operation. Detailed Embodiment

[0033] Based on the requirements of the recovery function in AC 20-170, the present invention proposes a method for implementing system recovery by combining two means of automatic recovery and manual recovery. A combined design method based on classified and graded automatic recovery supplemented by manual recovery, which proposes different countermeasures for different (resident function) fault types, enhances the usability of the IMA system, improves the safety of the IMA system, and provides guarantee for the airworthiness review of the IMA system.

[0034] The present invention will be further described in detail below with reference to the accompanying drawings.

[0035] An IMA recovery method compliant with AC 20-170, which is a combined design method based on classified and hierarchical automatic recovery supplemented by manual recovery. Different countermeasures are proposed for different (resident function) fault types, enhancing the usability of the IMA system and improving the security of the IMA system.

[0036] The present invention implements system recovery by combining two means of automatic recovery and manual recovery. For (resident function / IMA platform) faults, different levels and different module types of automatic recovery functions are first triggered according to the fault classification; if the automatic recovery function fails to eliminate the faults of the resident application (HA) or the general processing module (GPM), and the safety level of the functions related to the faulty HA or GPM is high (such as the GPM resident safety-critical function), then the IMA platform fault management system reports the current fault to the flight crew in the cockpit in the form of alarm messages, voice alarms or alarm lights, and it is up to the flight crew to decide whether to activate the manual recovery function.

[0037] 1. Automatic recovery

[0038] Automatic recovery is divided into three levels: resident application partition level, module level and platform level according to the scope of recovery operations. The logical process of its recovery function processing is to report and process step by step from partition -> module -> platform. The specific operation process is as follows:

[0039] (1) Resident application partition level recovery:

[0040] —When a resident application fails, start the partition recovery operation, meeting the requirements of A653;

[0041] —The resident application partition level recovery recovers independently by partition and does not affect the operation of other partitions of the same module;

[0042] (2) Module level recovery:

[0043] Based on the classification of IMA platform functional modules, it usually includes general processing module (GPM), large-capacity storage, video processing unit, network switching unit (SWM), and remote interface unit (RIU). The following module level recovery operations are applicable to the above functional modules. The specific process is:

[0044] When a module detects a fault, compare the configuration data of the module fault management to determine whether to start the module level recovery function. If the recovery requirements are met and the restart times are less than the limit times, the module starts a soft reset to restart the module; if the recovery requirements are met and the restart times exceed the limit times, the module reports this information to the recovery function, and the module declares failure and suspends, as Figure 1 shown;

[0045] Module-level recovery is independently restored separately according to the isolation of physical module installation, and does not affect the operation of the same module;

[0046] (3) Platform-level recovery:

[0047] — When it is detected that a module fails and sends, compare the configuration data of the platform fault management to determine whether it is necessary to restore the module at the platform level. If the recovery requirements are met and the restart count is less than the limit, the recovery function inputs a command of "cut off the power supply of this functional module for 3s" to the power management function to perform a cold restart of the module;

[0048] — Platform-level recovery is only applicable to all functional modules in the cabinet, except for the power module and the GPM that does not run the platform-level recovery function;

[0049] — Platform-level recovery is independently restored separately according to the isolation of physical module installation, and does not affect the operation of the same module;

[0050] (4) Other features:

[0051] — There are two GPMs in one side cabinet of the IMA platform that respectively reside in the "recovery function", and at the same time reside in the power management function; it is recommended that the platform-level health management and fault management also reside on the same GPM. The platform power supply should provide emergency power supply input to this GPM;

[0052] — If the GPM resides in the recovery function and the power management function, then it only supports partition-level recovery and module-level automatic recovery, but does not support the separate platform-level single-module recovery function; on the contrary, the GPM automatic recovery function not only supports module-level hot restart recovery, but also supports platform-level cold restart recovery.

[0053] (5) Configurability:

[0054] — The automatic recovery times of each level and each type of functional module are independently configurable;

[0055] — The number of automatic recoveries depends on the highest functional development assurance level (FDAL) of HA / resident function (HF), usually not exceeding 5 times.

[0056] — In fault management, the fault conditions that trigger the automatic recovery function are configurable;

[0057] — Configuration method: 1) Input through data loading; 2) Input through the configuration file after power-on;

[0058] (6) Input interfaces include:

[0059] — Cockpit "cabinet recovery" interface: Operated by flight crew members, the button press is valid only when held for at least 1s;

[0060] — Configuration file;

[0061] —Health monitoring and fault management at different levels, compared with the configuration file to determine whether to start the (automatic / manual) recovery program;

[0062] (VII) Output:

[0063] —Power management function - cut off the power supply of other modules for at least 3s to ensure the restart of other modules;

[0064] —Recovery log: Record information about relevant recovery operations such as the number of restarts.

[0065] 2. Manual recovery

[0066] Manual recovery refers to the manual operation by the flight crew to restart the system during flight through intervention. Specifically, in the present invention, when a system / platform fault is detected, the manual restart mechanism can be activated. 1) The flight crew operates the "cabinet recovery" interface to restore all functional modules in a single cabinet of the IMA platform. 2) The flight crew operates the "application recovery" interface to restore the resident applications (a group of partitions) of the GPM. As Figure 2 , as shown in the process.

[0067] The remote switching unit and the remote interface unit have automatic recovery functions. Since there are a large number of these two types of hardware units installed, if manual recovery functions are designed for both, it will not only significantly increase the workload of the flight crew but also easily lead to errors (due to too many buttons). Moreover, these two types of hardware units themselves have redundancy design, which improves safety (availability) through redundant backup. Therefore, during flight, the remote switching unit and the remote interface unit do not have manual recovery functions, and the manual recovery function is only applicable to the IMA cabinet. (The remote switching unit and the remote interface unit can be designed with manual recovery functions for the use process of ground maintenance personnel to improve the convenience of maintenance operations.) In case of an IMA platform fault, according to the platform-level fault configuration, it is reported to the flight crew. The reporting forms include alarm information, voice alarm, and alarm lights. The flight crew decides to initiate manual recovery, and the specific operation process is as follows:

[0068] (I) "Cabinet recovery"

[0069] —The flight crew presses the "left cabinet recovery" or "right cabinet recovery" elastic button and holds it down for at least 1s (to avoid accidental misoperation);

[0070] —Only the GPM module with the resident recovery function has the "cabinet recovery" interface. There are two GPMs in a single cabinet of the IMA platform that respectively reside in the "recovery function" and also reside in the power management function simultaneously; it is recommended that the platform-level health management and fault management also reside on the same GPM. The platform power supply should provide emergency power input to this GPM;

[0071] — The recovery function is configured according to the platform configuration data;

[0072] — After the recovery function detects that the "cabinet recovery" signal is valid, it inputs a command of "cut off the power supply of all modules in the cabinet for 3s" to the power management function;

[0073] — The power module sequentially cuts off the power supply of all functional modules in the cabinet. After 3s, the power module sequentially supplies power to all functional modules in the cabinet;

[0074] — If the GPM with the resident recovery function fails to operate the normal power-off of the cabinet, the power module can be triggered to cut off the power supply of all functional modules in the cabinet for 3s by pressing and holding the button for more than 5s;

[0075] — The manual recovery counter in the recovery function is incremented by 1;

[0076] — Manual recovery of the avionics function;

[0077] (2) HA and GPM reset

[0078] — The GPM must be able to reset a group of partitions according to the received application reset signal.

[0079] — The relationship between the application reset signal and the partitions to be reset must be configurable. The application reset must be executed by the embedded operating system (RTOS).

[0080] — The application reset of an avionics application (a group of partitions) must not be able to affect other resident applications on the same GPM.

[0081] 3. Operation process of the recovery function

[0082] Automatic recovery is divided into three levels: resident application partition level, module level, and platform level according to the execution scope of the recovery operation. The logical process of its recovery function processing is to report and process step by step from partition -> module -> platform.

[0083] When the HA fails, the partition automatic recovery is first started. When the number of partition automatic recovery reaches the upper limit, the partition announces the HA failure and reports the failure to the module;

[0084] The module starts the module-level hot restart automatic recovery. When the number of module automatic recovery reaches the upper limit, the module announces the failure and reports the failure to the platform;

[0085] The platform starts the platform-level cold restart automatic recovery. The platform cuts off the power supply of the module by the power module for at least 3s. When the number of module automatic recovery reaches the upper limit, the platform announces the failure and reports the failure to the crew members in the form of alarm language or lights, etc., and the crew members decide whether to start the manual recovery;

[0086] During the manual recovery process, the flight crew presses the "Left Cabinet Recovery" or "Right Cabinet Recovery" resilient button and holds it down for at least 1 s (to avoid accidental misoperation), restarting all functional modules in the cabinet except the power module.

[0087] The GPM core software must manage the following counters:

[0088] 1) Partition Reset Counter:

[0089] — The partition reset counter associated with each partition counts the number of partition resets caused by health monitoring, typically due to failure detection at the partition level.

[0090] — The maximum value of the partition reset counters for all partitions must be 3.

[0091] — When the partition reset counter reaches the maximum value, the partition must be set to IDLE.

[0092] — The partition reset counter must be set to 0 when the following conditions are met:

[0093] If the security test is successfully passed;

[0094] Or after a module is manually reset (through the GPM manual reset signal);

[0095] Or after a partition is manually reset, through an application reset

[0096] 2) Module Reset Counter:

[0097] — The module reset counter that counts the number of times a module is automatically reset (= the number of times the module is restarted due to an error, but this error does not include AFDX end system errors).

[0098] — The maximum value of the module reset counter is 3.

[0099] — When the module reset counter reaches the maximum value. The module must transition to:

[0100] Data Loading (PASSIVE-DL) mode if the previous mode was Normal Operation (OPS) mode;

[0101] Halt (HALT) mode if the previous mode was PASSIVE-DL mode;

[0102] — The module reset calculation must be set to 0 when:

[0103] After the security test passes,

[0104] Or after a module is manually reset;

[0105] 3) AFDX Reset Counter:

[0106] — The AFDX reset counter can calculate the number of times the module automatically restarts caused by the AFDX end system (E / S).

[0107] — The maximum value of the AFDX reset counter must be 3;

[0108] — When the AFDX reset counter reaches the maximum value, the AFDX end system must be deactivated;

[0109] — The AFDX reset counter must be set to 0 when:

[0110] After the safety test passes,

[0111] Or after the module is manually reset (by GPM reset).

[0112] 4. Advantages

[0113] 1) By combining hierarchical and classified automatic recovery and manual recovery, the availability of the system is maximally enhanced and the safety is improved;

[0114] 2) By means of partition restart and module restart, the recovery is restricted within a certain area to ensure the isolation between partitions;

[0115] 3) Restrict the number of recoveries to avoid infinite restarts from increasing the workload of flight crew.

Claims

1. An IMA recovery method compliant with AC 20-170, characterized in that, Including: Step 1: Trigger the automatic recovery functions of different levels and different module types according to the fault classification. The fault classification includes: resident application faults, hardware module resource faults, and platform resource faults. Step 1 specifically includes: Step 11: When only resident application faults exist, perform resident application partition-level recovery; Step 12: When there are no platform resource faults and there are hardware module resource faults, perform module-level recovery; Step 13: When there are platform resource faults, perform platform-level recovery. The module-level recovery in Step 12 specifically includes: obtaining the restart count of the currently faulty hardware module; comparing the restart count with the configuration data of module fault management; when the restart count is less than the limit count, initiate a soft reset of the currently faulty hardware module for module restart; if the restart count exceeds the limit count, report module failure information to the platform and suspend the currently faulty hardware module. The module failure information includes: module ID, fault type. Step 2: If the automatic recovery function fails to eliminate the faults of the resident application or the hardware module, and the security level of the functions related to the faulty resident application or hardware module is high, then report the current fault to the flight crew in the cockpit. Step 3: Receive the external trigger from the flight crew to complete the IMA recovery.

2. The method according to claim 1, wherein Reporting the current fault to the flight crew in the cockpit specifically includes: Reporting the current fault to the flight crew in the cockpit through alarm messages, voice alarms, or warning lights.

3. The method according to claim 2, wherein The resident application partition-level recovery in Step 11 specifically includes: When there is a resident application fault, independently start the partition recovery operation for each partition.

4. The method according to claim 3, characterized in that, The platform-level recovery in Step 13 specifically includes: Receiving all module failure information within the platform; Comparing the module ID in each module failure information with the configuration data of platform fault management respectively to determine the security level of each faulty module; In the case of faulty hardware modules with a high security level, comparing the restart count of the platform for the faulty hardware modules with a high security level with the configuration data of platform fault management; When the restart count is less than the limit count, recover the faulty hardware module with a high security level through platform operations; if the restart count exceeds the limit count, report the current fault to the flight crew in the cockpit.

5. The method according to claim 4, wherein Recovering the faulty hardware module with a high security level through platform operations specifically includes: Inputting a command of "cut off the power supply of the faulty hardware module with a high security level for a predetermined time" to the power module for module cold restart.

6. The method according to claim 5, wherein The predetermined time is 3 seconds.

Images