Independence Requirement Analysis for Common-Mode Analysis of Aircraft System Safety Based on AADL

Abstract

Common-mode analysis (CMA) is a qualitative analytical method used to support the evaluation of independence in the system safety assessment of civil aircraft. In traditional CMA, independence requirements are usually identified by evaluating the combination of events using the fault tree AND-gates. This approach is cumbersome and highly dependent on the skills and experiences of system safety engineers. An Architecture Analysis and Design Language (AADL)-based methodology is proposed to derive independence requirements for CMA. Error propagation data in AADL is extracted to develop a fault propagation model. Subsequently, potential factors contributing to common-mode failures (CMFs) are identified using the fault propagation model. A Primary Flight Computer (PFC) of an aircraft is used as a case study to illustrate the effectiveness of our proposed method.

1. Introduction

In the development of aircraft systems, independence between functions, systems, or items is required to satisfy the safety requirements. Common-mode failures (CMFs) affecting multiple redundant elements of a system may reduce the system’s ability to meet the independence requirement [1]. As redundant architectures are widely applied in the design of civil aircraft systems to enhance safety, the risks caused by CMFs are gaining growing prominence in the system safety assessment of civil aircraft [2]. CMFs refer to the simultaneous failure of two or more components or channels in an identical manner, leading to the same failure outcome and mode [3]. Such CMFs compromise redundancy and effectively result in a single point of failure [4]. Therefore, aircraft system safety assessments should prioritize CMFs that may lead to catastrophic consequences and conduct common-mode analysis (CMA) [5].

Common-mode analysis (CMA) is a qualitative analytical method used to ensure that development independence is maintained, or the risk associated with the dependence is acceptable. In traditional CMA, fault tree analysis (FTA)-based techniques, such as the “AND” gate and minimum cut set methods, are commonly utilized to derive independence requirements [1,6]. However, these methods exhibit several limitations, including cumbersome modeling processes, inconsistencies in system models, and reliance on engineers’ expertise. Furthermore, modifications to the architectural design necessitate corresponding updates to the fault tree [7]. Additionally, the analysis of independence requirements must be concurrently updated. This approach fails to facilitate automation and iterative updates of the analysis.

Model-Based Safety Analysis (MBSA) has emerged as a major research focus in the field of aircraft system safety engineering [8,9]. It represents a fundamental shift from document-centric to model-driven approaches in safety-critical systems engineering. Early foundational work established the automated generation of safety artifacts like fault trees directly from system models, addressing consistency gaps between design and safety verification [10,11,12,13]. In MBSA, the widely used tools include SIMULINK and SCADE, which are the typical tools for formal system modeling [14]. Employed modeling languages encompass AltaRica [15,16], Architecture Analysis and Design Language (AADL) [17,18,19,20,21,22], SysML [23], and so on.

AADL is an embedded systems language that encapsulates the principles of MBSA. It provides a comprehensive set of standards for describing hardware and software system architectures and their corresponding functional interfaces. Nevertheless, AADL inherently lacks the capability for safety analysis. Consequently, AADL models must be transformed into existing safety analysis frameworks, such as fault trees [24], time state machines [25], and Petri nets [26]. Thereafter, established analysis and verification techniques applicable to these models can be employed.

The rest of this paper is organized as follows. Section 2 introduces the method of aircraft system modeling based on the AADL. In Section 3, a common-mode independence requirement identification method is proposed based on the fault propagation model. In Section 4, a Primary Flight Computer (PFC) of an aircraft is used as a case study to show the effectiveness of our method. In Section 5, concluding remarks are presented.

2. AADL Modeling Method for Typical Aircraft Systems

Aircraft systems typically comprise numerous subsystems and components. Therefore, it is imperative to identify component types and organize them into distinct packages. AADL primarily consists of component types and component implementations, organized into separate packages [27]. To facilitate comprehensive system architecture modeling, AADL provides property declarations for various component types and implementations. The modeling of an aircraft system encompasses both nominal and extended system models [28].

