A Functional Model-Based Method and System for Fault Testing and Diagnosis of Airborne Systems

Abstract

This invention provides a method and system for airborne system fault testing and diagnosis requirements analysis based on a functional model. The method includes the following steps: S1, constructing a system functional model and conducting system functional hazard analysis or functional failure mode impact analysis; S2, constructing a system logical model and establishing the functional failure logical relationships between the system, subsystems, and equipment; S3, formulating initial configuration and adjustment principles for system functional failure diagnostic elements; S4, configuring and decomposing initial system functional failure test requirements; S5, conducting feasibility analysis and adjustment for functional failure testing; S6, generating a model-based system fault testing and diagnosis analysis database. This invention uses a system functional model and a fault logic model as its core, decomposing system functional failure testing and diagnosis requirements to the equipment level and supporting model-based feasibility analysis.

Description

Technical Field

[0001] This invention relates to the field of airborne fault diagnosis, and specifically to a method and system for analyzing the requirements of airborne system fault testing and diagnosis based on a functional model. Background Technology

[0002] The trend towards digitalization, intelligence, and integration of aircraft avionics systems has brought a series of challenges, especially in the testing and diagnosis of these systems. Model-based requirements analysis for airborne system fault testing and diagnosis is a model-based approach that can balance the safety and maintainability requirements of airborne systems. It analyzes the functional fault testing requirements of airborne systems, subsystems, and equipment, supporting systematic functional fault testing and diagnosis requirements analysis during the design phase and avoiding the under-design or over-design problems associated with traditional experience-based analysis.

[0003] Currently, the testing and diagnostic requirements for aircraft avionics systems primarily focus on quantitative indicators such as fault detection rate, fault isolation rate, and false alarm rate, supplemented by qualitative requirements such as some testability design principles. However, they do not address specific functional faults of the airborne product itself. Therefore, the design and analysis of diagnostic solutions for airborne systems mainly focus on the overall planning and design of the testing and diagnostic architecture, various BITs, condition monitoring, integrated diagnostics, and external testing elements, without addressing specific fault detection and isolation designs. A significant reason for this problem is the lack of an easily implementable method for analyzing the testing and diagnostic requirements of airborne systems in engineering applications. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention aims to provide a method and system for airborne system fault testing and diagnosis requirements analysis based on a functional model. The method includes constructing a system functional model and conducting system functional hazard analysis or functional failure mode impact analysis; constructing a system logical model; establishing the functional failure logical relationships between the system, subsystems, and equipment; formulating initial configuration and adjustment principles for system functional failures; configuring and decomposing initial system functional failure test requirements; conducting feasibility analysis and adjustment for functional failure testing; and generating a model-based system fault testing and diagnosis analysis database. This invention uses the system functional model and fault logic model as its core, decomposes the system functional failure testing and diagnosis requirements to the equipment level, supports model-based feasibility analysis, and provides a corresponding analysis system capable of quickly generating the system fault testing and diagnosis analysis database based on feasibility analysis.

[0005] Specifically, the present invention provides a method for fault testing and diagnosis requirements analysis of airborne systems based on a functional model, which includes the following steps:

[0006] S1. Construct a system functional model and conduct system functional hazard analysis or functional failure mode impact analysis, which includes the following sub-steps:

[0007] S1. Construct a system functional model and conduct a system functional failure mode and effect analysis, which includes the following sub-steps:

[0008] S11. Construct the system functional model. The system functional model expression is as follows:

[0009] Function(system.name.function)=list(function_1,...,function_m)

[0010] Where Function(system.name.function) represents the complete set of system functions, function_1 represents the first function, function_m represents the m-th function, and m is a positive integer; list() represents the complete set;

[0011] S12. Based on the system functional model, conduct functional failure mode impact analysis to form a complete set of system functional failures containing multiple functional failure sets. The expression for the functional failure set is as follows:

[0012] Failure(system.name.fuction_m)

[0013] =list(failure_mode_1,...,failure_mode_s)

[0014] Where Failure(system.name.fuction_m) represents the set of failures for the m-th function of the system, failure_mode_1 represents the first failure mode, failure_mode_s represents the s-th failure mode, and s is a positive integer.

[0015] S13. Assign a safety impact level or severity level to each system functional failure. Safety impact level B includes catastrophic (CAT), hazardous (HAZ), severe (MAJ), minor (MIN), and no safety impact (NSE), denoted as B=CAT, B=HAZ, B=MAJ, B=MIN, and B=NSE, respectively. Severity impact level A includes Class I, Class II, Class III, and Class IV, denoted as A=1, A=2, A=3, and A=4, respectively. Assign a safety impact level or severity level to each system functional failure according to the failure level table and output the failure impact D of each functional failure. When the failure impact causes minor injury to personnel, D is set to 1; otherwise, D is set to 0.

[0016] S2. Construct a system logical model based on the system functional model, and establish the functional fault logic relationships between the system, subsystems, and equipment. This includes the following sub-steps:

[0017] S21. Establish the functional fault logic relationship between the system and subsystems by mapping the system functional fault states to the subsystem functional fault states; the mapping relationship Logic(system.name.fuction_m.failure_mode_s) between the s-th fault mode of the m-th function of the system and the functional fault mode of the subsystem is expressed as follows:

[0018] Logic(system.name.fuction_m.failure_mode_s)