2.1. Construction of System Nominal Model

To organize components, it is essential first to identify component types and then create packages to group similar components. AADL supports three modeling types—software, execution platform, and system components [29]. As illustrated in

Table 1. AADL component meaning.

Category	Component	Detailed Explanations
Software	Data	Different types of data
	Thread	Schedulable units for parallel execution
	Process	Virtual processor for scheduling and executing threads
Hardware	Processor	Scheduling and executing threads
	Memory	Store code and data
	Bus	Connect processors, memory, and devices
	Device	Components such as sensors and actuators that represent external interfaces
System	Abstract	Represent any other component
	System	Integrate software, hardware, and other components

, the nominal model of the system is obtained by selecting appropriate AADL elements for each component and establishing their interconnections.

2.2. Construction of System Extended Model

The AADL error annex defines the declaration rules and specific semantics for constructing the error model. It facilitates the specification of error expression methods within architectural models and supports the assessment of aircraft system properties, including safety and reliability. It primarily comprises three components: error type, error behavior, and error propagation [30].

The error library [31] forms the foundation of the aircraft system error model, which consists of error types and behaviors. The failure effects of system components are declared in the error library, as determined by the interface output statuses of the components.

An error propagation model is established by specifying the influence of both external and internal failure states. To construct a comprehensive error model, details such as the error source, error sink, error path, and error transition, among other parameters, are incorporated [32]. The system’s error propagation model encompasses the incorporation of the error library and error behavior, the declaration of error propagation properties, and the modeling of internal states. The error characteristics used in the error annex include the following:

• Error propagation indicates the conditions under which a component emits an error;
• Error event represents the event that occurs in the component;
• Error transition defines how the state machine moves from one state to another, including the initial state, transition conditions, and termination state;
• Error source indicates that an error propagates out of the component;
• Error path describes how an error that originates outside a component, passes through the component;
• Error sink indicates that an error that enters a component, is handled inside the component;
• Error state defines the specific error states of the state-machine error-behavior models.

Since AADL inherently lacks safety analysis capabilities, the model must be transformed into an existing safety analysis framework. Moreover, essential information can be extracted for subsequent analysis of aircraft systems.

2.3. AADL Modeling: A Case Study of the Primary Flight Computer

In this section, a Primary Flight Computer (PFC) of an aircraft is selected as a study case to show the application of our AADL modeling method.

2.3.1. Description of the PFC

The PFC is a typical component that employs the redundant design in the flight control system. It receives control signals from the cockpit as input signals. PFC compromises three independent circuit boards: the command module, the monitor module, and the IO input/output module, as shown in Figure 1. Two lanes are present in the COM module, designated as the X-lane and Y-lane. Each lane is equipped with an identical type of CPU. Following processing by the CPU, the signals are transmitted to their respective FPGA for secondary processing. Simultaneously, a comparator is incorporated to compare the output signals from the X-lane and Y-lane, thereby preventing random failures In the MON module, a similar CPU is used to monitor the signals in the COM module. In the IOC module, the command IOC lane is mainly responsible for receiving external input signals, performing data processing, and sending the processed signals to the COM module CPU. The monitor IOC lane is mainly responsible for forwarding the processed signals to the MON module.

2.3.2. Nominal Model of the PFC

The nominal model of the PFC can be built by using the components given in Table 1. To provide a more detailed description of the internal structure, the “subsystem” components are chosen to model the command module (COM), the monitor module (MON), and the IO input/output module (IOC). By integrating the COM, MON, and IOC, the nominal model of the entire PFC is obtained, as illustrated in Figure 2.

Meanwhile, we can generate the code file of the PFC nominal model using an AADL tool such as Open Source AADL Tool Environment (OSATE).

2.3.3. Extended Model of the PFC

In the extended model, the error annex library and the error model must be defined. Three error types, which are {LossPower}, {LossSignal}, and {DataError}, are defined in the extended model of the PFC. These errors propagate to other components through ports, thereby affecting other components. Error behavior is established for each component in the error annex library, including declarations of error events, states, and transitions. This process represents the state transitions of the components when an error event occurs.

The error model of PFC consists of three parts: component error propagation, component error behavior, and composite error behavior, as shown in Figure 3. Error propagation defines how an error propagates from or into a component. Component error behavior represents the state transitions and how the state propagates error. Composite error behavior analyzes the collective impact of multiple components on overall system behavior.

In Figure 3, the composite error behavior includes a Voter component (analogous to PFC.Comparator), which checks outputs from redundant lanes. If discrepancies exceed thresholds, the Voter triggers a DataError state. This component was omitted in earlier diagrams for simplicity but is integral to the error model.

By adding the code of the PFC error model to the code file of the PFC nominal model, we can build the extended model.

3. Identification of Independence Requirements Using Fault Propagation

The traditional approach to deriving common-mode independence requirements based on fault tree analysis is cumbersome, labor-intensive, and heavily dependent on analysts’ expertise. Consequently, a common-mode analysis method is proposed based on a fault propagation model.

3.1. Common-Mode Analysis Process

According to ARP4761A [5], the causes of CMF include engineering factors, usage factors, and environmental factors, which constitute the source of the common-mode checklist. The process of common-mode analysis is as follows [33].

Step 1: A general common-mode checklist is initially established, as shown in

Table 2. Common-mode checklist.

Common-Mode Types	Common-Mode Sub-Types	Common-Mode Sources
Concept and Design	Design Architecture	Electrical power, hydraulic, ventilation, etc.
	Technology, Materials, Equipment	Size, hardware, software, material, etc.
Manufacturing	Manufacturer	Common manufacturer, procedure, etc.
Operation	Staff, procedures	Common staff, same procedure
Environment	Electrical and radiation	Electromagnetic, radiation, etc.
	Mechanical and thermal	Temperature, grit, vibration, etc.

. Many elements should be considered, including concept and design, manufacturing, operation, environment, etc. [34].

Step 2: Redundant design characteristics are typically represented using the “AND” gate (including the voting gates) [35]. In CMA, events related to independence requirements can be determined by identifying each “AND” gate input event or minimum cut set in the fault tree.

Step 3: The independence requirements are analyzed based on the common-mode checklist. If they are not affected by common-mode failures, relevant architectural design and supporting documents need to be submitted; if affected, it is necessary to reduce or eliminate the common-mode sources by altering the architecture design or improving product manufacturing quality.

3.2. Fault Propagation Model Construction Based on the AADL Model

Based on the architectural and error annex information provided by the AADL model, a fault propagation model of the system can be established. Components susceptible to CMF can be identified by the fault propagation model. The following is a step-by-step procedure to build the fault propagation model.

Step 1: Component types are first identified. In the AADL model, faults propagate within or between components. By retrieving keywords such as “device”, “process”, and “system” that represent component types, all components and their interface information in the model can be determined and saved in a component array.

Step 2: Fault propagation information is declared in the Error Model Annex to describe how faults propagate within or between components. A matrix P is constructed to store this information. P is a zero matrix, where the dimension is the number of components. P can be shown below.

$$P=\left[\begin{array}{cccc}0& p_{12}& \dots & p_{1n}\\ p_{21}& 0& \dots & p_{2n}\\ ⋮& ⋮& \ddots & ⋮\\ p_{n1}& p_{n2}& \dots & 0\end{array}\right],$$

(1)

where the value of $p_{ij}$ is taken as 1 or 0. When $p_{ij}=1$, it means fault propagates from component $i$ to $j$.

Step 3: The state transition logic within composite error behaviors is then determined. In matrix P, if there are multiple elements “1” in a column, it indicates that a fault has propagated from multiple components to one component. CMF usually exists in redundant architectures represented by “and” logic. If the keyword “and” exists in the composite error behavior, it can be determined that the composite error behavior may cause CMF and is marked in the matrix P.