[0019] =dom(subsystem.name.fuction_1.failure_mode_1)OR

[0020] dom(subsystem.name.fuction_h.failure_mode_f)

[0021] Where dom(subsystem.name.fuction_1.failure_mode_1) represents the first failure mode of the first function in the subsystem; OR represents a logical OR operation.

[0022] dom(subsystem.name.fuction_h.failure_mode_j) represents the j-th failure mode of the h-th function in the subsystem; h and j are positive integers.

[0023] S22. Establish the functional fault logic relationship between the subsystem functional fault state and the subsystem output port state through fault tree, supporting logical AND, OR, and voting gate relationships between output port states; the mapping relationship between the j-th fault mode of the h-th function of the subsystem and the subsystem output port state is expressed as follows:

[0024] Log ic(subsystem.name.fuction_h.failure_mode_j)

[0025] =dom(subsystem.name.outport_1.state_1)OR

[0026] dom(subsystem.name.outport_k.state_n)

[0027] Where dom(subsystem.name.outport_1.state_1) represents the first state of the first output port of the subsystem; dom(subsystem.name.outport_k.state_n) represents the nth state of the kth output port of the subsystem; k and n are both positive integers;

[0028] S23. Establish the fault logic relationship between the device output port state and the subsystem output port state through the fault tree; the expression for the fault logic relationship Logic(subsystem.name.outport_k.state_n) between the nth state of the kth output port of the subsystem and the device output port state is as follows:

[0029] Log ic(subsystem.name.outport_k.state_n)

[0030] =dom(equipment.name.outport_1.state_1)OR

[0031] dom(equipment.name.outport_p.state_q)

[0032] Where dom(equipment.name.outport_1.state_1) represents the first state of the first output port of the device; dom(equipment.name.outport_p.state_q) represents the q-th state of the p-th output port of the device; p and q are both positive integers;

[0033] S24. Establish the functional fault logic relationships between the device's functional fault states, the device's input port states, and the device's output port states using a fault tree; establish the functional fault logic relationships between the q-th state of the p-th output port, the device's input port states, and the device's fault modes.

[0034] The expression for Logic(equipment.name.outport_p.state_q) is as follows:

[0035] Logic(equipment.name.outport_p.state_q)

[0036] =dom(equipment.name.inputport_1.state_1)OR

[0037] dom(equipment.name.inputport_x.state_y)OR

[0038] dom(equipment.name.function_l.failure_mode_z)

[0039] Where dom(equipment.name.inputport_1.state_1) represents the first state of the first input port of the device; dom(equipment.name.inputport_x.state_y) represents the y-th state of the x-th input port of the device;

[0040] dom(equipment.name.function_l.failure_mode_z) represents the z-th failure mode of the first function, where x, y, l, and z are all positive integers;

[0041] S3. Construct an initial configuration model for the diagnostic elements of system functional failures and determine the adjustment rules, specifically including the following sub-steps:

[0042] S31. Construct the initial configuration model for diagnostic elements as follows:

[0043]

[0044] Where C is the initial configuration model for diagnostic elements, c1 and c 21 Represents the power-on bit, cycle bit, and start-up bit, c 22 c3 represents the power-on bit and the startup bit;

[0045] S32. Determine adjustment rules based on safety impact level B, severity level A, and the equipment type corresponding to system functional failures;

[0046] S4. Based on the initial configuration and adjustment principles of the diagnostic elements for system functional faults determined in step S3, configure and decompose the initial test requirements for system functional faults.

[0047] S5. Feasibility analysis and adjustment of functional failure testing;

[0048] S6. Based on the feasibility analysis in step S5, generate and output the system fault test diagnosis analysis database.

[0049] Preferably, step S3 specifically includes the following sub-steps:

[0050] S31. Based on the complete set of functional faults, formulate the initial configuration of diagnostic elements for system functional faults;

[0051] S32. Formulate configuration adjustment principles for system functional faults based on the complete set of functional faults.

[0052] Preferably, step S4 specifically includes the following sub-steps:

[0053] S41. Based on the initial configuration principles of the system functional fault diagnosis elements established in step S3, and the severity level or safety impact level of the system functional fault, generate the initial test requirements for the system functional fault.

[0054] S42. Based on the functional fault logic model established in step S2, the initial test requirements for system functional faults formed in S41 are passed from the top event of the fault tree of system functional faults to the bottom event layer by layer along the fault tree to form the initial test requirements for subsystem functional faults and equipment functional faults.

[0055] S43. When a requirement is passed down from the top event of the fault tree of a system functional failure, configure the handling method of AND gates and voting gates, including passing it down directly or not passing it down.

[0056] Preferably, step S32 specifically includes the following sub-steps:

[0057] S321, Based on device type, classify c1 and c 21 Adjustments were made: when the equipment type is electronic product, c1 was adjusted to system BIT; when the equipment type is electromechanical product, c1 was adjusted to condition monitoring.

[0058] S322, c 22 And adjust c3 to determine whether the power-on BIT and start-up BIT can work. If the power-on BIT and start-up BIT cannot be implemented but the periodic BIT can be implemented, then adjust to the periodic BIT. If the power-on BIT, start-up BIT and periodic BIT cannot be implemented, then replace them in the following order: system BIT, status monitoring, manual testing, automated testing equipment and manual inspection.