The fault propagation model is updated as the AADL model changes. It can ensure the consistency between two models.

3.3. Common-Mode Independence Requirements Identification

In this section, the fault propagation paths are analyzed to identify components susceptible to CMF based on the fault propagation model. The method to obtain the fault propagation path is shown in Figure 4.

Step 1: CMA is performed based on the common-mode checklist. For ease of analysis, labels are assigned to components according to the checklist. In this step, we should consider the common-mode types and sources in the checklist to add the corresponding labels.

Step 2: In the fault propagation matrix P, the search begins from the last column, where the output component or interface is located. If there are multiple “1” values in the column and their composite error behavior logical is “and”, we record the component number of the column $i$.

Step 3: For each “AND” or “k (k > 1) ormore” logic component, its forward fault propagation path is determined. For example, the value of $p_{j_{1}i}$ and $p_{{\mathrm{j}}_{2}i}$ in the column $i$ is “1”. It means that only when fault propagates from component $j_1$ and $j_2$, component $i$ will continue to propagate the fault. Then we should retrieve the elements $p_{{\mathrm{k}}_1{\mathrm{j}}_1}$ and $p_{{\mathrm{k}}_2{\mathrm{j}}_2}$ in column $j_1$ and $j_2$, where $k_1$ and $k_2$ are is the components that propagate faults from the previous level. We should repeat this process until the component is the initial input component. Then we record the component names corresponding to the matrix elements on these two propagation paths. The pseudo-code of Error propagation path determination is given in Algorithm 1.

Algorithm 1 The algorithm of Error propagation path determination

Extract Error propagation path: Extract_CP( ) INPUT: the error propagation model OUTPUT: component path

1   Extract_CP (error propagation model) 2   component_paths = {} 3   num_components = len(error_propagation_model) 4   FOR i in range(num_components) 5         IF sum(error_propagation_model[i]) > 1 6               FOR j1 in range(num_components) and j2 in range(num_components) 7                  IF error_propagation_model[i][j1] == 1 and error_propagation_model[i][j2] == 1 8                     IF j1! = 0 and j2! = 0 9                          path_ j1 = trace_fault_path(error_propagation_model, j1) 10                        path_ j2 = trace_fault_path(error_propagation_model, j2) 11                        component_paths[i] = {‘path_ j1’: path_ j1, ‘path_ j2’: path_ j2} 12                       END IF 13                     END IF 14                  END FOR 15      END IF 16 END FOR 17 END Extract_CP

Furthermore, each “AND” or “k (k > 1) ormore” logic component is identified by analyzing composite error behaviors in the AADL error annex. For example, if a component’s error behavior transitions depend on the simultaneous occurrence of errors from two upstream components (e.g., COMX.CPU and COMY.CPU), the composite behavior is tagged with an AND operator. This is programmatically detected using keyword searches (e.g., and in AADL error transitions) during model parsing.

Step 4: After determining the fault propagation path, possible CMF component combinations are identified. According to the two sets of components obtained in step 3, we should compare the elements in one set with those in the other set. If the components are the same type or have the same label, it is determined as a possible combination of CMF components and recorded. Then we return to step 3 until all “and” logical components are traversed.

Based on the identified component combinations, CMF risks are assessed using the common-mode checklist. If the components are affected by CMF, independence requirements should be proposed.

3.4. Independence Requirement Identification: A Case Study of the PFC

In this section, we also take the above-mentioned PFC as an example to show how to identify the common-mode independence requirements.

3.4.1. Fault Propagation Model of the PFC

There are 13 components or interfaces in PFC according to the AADL model. Figure 5 constructs a 13 × 13 fault propagation matrix P.

In fault propagation matrix P, the red cell indicates that the fault propagates by “and” logic. The green cell indicates that the fault propagates by “or” logic. According to Figure 5, there are multiple components propagating faults to components 10 (COM.Compare) and 11 (PFC.Compare) by “and” logic. So we need to analyze their forward fault propagation paths.

3.4.2. Common-Mode Independence Requirements Identification of the PFC

For more convenience analysis, we should add labels to the components according to the common-mode checklist. The labels added in PFC are shown in

Table 3. Component labels.

Component Name	Design Architecture	Technology, Materials, Equipment	Manufacturer
IO_COM. FPGA	IOC_Power	IOC	FPGA manufacturer
IO_MON. FPGA	IOC_Power	IOC	FPGA manufacturer
COMX. CPU	COM_Power	COM	CPU_A manufacturer
COMX. FPGA	COM_Power	COM	FPGA manufacturer
COMY. CPU	COM_Power	COM	CPU_A manufacturer
COMY. FPGA	COM_Power	COM	FPGA manufacturer
COM. Comparator	COM_Power	COM	Comparator manufacturer
MON. CPU	MON_Power	MON	CPU_B manufacturer
MON. FPGA	MON_Power	MON	FPGA manufacturer
PFC. Comparator	PFC_Power	PFC	Comparator manufacturer

. For example, component “IO_COM.FPGA” has four labels. “IOC_Power” indicates that the FPGA is powered by the IOC module. “IOC” indicates that the FPGA is deployed and works in the IOC module. “FPGA” indicates that it is produced by FGPA manufacturers.

According to the fault propagation matrix, we analyze the “and” logic in it and obtain the fault propagation paths, as shown in Figure 6. There are three paths and two “and” logics in this fault propagation process. In fault propagation path, the red node indicates that the fault propagates by “and” logic. The green node indicates that the fault propagates by “or” logic.

The CMF components and independence requirements obtained from the comprehensive analysis of the PFC are shown in

Table 4. Common-mode failure component and independence requirement.

Code	Component Pair		Independence Requirement Description
1	COMX. CPU	COMY. CPU	CPU in COM X-lane and Y-lane should be independent
2	COMX. CPU	MON. CPU	CPU in COM and MON module should be independent
3	COMX. FPGA	COMY. FPGA	FPGA in COM X-lane and Y-lane should be independent
4	COMX. FPGA	MON. FPGA	FPGA in COM and MON module should be independent
5	IO_COM. FPGA	IO_MON. FPGA	FPGA in IOC module COM and MON should be independent
6	COMX. CPU	COMY. FPGA	CPU in X lane and FPGA in Y lane should be independent
7	COMY. CPU	COMX. FPGA	CPU in Y lane and FPGA in X lane should be independent
8	COMX. FPGA	IO_MON. FPGA	CPU in COM and IOC module should be independent
9	COMY. FPGA	IO_MON. FPGA	N/A
10	MON. FPGA	IO_MON. FPGA	N/A

.

4. Discussion and Comparison Analysis

4.1. Common-Mode Independence Requirements Analysis

The common-mode independence requirements are analyzed by considering redundant components and functions.

For instance, in ID 1, {COMX.CPU} and {COMY.CPU} represent the processors used in the X and Y channels of the COM module, respectively. Simultaneous propagation of the {LossSignal} error by both processors may result in PFC signal loss. According to the common-mode checklist, these two CPUs are susceptible to CMF due to the same type of operating environment. Therefore, independence between these CPUs must be ensured. The requirement stating that “CPU in COM X-lane and Y-lane should be independent” is proposed.

In addition to redundant components, attention must also be given to the components of different types that perform the same function. In ID 6, {COMX.CPU} and {COMY.FPGA} represent the X-channel CPU and Y-channel FPGA in the COM module, respectively. Although differing in component type, both execute the function of processing PFC signals. According to the common-mode checklist, both components are located inside the COM module. Their power supply, data transmission, and working environment are susceptible to common-mode factors. Thus, the independence requirement stating that “CPU in X lane and FPGA in Y lane should be independent” is established.

Some component combinations may not necessarily result in CMF due to design architecture. In the 8th component combination, {COMX.FPGA} and {IOCMON.FPGA}, respectively, represent the FPGA of the X channel in the COM module and the MON in the IOC module. These two FPGAs perform different functions and have no connection interaction relationship. According to the common-mode checklist, their power supply, data transmission, and working environment are independent. So there is no need to propose independence requirements.