[0059] Preferably, step S5 specifically includes the following sub-steps:

[0060] S511. Test points are configured on the output ports of the device or subsystem;

[0061] S512: A single test point can be configured with multiple tests;

[0062] S513, Test the status associated with the connected output port;

[0063] S514. Test information includes test name, test method, test cost, test time, test implementation unit, and design constraints.

[0064] Preferably, step S51 specifically includes the following sub-steps:

[0065] S511. Test points are configured on the output ports of the device or subsystem;

[0066] S512: A single test point can be configured with multiple tests;

[0067] S513, Test the status associated with the connected output port;

[0068] S514. Test information includes test name, test method, test cost, test time, test implementation unit, and design constraints.

[0069] Preferably, step S52 specifically includes the following sub-steps:

[0070] Step S5 specifically includes the following sub-steps:

[0071] S521 Fault coverage analysis: Taking the tests configured in the fault logic model in step S51 as the main analysis object, analyze whether the initial requirements formed in S4 are met.

[0072] S522, Design Constraint Analysis: From the perspective of system hardware and software design, analyze the engineering feasibility of the test.

[0073] S523. Benefit Analysis: Based on meeting the fault coverage requirements, analyze the benefits of the test plan; the test model is as follows:

[0074] C z =C D +NC P +C aux +ZC maux +(1-P F )N o λ PE T o Z(M MHi +M MHrp C MH +

[0075] P F N o λ PE T o ZM MHrp C MH +P o N o λ PE T o ZC FD +

[0076] N p λ I TZ(C IFMA +TIFMP C MH / T PM )

[0077] In the formula, λ I To test the failure rate of the equipment; λ PE The total failure rate of all hardware components used in the test for each system or device; A is the average ambiguity of the test scheme; C Z The cost of the test plan; C aux The total cost of any auxiliary testing or maintenance equipment other than the testing equipment required to ensure or complete the basic testing work; C maux C. The total cost of auxiliary testing or repair equipment required for annual maintenance; u This refers to the development cost of the test equipment or circuits in the test plan. If the test plan does not use newly developed equipment, this cost is zero; C P C represents the average production cost of the test equipment or circuits in the test plan. MH The cost per repair hour; C FD To determine the average cost required to identify the fault that has occurred; C IFMA The necessary components for repairing a faulty test device or circuit in a test program; M MHi M is the average repair man-hours required for fault isolation or detection by the test plan. MHs The average repair time required to completely isolate a fault; M MHrp To determine the average maintenance time required to isolate an LRU using manual fault diagnosis when the test plan cannot achieve complete isolation; M MHPm N represents the average maintenance man-hours for preventative maintenance activities on test equipment in each test plan; N is the number of test equipment units produced or the number of devices containing test circuits; N F N represents the average number of test devices used in the field at any given time, or the average number of devices containing test circuits; o P represents the number of systems or devices used. F P represents the proportion of LRU failures in a system that cannot be isolated by applicable test equipment. o The percentage of undetected system or equipment faults; T represents the number of operating hours per year per test device; T IFMP The average total man-hours required to repair a faulty test device; T o The working hours of each system or device directly serving the test equipment or circuit in the annual test plan; T PM Z represents the working hours between two preventive maintenance procedures for the test equipment or circuit in the test plan; Z represents the expected service life of the system or equipment.

[0078] S524. Fault Isolation Analysis: Based on meeting the fault coverage requirements, this section analyzes the feasibility of adding tests to improve fault isolation capabilities for fault isolation between devices.

[0079] Preferably, the specific operation process of step S6 is as follows: a model-based system fault test diagnosis and analysis database, including an initial decomposition table of test requirements, a fault coverage analysis table, and a subsystem / equipment test requirement table.

[0080] On the other hand, the present invention also provides a model-based airborne system fault test and diagnosis requirement analysis system, which includes a system functional model construction unit, a system fault logic model construction unit, a diagnostic element initial configuration and adjustment principle formulation unit, a test requirement configuration and decomposition unit, a functional fault test feasibility analysis and adjustment unit, and a system fault test and diagnosis analysis database generation unit.

[0081] The system functional model construction unit is used to construct the system functional model and conduct system functional hazard analysis or functional failure mode impact analysis;

[0082] The system fault logic model construction unit is used to construct the system logic model and establish the functional fault logic relationships of the system, subsystems and equipment.

[0083] The initial configuration and adjustment principle unit for diagnostic elements is used to formulate the initial configuration and adjustment principles for diagnostic elements of system functional failures;

[0084] The test requirement configuration and decomposition unit is used to configure and decompose the initial test requirements for system functional failures.

[0085] The functional failure test feasibility analysis and adjustment unit is used to perform feasibility analysis and adjustment for functional failure tests.

[0086] The system fault test diagnosis and analysis database generation unit is used to generate a model-based system fault test diagnosis and analysis database.

[0087] Preferably, the initial configuration model of diagnostic elements constructed by the test requirement configuration and decomposition unit is as follows:

[0088]

[0089] Where C is the initial configuration model for diagnostic elements, c1 and c 21 Represents the power-on bit, cycle bit, and start-up bit, c 22 c3 represents the power-on bit and the startup bit.

[0090] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0091] (1) This invention provides a method for analyzing the requirements for airborne system fault testing and diagnosis based on a functional model. This method includes constructing a system functional model and conducting system functional hazard analysis or functional failure mode impact analysis; constructing a system logical model; establishing the functional failure logical relationships between the system, subsystems, and equipment; formulating initial configuration and adjustment principles for system functional failures; configuring and decomposing initial test requirements for system functional failures; conducting feasibility analysis and adjustment for functional failure testing; and generating a model-based system fault testing and diagnosis analysis database. This invention uses the system functional model and fault logic model as its core, decomposes the test and diagnosis requirements for system functional failures to the equipment level, and supports model-based feasibility analysis.

[0092] (2) The present invention provides an airborne system fault test and diagnosis requirement analysis system based on a functional model. The various units of the system communicate and interact with each other. Based on the system functional model, the fault test and diagnosis requirement analysis is performed, which can quickly obtain a feasibility analysis and generate a system fault test and diagnosis analysis database. Attached Figure Description

[0093] Figure 1 This invention provides a model-based requirements analysis process for airborne system fault testing and diagnosis.

[0094] Figure 2 This is an example of initial requirement decomposition in an embodiment of the present invention;

[0095] Figure 3 This is a block diagram of the fault testing and diagnosis requirements analysis system of the present invention. Detailed Implementation

[0096] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.

[0097] This paper provides a method for analyzing the requirements of airborne system fault testing and diagnosis based on a functional model, such as... Figure 1-2 As shown, it includes the following steps:

[0098] S1. Construct a system functional model and conduct system functional hazard analysis or functional failure mode impact analysis, which includes the following sub-steps:

[0099] S11. Construct the system functional model. The system functional model expression is as follows:

[0100] Function(system.name.function)=list(function_1,...,function_m)

[0101] In this context, Function(system.name.function) represents the complete set of system functions, function_1 represents the first function, function_m represents the mth function, and m is a positive integer; list() represents the complete set.

[0102] S12. Conduct functional failure mode-effect analysis or functional hazard analysis based on the functional model, prioritizing functional failure mode-effect analysis to form a complete set of system functional failures. The expression for the complete set of system functional failures is as follows:

[0103] Failure(system.name.fuction_m)

[0104] =list(failure_mode_1,...,failure_mode_s)

[0105] Where Failure(system.name.fuction_m) represents the set of failures for the m-th function of the system, failure_mode_1 represents the first failure mode, failure_mode_s represents the s-th failure mode, and s is a positive integer.

[0106] S13. Assign a safety impact level or severity level to each system functional failure. Safety impact level B includes catastrophic (CAT), hazardous (HAZ), severe (MAJ), minor (MIN), and no safety impact (NSE), denoted as B=CAT, B=HAZ, B=MAJ, B=MIN, and B=NSE, respectively. Severity impact level A includes Class I, Class II, Class III, and Class IV, denoted as A=1, A=2, A=3, and A=4, respectively. Assign a safety impact level or severity level to each system functional failure and output the failure impact D for each failure. When the failure impact causes minor injury to personnel, D is set to 1; otherwise, D is set to 0.

[0107] S2. Construct a system logical model based on the system functional model, and establish the functional fault logic relationships between the system, subsystems, and equipment. This includes the following sub-steps:

[0108] S21. Establish the functional fault logic relationship between the system and subsystems by mapping the system functional fault states to the subsystem functional fault states; the mapping relationship Logic(system.name.fuction_m.failure_mode_s) between the s-th fault mode of the m-th function of the system and the functional fault mode of the subsystem is expressed as follows:

[0109] Logic(system.name.fuction_m.failure_mode_s)

[0110] =dom(subsystem.name.fuction_1.failure_mode_1)OR

[0111] dom(subsystem.name.fuction_h.failure_mode_j)

[0112] Where dom(subsystem.name.fuction_1.failure_mode_1) represents the first failure mode of the first function in the subsystem; OR represents a logical OR operation.

[0113] dom(subsystem.name.fuction_h.failure_mode_j) represents the j-th failure mode of the h-th function in the subsystem; h and j are positive integers.

[0114] S22. Establish the functional fault logic relationship between the subsystem functional fault state and the subsystem output port state through fault tree, supporting logical AND, OR, and voting gate relationships between output port states; mapping relationship between the j-th fault mode of the h-th function of the subsystem and the subsystem output port state.

[0115] The logic(subsystem.name.fuction_h.failure_mode_j) is expressed as follows:

[0116] Logic(subsystem.name.fuction_h.failure_mode_j)

[0117] =dom(subsystem.name.outport_1.state_1)OR

[0118] dom(subsystem.name.outport_k.state_n)

[0119] Where dom(subsystem.name.outport_1.state_1) represents the first state of the first output port of the subsystem; dom(subsystem.name.outport_k.state_n) represents the nth state of the kth output port of the subsystem; k and n are both positive integers.

[0120] S23. Establish the fault logic relationship between the device output port state and the subsystem output port state through the fault tree; the expression for the fault logic relationship Logic(subsystem.name.outport_k.state_n) between the nth state of the kth output port of the subsystem and the device output port state is as follows:

[0121] Logic(subsystem.name.outport_k.state_n)

[0122] =dom(equipment.name.outport_1.state_1)OR

[0123] dom(equipment.name.outport_p.state_q)