4.2. Comparison with FTA-Based Method

Reference [24] proposed a transformation rule from the AADL model to the fault tree model. The AADL modeling tool OSATE includes functionality for transforming AADL models into fault trees.

Traditional common-mode analysis is generally based on FTA [36]. It includes the analysis of the “AND” gate and minimum cut set of the fault tree.

The analysis of the “AND” gate requires analysts to observe the “AND” gates in the fault tree. The input events under each “AND” gate must be analyzed based on the common-mode checklist. However, the “AND” gate appears in different levels within the fault tree. This analysis method depends on the analyst’s understanding of the system and engineering experience. In complex fault trees, omissions are likely to occur.

The minimum cut set exhaustively lists all possible combinations that could result in the occurrence of the top event. The independence of the events within the minimum cut set must be analyzed. However, in complex redundant systems, a substantial number of minimum cut sets exist. The analysis workload is significant. And the events in the minimum cut set are basic events. The independence between intermediate-level events is not taken into account.

Taking “PFC LossSignal” as the top event, we can obtain the fault tree based on AADL, as shown in Figure 7.

In this fault tree, there are two “AND” gates. The input events of these gates should be independent. For example, the “AND” gate {PFC COMLossSignal} has two input events, {COMX LossSignal} and {COMY LossSignal}. It indicates that the X-lane and Y-lane in the COM module should be independent. For a more detailed analysis, the basic events under these two intermediate events should also be considered.

The analysis results of FTA are listed in

Table 5. Common-mode independence requirement (FTA).

ID	Independence Requirement
1	CPU in COM X-lane and Y-lane should be independent
2	CPU in COM and MON module should be independent
3	FPGA in COM X-lane and Y-lane should be independent
4	CPU in COM and IOC module should be independent
5	FPGA in COM and MON module should be independent
6	FPGA in IOC module COM and MON should be independent
7	CPU in X lane and FPGA in Y lane should be independent
8	CPU in Y lane and FPGA in X lane should be independent

. Comparing the FTA method and the method we proposed, the analysis results are the same. Our method avoids the cumbersome modeling process of fault trees and can be updated as the architecture changes.

Compared to Lanzani et al.’s work [17], our method avoids manual tagging of commonalities by leveraging AADL’s inherent error propagation semantics, reducing subjectivity. Furthermore, our toolchain supports iterative updates, whereas their approach requires re-tagging after design changes.

5. Conclusions

This study carries out CMA and identifies the common-mode independence requirements based on the AADL model. The main contributions of this study are as follows:

• AADL is used to establish nominal and extended models of redundant systems. CMA is conducted based on these models, ensuring consistency between the aircraft analysis and the design models.
• A fault propagation model is established based on the AADL model. It can identify factors that may cause aircraft system CMF and propose independence requirements. The analysis results can be dynamically updated in response to architecture modification.
• The effectiveness of the proposed method is verified by comparing the CMA method based on the fault propagation model with the traditional FTA method. The proposed method can avoid the cumbersome process of constructing fault trees in traditional CMA.

This study presents the following key innovations:

• AADL-based automation for independence requirements: We introduce a novel, automated method to derive common-mode independence requirements directly from AADL models. By constructing a fault propagation model and analyzing its logic (e.g., “AND” gates), the method systematically identifies potential CMF component combinations, significantly reducing manual effort and subjectivity compared to traditional FTA-based CMA.
• Ensured consistency and dynamic update capability: The approach maintains consistency between the AADL design model and safety analysis (fault propagation model, requirements). Crucially, both the model and derived requirements can be dynamically updated as the architecture evolves, enabling efficient iterative design and assessment.

The limitations of our work include reliance on AADL’s error annex for fault modeling, which may not capture all physical interactions. Future work will integrate SysML for multi-physics analysis and extend the method to probabilistic CMF scenarios.