[0124] Where dom(equipment.name.outport_1.state_1) represents the first state of the first output port of the device; dom(equipment.name.outport_p.state_q) represents the qth state of the pth output port of the device; p and q are both positive integers.

[0125] S24. Establish the functional fault logic relationships between the device's functional fault states, the device's input port states, and the device's output port states using a fault tree; establish the functional fault logic relationships between the q-th state of the p-th output port, the device's input port states, and the device's fault modes.

[0126] The expression for Logic(equipment.name.outport_p.state_q) is as follows:

[0127] Logic(equipment.name.outport_p.state_q)

[0128] =dom(equipment.name.inputport_1.state_1)OR

[0129] dom(equipment.name.inputport_x.state_y)OR

[0130] dom(equipment.name.function_l.failure_mode_z)

[0131] Where dom(equipment.name.inputport_1.state_1) represents the first state of the first input port of the device; dom(equipment.name.inputport_x.state_y) represents the y-th state of the x-th input port of the device;

[0132] dom(equipment.name.function_l.failure_mode_z) represents the z-th failure mode of the l-th function, where x, y, l, and z are all positive integers.

[0133] S3. Establish initial configuration and adjustment principles for diagnostic elements of system functional failures; specifically including the following sub-steps:

[0134] S31, S31, The initial configuration model for diagnostic elements is constructed as follows:

[0135]

[0136] Where C is the initial configuration model for diagnostic elements, c1 and c 21 Represents the power-on bit, cycle bit, and start-up bit, c 22 c3 represents the power-on bit and the startup bit;

[0137] When a system function fails with a severity level of I or II, or a safety impact level of CAT or HAZ, the diagnostic elements in the initial configuration include the power-on BIT, the cycle BIT, and the startup BIT.

[0138] When a system function failure occurs at a severity level of Class III or a safety impact level of MAJ, and the failure impact includes "causing minor injury to personnel", the diagnostic elements of the initial configuration include the power-on BIT, the cycle BIT, and the startup BIT; otherwise, the diagnostic elements of the initial configuration include the power-on BIT and the startup BIT.

[0139] When a system function failure occurs at a severity level of IV or a safety impact level of MIN or NSE, the diagnostic elements for the initial configuration include the power-on BIT and the startup BIT.

[0140] S32. Principles for constructing adjustments, including:

[0141] S321, Based on device type, classify c1 and c 21 Adjustments were made: when the equipment type is electronic product, c1 was adjusted to system BIT; when the equipment type is electromechanical product, c1 was adjusted to condition monitoring.

[0142] S322, c 22And adjust c3 to determine whether the power-on BIT and start-up BIT can work. If the power-on BIT and start-up BIT cannot be implemented but the periodic BIT can be implemented, then adjust to the periodic BIT. If the power-on BIT, start-up BIT and periodic BIT cannot be implemented, then replace them in the following order: system BIT, status monitoring, manual testing, automated testing equipment and manual inspection.

[0143] When a system functional failure occurs at severity levels I and II, or safety impact levels CAT and HAZ, for electronic products, diagnostic elements should be configured strictly according to the initial requirements; if the product's own BIT cannot be implemented, it can be implemented by the system BIT; for electromechanical products, if BIT cannot be implemented, condition monitoring can be used as a substitute.

[0144] When a system malfunction occurs at a severity level of Class III or a safety impact level of MAJ, if the malfunction's impact includes "causing minor injury to personnel," the adjustment principle shall be implemented according to S321; otherwise, the adjustment principle shall be implemented according to S323.

[0145] When a system functional failure occurs at a severity level of IV or a safety impact level of MIN or NSE, and power-on BIT and maintenance BIT are not feasible, but periodic BIT is feasible, the system should be adjusted to periodic BIT. If BIT is not feasible, the following steps should be considered in sequence: system BIT → condition monitoring → manual testing (direct observation) → automated testing equipment → manual testing (inspection and testing). For functional failures that cannot be achieved through BIT / condition monitoring but can be directly observed by humans in a closed loop, manual testing (direct observation) may be considered, and compensation measures should be in place to ensure normal flight operation.

[0146] S4. Initial System Functional Fault Test Requirements Configuration and Decomposition; specifically including the following sub-steps:

[0147] S41. Based on the initial configuration principles of system functional fault diagnosis elements established in S3, and the severity level or safety impact level of system functional faults, automatically generate the initial test requirements for system functional faults.

[0148] S42. Based on the system logic model established in S2, the initial test requirements for system functional faults formed in S41 are passed from the top event of the fault tree of system functional faults to the bottom event layer by layer along the fault tree, forming the initial test requirements for subsystem functional faults and equipment functional faults.

[0149] S43. When a requirement is passed down from the top event of the fault tree of a system functional failure, configure the handling methods of AND gates and voting gates, including passing it down directly (resulting in a more stringent requirement) or not passing it down.

[0150] S5. Feasibility analysis and adjustment of functional failure testing; specifically including the following sub-steps:

[0151] S51. In the fault logic model formed in S2, design the test diagnosis for system functional faults, and configure the test points and test information for functional faults; wherein the test points and test information have the following characteristics:

[0152] S511. Test points are configured on the output ports of the device or subsystem.

[0153] S512: Multiple tests can be configured for one test point.

[0154] S513, Test the status of the connected output port.

[0155] S514. Test information includes test name, test method, test cost, test time, test implementation unit, design constraints, etc.

[0156] S52. Feasibility analysis includes fault coverage analysis, design constraint analysis, and fault isolation analysis; specifically, it includes the following sub-steps:

[0157] S521, Fault Coverage Analysis, focuses on the tests configured in the fault logic model in step S51, analyzing whether the initial requirements formed in S4 are met. In fault coverage analysis, the principle of test diagnostic element coverage, based on the complete consistency of test diagnostic elements, also includes the adjustment principle of diagnostic elements formed in step S32. For example, the cycle BIT of electromechanical products can be covered by condition monitoring, and the cycle BIT of electronic products can be covered by the system BIT. The specific logic of fault coverage analysis is as follows: If the top event of a system functional fault can be directly covered by the tests in the model, then the test requirements for that functional fault are met; if the top event of a system functional fault is not directly covered by the tests in the model, then it is analyzed whether the subsystem functional faults in the fault tree where the top event is located can be covered by the tests in the model. If they can be covered, then the test requirements for that system functional fault (top event) are met; if the subsystem functional fault is not directly covered by the tests in the model, then it is analyzed whether the equipment functional faults in the fault tree where the subsystem functional fault is located can be covered by the tests in the model. If they can be covered, then the test requirements for that subsystem functional fault (intermediate event) are met, and further analysis is conducted to determine whether the test requirements for that system functional fault (top event) are met.

[0158] S522, Design Constraint Analysis: From the perspective of system hardware and software design, analyze the design schemes related to testing and diagnosis, such as sensor configuration, data processing capabilities, BIT judgment logic, weight, size, reliability, and technology maturity, and evaluate the engineering feasibility of the test.

[0159] S523. Benefit Analysis: Based on meeting the fault coverage requirements, analyze the benefits of the test plan.

[0160] The cost of a test program includes: research and development costs, production costs, the total cost of any auxiliary testing or maintenance equipment other than that required to ensure and complete the basic testing work, the total cost of auxiliary testing or maintenance equipment required for maintenance during the life cycle, the cost of using testing to isolate faults, the cost of isolating faults by methods other than testing, the cost of identifying undetected faults, the cost of repairing test equipment or circuits involved in the test program, and the average preventive maintenance cost of test equipment.

[0161] The specific calculation and testing model is as follows:

[0162] C z =C D +NC P +C aux +ZC maux +(1-P F )N o λ PE T o Z(M MHi +M MHrp C MH +

[0163] P F N o λ PE T o ZM MHrp C MH +P o N o λ PE T o ZC FD +

[0164] N p λ I TZ(C IFMA +T IFMP C MH / T PM )

[0165] In the formula, λ I To test the failure rate of the equipment; λ PE The total failure rate of all hardware components used in the test for each system or device; A is the average ambiguity of the test scheme; C Z The cost of the test plan; C aux The total cost of any auxiliary testing or maintenance equipment other than the testing equipment required to ensure or complete the basic testing work; C maux C. The total cost of auxiliary testing or repair equipment required for annual maintenance; uThis refers to the development cost of the test equipment or circuits in the test plan. If the test plan does not use newly developed equipment, this cost is zero; C P C represents the average production cost of the test equipment or circuits in the test plan. MH The cost per repair hour; C FD To determine the average cost required to identify the fault that has occurred; C IFMA The necessary components for repairing a faulty test device or circuit in a test program; M MHi M is the average repair man-hours required for fault isolation or detection by the test plan. MHs The average repair time required to completely isolate a fault; M MHrp To determine the average maintenance time required to isolate an LRU using manual fault diagnosis when the test plan cannot achieve complete isolation; M MHPm N represents the average maintenance man-hours for preventative maintenance activities on test equipment in each test plan; N is the number of test equipment units produced or the number of devices containing test circuits; N F N represents the average number of test devices used in the field at any given time, or the average number of devices containing test circuits; o P represents the number of systems or devices used. F P represents the proportion of LRU failures in a system that cannot be isolated by applicable test equipment. o The percentage of undetected system or equipment faults; T represents the number of operating hours per year per test device; T IFMP The average total man-hours required to repair a faulty test device; T o The working hours of each system or device directly serving the test equipment or circuit in the annual test plan; T PM Z represents the working hours between two preventive maintenance procedures for the test equipment or circuit in the test plan; Z represents the expected service life of the system or equipment.

[0166] S524. Fault Isolation Analysis: Based on meeting the fault coverage requirements, this analysis examines feasible solutions for improving fault isolation capabilities by adding tests (e.g., electric valves in electromechanical systems do not have data processing capabilities, but can be functionally tested through the system BIT of other systems, which can be completed by designing only in the software), providing decision-making information for the formation of final test requirements.

[0167] S53. Adjustment of Test Requirements. Based on the combined analysis of S521 (fault coverage), S522 (design constraint analysis), S523 (cost-benefit analysis), and S524 (fault isolation analysis), the initial test requirements are adjusted according to S32 and configured into the test information. Steps S52 and S53 are a continuous process of analysis and iteration.

[0168] S6. Generate a model-based system fault test diagnosis and analysis database. The specific steps are as follows: The model-based system fault test diagnosis and analysis database includes an initial test requirement decomposition table, a fault coverage analysis table, and a subsystem / equipment test requirement table. The initial test requirement decomposition table, shown in Table 1, includes system-level, subsystem-level, and equipment-level functional fault modes and initial test requirements; the fault coverage analysis table, shown in Table 2, includes system-level, subsystem-level, and equipment-level functional fault modes, test requirements, requirement fulfillment status, test names, and types. Requirement fulfillment status includes three types: direct fulfillment, lower-level fulfillment, and non-fulfillment. Test names and types are derived from test information in the test points; the subsystem / equipment test requirement table, shown in Table 3, summarizes the test information in the model to form the subsystem / equipment test requirement table.

[0169] Table 1 Initial Requirements Breakdown Table for Functional Fault Testing

[0170]

[0171] Table 2 Functional Fault Coverage Analysis Table

[0172]

[0173] Table 3 Subsystem / Equipment Testing Requirements

[0174]

[0175] On the other hand, the present invention also provides a model-based airborne system fault testing and diagnosis requirements analysis system, such as... Figure 3 As shown, it includes a system functional model construction unit 1, a system fault logic model construction unit 2, a diagnostic element initial configuration and adjustment principle formulation unit 3, a test requirement configuration and decomposition unit 4, a functional fault test feasibility analysis and adjustment unit 5, and a system fault test diagnostic analysis database generation unit 6. The system functional model construction unit 1 is used to construct the system functional model and conduct system functional hazard analysis or functional fault mode impact analysis. The system fault logic model construction unit 2 is used to construct the system logic model and establish the functional fault logic relationships of the system, subsystems, and equipment. The diagnostic element initial configuration and adjustment principle unit 3 is used to formulate the initial configuration and adjustment principles for system functional fault diagnostic elements. The test requirement configuration and decomposition unit 4 is used to perform initial test requirement configuration and decomposition for system functional faults. The functional fault test feasibility analysis and adjustment unit 5 is used to perform feasibility analysis and adjustment for functional fault tests. The system fault test diagnostic analysis database generation unit 6 is used to generate a model-based system fault test diagnostic analysis database.

[0176] In summary, the method of this invention can establish the functional fault logic relationships of the system, subsystems, and equipment; formulate the initial configuration and adjustment principles for system functional faults; configure and decompose the initial test requirements for system functional faults; conduct feasibility analysis and adjustment of functional fault testing; and generate a model-based system fault test diagnosis and analysis database. This invention uses a system functional model and a fault logic model as its core, decomposes the test diagnosis requirements for system functional faults to the equipment level, and supports model-based feasibility analysis.

[0177] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for fault testing and diagnosis requirements analysis of airborne systems based on functional models, characterized in that: It includes the following steps: S1. Construct a system functional model and conduct a system functional failure mode and effect analysis, which includes the following sub-steps: S11. Construct the system functional model. The system functional model expression is as follows: ； in, Indicates the complete set of system functions. This indicates the first function. This represents the m-th function, where m is a positive integer; Indicates the complete collection; S12. Based on the system functional model, conduct functional failure mode impact analysis to form a complete set of system functional failures containing multiple functional failure sets. The expression for the functional failure set is as follows: ； in, This represents the fault set of the m-th function of the system. This indicates the first fault mode. This represents the s-th fault mode, where s is a positive integer; S13. Assign a safety impact level or severity level to each system functional failure; where safety impact level B includes catastrophic (CAT), hazardous (HAZ), severe (MAJ), minor (MIN), and no safety impact (NSE), denoted as follows: Severity impact level A includes categories I, II, III, and IV, denoted as follows: Assign a safety impact level or severity level to each system functional failure and output the failure impact D of each functional failure. When the failure impact causes minor injury to personnel, D is set to 1; otherwise, D is set to 0. S2. Construct a system logical model based on the system functional model, and establish the functional fault logic relationships between the system, subsystems, and equipment. This includes the following sub-steps: S21. Establish the functional fault logic relationship between the system and subsystems by mapping the system functional fault states to the subsystem functional fault states; establish the mapping relationship between the s-th fault mode of the m-th function of the system and the functional fault modes of the subsystem. The expression is as follows: ； in, This represents the first fault mode of the first function in the subsystem. Represents a logical OR operation; This represents the j-th failure mode of the h-th function in the subsystem; h and j are both positive integers. S22. Establish the functional fault logic relationship between the subsystem functional fault state and the subsystem output port state through fault tree, supporting logical AND, OR, and voting gate logic relationships between output port states; mapping relationship between the j-th fault mode of the h-th function of the subsystem and the subsystem output port state. The expression is as follows: ； in, This indicates the first state of the first output port of the subsystem; This represents the nth state of the kth output port of the subsystem; k and n are both positive integers. S23. Establish the fault logic relationship between the device output port status and the subsystem output port status through fault tree analysis; establish the fault logic relationship between the nth state of the kth output port of the subsystem and the device output port status. The expression is as follows: ； in, This indicates the first state of the device's first output port; This represents the q-th state of the p-th output port of the device; p and q are both positive integers. S24. Establish the functional fault logic relationships between the device's functional fault states, the device's input port states, and the device's output port states using a fault tree; establish the functional fault logic relationships between the q-th state of the p-th output port, the device's input port states, and the device's fault modes. The expression is as follows: ； in, This indicates the first state of the device's first input port; This indicates the y-th state of the x-th input port of the device; This represents the z-th failure mode of the l-th function, x, y, Both z and z are positive integers; S3. Construct an initial configuration model for the diagnostic elements of system functional failures and determine the adjustment rules, specifically including the following sub-steps: S31. Construct the initial configuration model for diagnostic elements as follows: ； Where C is the initial configuration model for diagnostic elements, c1 and c 21 All represent the power-on bit, cycle bit, and start-up bit, c 22 Both c3 and c2 represent the power-on bit and the startup bit, respectively. S32. Determine adjustment rules based on safety impact level B, severity level A, and the equipment type corresponding to system functional failures; S4. Based on the initial configuration model and adjustment rules of the diagnostic elements of system functional faults determined in step S3, configure and decompose the initial test requirements for system functional faults. S5. Conduct feasibility analysis and adjustments for functional failure testing; S6. Based on the feasibility analysis in step S5, generate and output the system fault test diagnosis analysis database.

2. The method for airborne system fault testing and diagnosis requirements analysis based on functional models according to claim 1, characterized in that: Step S4 specifically includes the following sub-steps: S41. Based on the initial configuration model of system functional fault diagnosis elements formulated in step S3, and the severity level or safety impact level of system functional faults, generate the initial test requirements for system functional faults. S42. Based on the functional fault logic relationship established in step S2, the initial test requirements of the system functional fault formed in S41 are passed from the top event of the fault tree of the system functional fault to the bottom event layer by layer along the fault tree to form the initial test requirements of the subsystem functional fault and the equipment functional fault. S43. When a requirement is passed down from the top event of the fault tree of a system functional failure, configure the handling method of AND gates and voting gates, including passing it down directly or not passing it down.

3. The method for airborne system fault testing and diagnosis requirements analysis based on functional models according to claim 1, characterized in that: Step S32 specifically includes the following sub-steps: S321, Based on device type, classify c1 and c 21 Adjustments were made: when the equipment type is electronic product, c1 was adjusted to system BIT; when the equipment type is electromechanical product, c1 was adjusted to condition monitoring. S322, c 22 And adjust c3 to determine whether the power-on BIT and start-up BIT can work. If the power-on BIT and start-up BIT cannot be achieved but the periodic BIT can be achieved, then adjust to the periodic BIT. If the power-on BIT, start-up BIT and periodic BIT cannot be achieved, then replace them in the following order: system BIT, status monitoring, manual testing, automated testing equipment and manual inspection.

4. The method for airborne system fault testing and diagnosis requirements analysis based on a functional model according to claim 3, characterized in that: Step S5 specifically includes the following sub-steps: S51. In the functional fault logic relationship established in step S2, design the test diagnosis of system functional faults and determine the test points and test information of functional faults. S52. Feasibility analysis includes fault coverage analysis, design constraint analysis, benefit analysis, and fault isolation analysis. S53. Adjust test requirements: Based on the analysis results of fault coverage analysis, design constraint analysis and fault isolation analysis in step S52, adjust the initial configuration model of diagnostic elements according to the adjustment rules determined in step S32, and iterate through steps S52-S53 until all initial test requirements meet the adjustment rules of step S32.

5. The method for airborne system fault testing and diagnosis requirements analysis based on a functional model according to claim 4, characterized in that: Step S51 specifically includes the following sub-steps: S511. Test points are configured on the output ports of the device or subsystem; S512: A single test point can be configured with multiple tests; S513, Test the status associated with the connected output port; S514. Test information includes test name, test method, test cost, test time, test implementation unit, and design constraints.

6. The method for airborne system fault testing and diagnosis requirements analysis based on functional models according to claim 1, characterized in that: The specific operation process of step S6 is as follows: The system fault test diagnosis and analysis database includes an initial test requirement decomposition table, a fault coverage analysis table, and a subsystem / equipment test requirement table.

7. An airborne system fault testing and diagnosis requirements analysis system for the airborne system fault testing and diagnosis requirements analysis method based on functional models as described in claim 1, characterized in that: It includes a system functional model construction unit, a system fault logic model construction unit, a diagnostic element initial configuration and adjustment rule formulation unit, a test requirement configuration and decomposition unit, a functional fault test feasibility analysis and adjustment unit, and a system fault test diagnostic analysis database generation unit; The system functional model construction unit is used to construct the system functional model and conduct system functional hazard analysis or functional failure mode impact analysis; The system fault logic model construction unit is used to construct the system logic model and establish the functional fault logic relationships of the system, subsystems and equipment. The diagnostic element initial configuration and adjustment rule formulation unit is used to formulate the diagnostic element initial configuration and adjustment rules for system functional failures; The test requirement configuration and decomposition unit is used to configure and decompose the initial test requirements for system functional failures. The functional failure test feasibility analysis and adjustment unit is used to perform feasibility analysis and adjustment for functional failure tests. The system fault test diagnosis and analysis database generation unit is used to generate a model-based system fault test diagnosis and analysis database.

8. The airborne system fault testing and diagnosis requirements analysis system according to claim 7, characterized in that: The initial configuration model for diagnostic elements constructed by the test requirement configuration and decomposition unit is as follows: ； Where C is the initial configuration model for diagnostic elements, c1 and c 21 All represent the power-on bit, cycle bit, and start-up bit, c 22 Both c3 and c3 represent the power-on bit and the startup bit, respectively.

Images