A model-based civil aircraft integrated modular avionics resident system design method

Abstract

This invention discloses a model-based design method for a modular avionics-based resident system for civil aircraft, comprising: S1, resident system requirement modeling and requirement verification based on a customized MBSE method; S2, resident application software functional logic modeling based on a Simulink model; and S3, resident system qualitative safety analysis based on functional scenarios and fault combinations. The input to step S1 comes from the resident system's technical protocol issued by the host. Through iterative modeling, the resident system's requirements are captured and sent to step S2. Step S2 provides feedback on system design issues identified during the modeling process. Step S1 simultaneously sends the resident system's requirements to step S3, while step S3 feeds back the identified safety requirements and constraints to step S1 to support system requirement iteration. This invention provides an efficient, replicable, and implementable design approach for modular avionics-based resident systems, improving system design efficiency and reducing verification costs.

Description

Technical Field

[0001] This invention relates to an avionics system design method, and more particularly to a model-based design method for a civil aircraft integrated modular avionics dwell system. Background Technology

[0002] Integrated Modular Avionics (IMA) systems represent a significant trend and key airborne avionics system in the development of large civil aircraft avionics in recent years. IMA systems employ an integrated, modular, and open system architecture, featuring a universal integrated processing cabinet, a universal operating system, universal fault-tolerant processing, central power supply, and flexible aircraft application interfaces. It does not provide any aircraft-level functionality itself; instead, various aircraft-level functions operate as resident software within its provided environment, thereby realizing the aircraft-level functionality of various airborne avionics / electromechanical systems.

[0003] Traditional airborne avionics system design is generally document-based, with core design work revolving around document-based requirements and design iterations (primarily through technical reviews and referencing engineering experience from other projects). The system design information, comprised of numerous documents of various types, makes it difficult to maintain consistency and traceability during iterative design processes. This increases the difficulty and complexity of conducting system engineering activities and is unsuitable for the forward design of airborne avionics systems (high-security, multidisciplinary, and complex systems). Furthermore, insufficient design work leads to a disconnect between system design and product implementation, as well as system verification. This typically requires significant resources for iterative product implementation and system verification, resulting in low system development efficiency.

[0004] Compared to traditional text-based systems engineering methods, model-based systems engineering (MBSE) can support systems engineering activities throughout the entire lifecycle of system development using formal modeling languages, including system requirements, design, analysis, and verification. It achieves the design of the system at all levels and dimensions through the continuous evolution of the model.

[0005] Based on the analysis of publicly available literature and patents, there are currently no documents or patents specifically studying the design of civil aircraft IMA (In-Aircraft Navigation and Assistance) systems. Only a few examples exist of applying model-based design modeling methods to airborne system design. In the literature "Research and Simulation of Model-Based Systems Engineering in Avionics System Design" (Wang Yang. Research and Simulation of Model-Based Systems Engineering in Avionics System Design [J]. Digital Technology and Application, 2020, 38(2):3.DOI:CNKI:SUN:SZJT.0.2020-02-071.), the author uses the classic HarmonySE modeling methodology and the Rhapsody modeling tool to study the design of the TCAS system, discussing the modeling and implementation of basic model elements. In the literature "Modeling and Model Verification of Civil Aircraft Data Loading System Based on MBSE" (Yang Yuan; Modeling and Model Verification of Civil Aircraft Data Loading System Based on MBSE [D]; University of Electronic Science and Technology of China; 2020), the author uses Rhapsody to model and perform model-based simulation verification of the airborne data loading system. In the patent document "Design Method of Airborne Fiber Optic Strapdown Attitude and Classification System Based on MBSE Model" (Patent Authorization No.: CN114217769B), the authors designed a system design method for attitude and classification systems based on the Rhapsody tool and HarmonySE modeling methodology, encompassing processes such as requirements analysis, functional analysis, and design synthesis. In the patent document "A Modeling Method, System, and Process for Airborne Communication Systems Based on the Capella Platform" (Patent Publication No.: CN113162792A), the authors designed a system design method for airborne communication systems based on the Capella tool and Arcadia methodology, including processes such as operational analysis, system analysis, logical analysis, and physical entity analysis.

[0006] As can be seen from the above, current model-based system design methods generally suffer from the following problems:

[0007] 1. Existing solutions typically only apply standard MBSE modeling methodologies to describe generalized modeling frameworks and tasks, such as HarmonySE, Arcadia, or MagicGrid. These methods do not clearly describe the specific engineering activities involved in avionics system design, making it difficult for users to perform practical operations. Consequently, MBSE-based design results are not significant, and the methods cannot be effectively implemented or promoted.

[0008] 2. Existing solutions only address requirement capture at the system level, failing to adequately consider the connection between system design and product implementation. This results in many specific designs and requirements not being considered or captured during product implementation, making it difficult for the product implementation team to utilize the model's results. Consequently, there is a disconnect between system design, product implementation, and validation. From the perspective of the MBSE methodology, existing solutions only consider isolated model solutions for system design within the problem domain and solution domain, without providing a complete model-based system design solution that bridges the problem domain, solution domain, and product implementation domain.

[0009] 3. Existing solutions typically only consider system design issues and do not conduct safety-related design analysis activities simultaneously during the system design process. This fails to provide sufficient system design information for safety analysts and is inconsistent with the working practices of the civil aircraft industry (ARP4754 and ARP4761 require civil aircraft avionics system design and safety design to be carried out in parallel and simultaneously).

[0010] 4. There are no successful application cases for the integrated modular avionics dwell application system in the existing solution. Summary of the Invention

[0011] The technical problem to be solved by the present invention is to provide a model-based design method for integrated modular avionics dwell system of civil aircraft, which can provide an efficient design idea and a replicable and implementable design method for the design of integrated modular avionics dwell application system, thereby improving system design efficiency and reducing the implementation cost of system verification.

[0012] To address the aforementioned technical problems, this invention provides a model-based design method for a civil aircraft integrated modular avionics dwell system, comprising the following steps: S1, dwell system requirement modeling and requirement confirmation based on a customized MBSE method; S2, dwell application software functional logic modeling based on a Simulink model; S3, dwell system qualitative safety analysis based on functional scenarios and fault combinations; the main input of step S1 comes from the technical protocol of the dwell system issued by the host, and through modeling iteration, the requirements of the dwell system are captured and sent to step S2; step S2 provides feedback on system design problems identified during the modeling process to support iterative design and updating of system requirements; step S1 simultaneously sends the dwell system requirements to step S3, while step S3 feeds back the identified safety requirements and constraints to step S1 to support system requirement iteration; step S2 outputs the design information of the dwell application software to step S3, and simultaneously obtains the safety constraints of the dwell application software identified by the safety analysis from step S3.

[0013] Furthermore, step S1 divides the modeling and design work of the resident application system into two stages: the problem domain and the solution domain. It clarifies the main tasks in each stage and the inputs and outputs between them. The activities within the two stages are iterated in a loop to meet the design requirements of the system. The activities between the two stages are also iterated to ensure that the solution domain model is consistent with the problem domain model.

[0014] Furthermore, step S1 employs a tailored AOT system MBSE design method, dividing the problem domain modeling activity into the following steps: S11, AOT system requirements analysis modeling: Obtain customer requirements for the AOT system, establish corresponding requirement diagrams in the Magicdraw environment, and establish each requirement as a requirement object; S12, AOT system scenario analysis modeling: Establish a Usecase diagram for the AOT system, and identify the working scenarios and interaction objects of the AOT system; S13, AOT system functional analysis modeling: For various different working scenarios, analyze the functional logic or functional flow of the AOT system using activity diagrams, sequence diagrams, or state machine diagrams; S14, AOT system architecture analysis modeling: Analyze the architecture of the AOT system through class diagrams and internal structure diagrams, and identify the input / output interfaces and input / output information of the AOT system; S15, AOT system model and high-level requirement tracing relationship modeling analysis: Trace the model elements to the system requirements, representing that the requirements are covered by the problem description.

[0015] Furthermore, step S1 also includes: after the model reaches a certain level of maturity, by introducing stakeholders of the AOT system to review the modeling design content, identify errors or omissions in the model, and provide key design input information so that the problem domain model can correctly describe the design problems of the AOT system; if the model's maturity is insufficient, then iterative work is carried out on problem domain modeling, and the problem domain model of the AOT system is updated by acquiring more design information, engineering experience, and design assumptions.

[0016] Further, step S1 divides the solution domain modeling activity into the following steps: S15, AOT system functional analysis and modeling: Analyze the functional logic or functional flow of AOT system sub-functions using activity diagrams, sequence diagrams, or state machine diagrams; S16, AOT system architecture analysis and modeling: Analyze the architecture of AOT system sub-functions using class diagrams and internal structure diagrams, and identify the input / output interfaces and input / output information of each sub-function; S17, AOT system model simulation verification: Based on the activity diagrams or state machine diagrams of the solution domain model, perform model simulation tests to check and verify the system design scheme; S18, AOT system... System Requirements Analysis and Modeling: Modeling identifies uncovered model content or design constraints within the requirements and converts them into system requirements for management within the requirements diagram; simultaneously, it establishes a solution domain requirements diagram for the requirements; S19, AOT System Model and System Requirements Traceability Modeling and Analysis: After iteratively updating the requirements, a traceability relationship is established between model elements and AOT system requirements in the solution domain, representing that the requirements are covered by the design solution; simultaneously, a traceability relationship is also established between the requirements of the solution domain and the requirements of the problem domain; if incomplete coverage is identified, new requirements are captured or the design is modified to achieve complete coverage of the traceability relationship.

[0017] Furthermore, step S1 also includes: after the model reaches a certain level of maturity, by introducing stakeholders of the AOT system to review the modeling design content, identifying errors or omissions in the model, and providing key design input information so that the solution domain model can accurately reflect the design scheme of the AOT system, and all designs that meet customer needs are correctly captured; the solution domain modeling process is iterated multiple times, with each iteration updating the system requirements and the corresponding solution design, until all design content that meets the requirements of the problem domain is captured in the model.

[0018] Further, step S2 includes: firstly, performing software architecture design; based on the high-level requirements of the resident application software, proposing a software reference architecture scheme as the iterative starting point for model design; the reference architecture needs to describe the software's module division, basic input / output interfaces between modules, and functional requirements of each functional module; based on the reference architecture, designing software functional modules; divided into two cases: i) if the function of the software module can be directly implemented by a specific algorithm or logic, then the design of the software functional module is considered complete, and it is necessary to identify the impact of the implementation scheme of the software functional module on the software architecture; ii) if the If the functionality of a software module cannot be directly implemented by an algorithm or logic, it is considered a new software black box. The first step is to analyze and propose the architecture design of this black box, and then iterate the design of its sub-modules. After the software model design reaches a certain level of maturity, the architectural requirements or constraints identified in the software model design are fed back into the software architecture design to iterate the overall software model architecture design and improve the overall design of the software model. The final output of the resident application software design is the resident application software model. After the resident application software model discovers requirements or design problems, it is fed back into the MBSE modeling work to iteratively update the AOT system design and requirements.

[0019] Furthermore, the top layer of the resident application software model consists of the Simulink modules corresponding to the four AOT instances and the input / output interfaces for interaction between them. The lower layer of each AOT instance module is the specific software function implementation of the AOT module, including the design of the AOT fault injection interface and the model mode control interface.

[0020] Furthermore, step S3 uses a matrix diagram to describe the results of the security analysis; the rows of the matrix represent the working scenarios of the AOT system, and the columns represent the failure modes; step S3 requires multiple rounds of security assessment to ensure that the target system outputs acceptable results under all working scenarios and failure combinations, and that the corresponding security requirements are met for cases where the output results are unacceptable: i. If an independent monitoring function for known failures is added, a new round of security analysis and assessment is performed; ii. If an independent monitoring function for the loss of AOT function is added, a new round of security analysis and assessment is performed.

[0021] Furthermore, the work scenarios include ground-based work scenarios, airborne work scenarios, and data loading scenarios; the external interaction objects include airborne systems with input / output interfaces to the AOT system, airborne functions, and operators of various systems.

[0022] Compared with the prior art, the present invention has the following beneficial effects: The model-based design method for integrated modular avionics dwell system of civil aircraft provided by the present invention can provide an efficient design idea and a replicable and feasible design implementation method for the design of integrated modular avionics dwell application system, thereby improving system design efficiency and reducing the implementation cost of system verification. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the model-based integrated modular avionics dwell system for civil aircraft according to the present invention;

[0024] Figure 2 This is a flowchart of the modified MBSE modeling method for the AOT system according to the present invention;

[0025] Figure 3 This is a flowchart illustrating the design of the application software model for this invention.

[0026] Figure 4 This is a logic diagram of mode switching between the models of the present invention;

[0027] Figure 5 This is a matrix result diagram after the first round of security analysis of this invention;

[0028] Figure 6 The matrix result diagram after performing a new round of security analysis with independent monitoring of known faults for this invention;

[0029] Figure 7 The matrix result diagram is shown after a new round of security analysis was performed to add independent monitoring of function loss to the present invention. Detailed Implementation

[0030] The present invention will now be further described with reference to the accompanying drawings and embodiments.

[0031] Figure 1 This is a schematic diagram of the model-based integrated modular avionics dwell system for civil aircraft according to the present invention.

[0032] Please see Figure 1 This invention provides a model-based design method for integrated modular avionics residency application systems, which offers an efficient design approach and a replicable and feasible design implementation method for the design of integrated modular avionics residency application systems, thereby improving system design efficiency and reducing the implementation cost of system verification.

[0033] This method consists of three steps: Step 1: Requirements modeling and verification of the residency application system based on a customized MBSE methodology; Step 2: Functional logic modeling of the residency application software based on a Simulink model; Step 3: Qualitative security analysis of the residency application based on functional scenarios and fault combinations. Through the parallel execution and iterative implementation of these three steps, the residency application system design gradually matures, supporting product implementation and system integration verification, making it suitable for design applications in IMA residency systems.

[0034] Step 1: Resident Application System Requirements Modeling and Validation. A customized MBSE method and process are adopted for the object system. Drawing inspiration from the MagicGrid methodology, the modeling and design work for the resident application system is divided into two main phases: problem domain and solution domain. The main tasks within each phase and their inputs and outputs are clearly defined. Activities within each phase can be iteratively repeated to meet the system's design requirements. Activities between the two phases can also be iteratively performed to ensure consistency between the solution domain model and the problem domain model. The modeling iteration emphasizes the traceability and coverage of design to requirements, and lower-level requirements to higher-level requirements. The main input for Step 1 comes from the high-level requirements of the resident application system issued by the host. Through iterative modeling, the system-level requirements of the resident application are captured and issued to Step 2. Step 2 will then provide feedback on system design issues identified during the modeling process to support iterative design and updates of system requirements. Step 1 will simultaneously send the system-level requirements of the resident application to Step 3, while Step 3 will provide feedback on identified system security requirements and constraints to Step 1 to support iterative system requirements iteration.

[0035] Step 2: Functional Logic Modeling of Resident Application Software. Using a Simulink model, the gap between system requirements and product implementation (resident software) is bridged, making the process from design to implementation to verification smoother and more coherent. The main input to Step 2 comes from the upper-level resident application system requirements, and the main output is the captured high-level requirements of the resident software. Step 2 also provides feedback to Step 1 on system design issues identified during software modeling. Step 2 outputs the design information of the resident application software to Step 3, and obtains the security constraints of the resident application software identified through security analysis from Step 3.

[0036] Step 3: Qualitative Security Analysis of Resident Applications. A qualitative security analysis method based on operational scenarios and fault combinations is employed to tightly integrate requirements analysis and system design, supporting trade-offs in the architectural design of resident application systems and software, and providing the security team with more system design information.

[0037] This invention uses the AOT (Aircraft Option Table) system as a system example for the application of the Integrated Modular Avionics (IMA) system in civil aircraft. It employs the proposed scheme to design the AOT system, specifically illustrating the implementation of this method. The AOT system stores and distributes configuration information required by the aircraft and avionics systems, such as optional equipment lists and aircraft system calibration data. It is one of the key resident systems of the core avionics processing system, and its design safety assurance level meets the highest DAL A requirement in the civil aviation industry. The design of the AOT system mainly includes three iterative design steps.

[0038] I. Requirements Modeling and Requirement Confirmation for Resident Application Systems

[0039] The flowchart of the trimmed AOT system MBSE design method used in this invention is as follows: Figure 2 As shown. The entire design process can be divided into two main stages of modeling: the problem domain and the solution domain, including:

[0040] Problem domain modeling activities:

[0041] AOT system high-level requirements analysis and modeling;

[0042] AOT system scenario analysis and modeling;

[0043] AOT system functional analysis and modeling (black box);

[0044] AOT system architecture analysis and modeling (black box);

[0045] Modeling and analysis of the relationship between the AOT system model and high-level requirements.

[0046] Solution domain modeling activities:

[0047] AOT system functional analysis and modeling (white box);

[0048] AOT system architecture analysis and modeling (white box);

[0049] AOT system model simulation verification;

[0050] AOT system requirements analysis and modeling;

[0051] Modeling and analysis of the relationship between AOT system model and system requirements;

[0052] The activities within each of the two phases can be iterated over, allowing the model to gradually reach a certain level of maturity and meet the system's design requirements. The activities in both phases can also be iterated to ensure consistency between the solution domain model and the problem domain model.

[0053] Problem Domain Modeling of AOT Systems

[0054] 1.1 High-level requirements analysis and modeling for AOT systems

[0055] The first step in modeling the problem domain of an AOT system is to obtain the customer requirements for the AOT system. In this project, the customer requirements mainly originate from the higher-level system requirements above the AOT system. After obtaining these requirements, a corresponding requirement diagram is created in the MagicDraw environment, with each requirement being created as a requirement object.

[0056] 1.2 AOT System Scenario Analysis and Modeling

[0057] After completing the AOT system requirements diagram, it is necessary to analyze the AOT system's usage environment. This includes creating an AOT system use case diagram and identifying the main operating scenarios of the AOT system, including ground-based, airborne, and data loading scenarios. Simultaneously, based on customer needs and engineering experience, identify the external interaction objects of the AOT system, primarily including airborne systems with input / output interfaces, airborne functions, and operators of various systems.

[0058] 1.3 AOT System Functional / Architecture Analysis and Modeling (Black Box)

[0059] After identifying the working scenarios and interactive objects of the AOT system, the functional logic or functional flow of the AOT system is analyzed using activity diagrams, sequence diagrams, or state machine diagrams for various working scenarios, as well as the possible top-level working modes and their switching logic of the AOT system.

[0060] While performing functional analysis, the architecture of the AOT system is analyzed in the form of class diagrams (BD) and internal structure diagrams (IBD) to identify the input and output interfaces and input and output information of the AOT system (only high-level information, without considering the specific implementation).

[0061] When performing functional and architectural analysis, the AOT system is treated as a black box object, and its internal functions are not exposed. Only the functions, interfaces, and architectural constraints of the top-level AOT system need to be identified. This information is then captured and solidified into the model using SysML language graphical elements; that is, the design problems of the AOT system are described through model elements.

[0062] 1.4 Analysis and Modeling of the Relationship between AOT System Model and Requirements Traceability

[0063] After completing the functional and architectural analysis of the AOT system, it is necessary to trace the model elements (activities, interfaces, or classes / modules) against the system requirements to show whether the requirements are covered by the problem description. If there are model elements that are not covered by the requirements, new system requirements have been identified. These requirements need to be confirmed and agreed upon with the client to update the model accordingly.

[0064] Once the model reaches a certain level of maturity, stakeholders of the AOT system (host, customer, subsystem / component supplier, domain experts within the team, etc.) are brought in to review the modeling design content, identify errors or omissions in the model, and provide key design input information (the goal is to ensure that the problem domain model can correctly describe the design problem of the AOT system).

[0065] If the model is not mature enough, work iterations of problem domain modeling are carried out to update the problem domain model of the AOT system by acquiring more design information, engineering experience, and design assumptions.

[0066] AOT System Solution Domain Design

[0067] 1.5 AOT System Functional / Architecture Analysis and Modeling (White Box)

[0068] After completing the problem domain modeling of the AOT system, it is necessary to model it from an implementation perspective. This involves opening up the functional modules of the problem domain model and performing white-box functional analysis. Depending on the complexity of the AOT system, modeling can be layered.

[0069] Similar to problem domain modeling methods, activity diagrams, sequence diagrams, or state machine diagrams are used to analyze the functional logic or functional flow of sub-functions in the AOT system, the information flow of interactions between sub-functions, or the possible working modes and switching logic of sub-functions.

[0070] While performing functional analysis, the architecture (layered architecture) of the AOT system sub-functions is analyzed in the form of class diagrams (BD) and internal structure diagrams (IBD), and the input and output interfaces and input and output information of each sub-function are identified (in this project, the solution domain interface model messages and AOT system interface messages correspond).

[0071] 1.6 AOT System Model Simulation Verification

[0072] After completing functional and architectural analysis, model simulation testing can be performed based on the activity diagram or state machine diagram of the solution domain model to check and verify the system design scheme. This mainly includes checking whether the model covers all working scenarios and logical branches of the AOT system, whether the interaction or mode state transition is consistent with the design expectations (a rough check of system behavior logic; detailed model logic design and testing will be carried out later in Simulink modeling), and whether the jump conditions of the identification logic branches are consistent with expectations. Different design schemes of the AOT system can be modeled in the model, and trade-off analysis of the design schemes can be performed based on the model.

[0073] 1.7 AOT System Requirements Analysis and Modeling

[0074] After the solution domain model reaches a certain maturity level through simulation testing, modeling is used to identify model content or design constraints not covered in the requirements (identifying model elements that cannot be associated with the requirements), and these are then converted into system requirements and incorporated into the requirements diagram for management. During this process, a solution domain requirements diagram needs to be created for the requirements (AOT system-level requirements).

[0075] 1.8 Analysis and Modeling of the Relationship between AOT System Model and Requirements Traceability

[0076] After iteratively updating the requirements, a traceability relationship needs to be established between model elements (activities, interfaces, or classes / modules) and AOT system requirements in the solution domain, indicating that the requirements are covered by the design solution. Simultaneously, a traceability relationship also needs to be established between the requirements in the solution domain and the requirements in the problem domain (representing that the solution design covers the system requirements; and that all customer requirements have been considered). If incomplete coverage is identified, new requirements need to be captured or the design modified as needed to achieve complete coverage of the traceability relationship (which may require iteration of the problem domain model).

[0077] Once the model reaches a certain level of maturity, similar to problem domain modeling, stakeholder reviews of the AOT system's design are introduced to identify errors or omissions and provide crucial design input information (the goal is to ensure the solution domain model accurately reflects the AOT system's design, and that all designs meet customer requirements and are correctly captured). Solution domain modeling is also a multi-iterative process; each iteration updates system requirements and corresponding solution designs (different designs can be used to support trade-off analysis), until all design content meeting the problem domain requirements is captured in the model.

[0078] II. Functional Logic Modeling of Resident Application Software

[0079] After obtaining the AOT system requirements and SysML model, the software functional logic model of the AOT system is performed based on the Simulink toolbox to simulate product implementation (product implementation domain modeling).

[0080] The design of the resident application software model adopts, for example Figure 3 The process is illustrated below. First, the software architecture is designed. Based on the high-level requirements of the resident application software, a reference architecture is proposed as the starting point for iterative model design. This reference architecture needs to describe the software's modular division, basic input / output interfaces between modules, and the functional requirements of each module.

[0081] Based on the reference architecture, the design of software functional modules is carried out. This can be divided into two cases: 1) If the function of the software module can be directly implemented by the specific algorithm or logic, then the design of the module is considered complete. At the same time, it is necessary to identify the impact of the implementation scheme on the software architecture. 2) If the function of the software module cannot be directly implemented by the algorithm or logic (complex function), it can be regarded as a new software black box. First, the architecture design of the black box is proposed through analysis, and then its sub-modules are designed iteratively.

[0082] Once the software model design reaches a certain level of maturity, the architectural requirements or constraints identified in the software model design are fed back into the software architecture design, undergoing iterative design of the overall software model architecture to refine the overall design. The final output of the resident application software design is the resident application's software model (Simulink model).

[0083] Once the residency application software model identifies requirements or design issues, it can be fed back to the MBSE modeling work to iteratively update the AOT system design and requirements.

[0084] The top layer of the AOT software model architecture consists of the Simulink modules corresponding to the four AOT instances and the input / output interfaces for interaction between them. The lower layer of each AOT module instance contains the specific software function implementation of the AOT module, including the design of AOT fault injection interfaces and model mode control interfaces. This allows for the simulation of AOT system faults and virtual model integration testing in the early stages of AOT system design.

[0085] A significant portion of the work on the Simulink model for AOT involves modeling and iterating the system behavior under various AOT failure scenarios. Based on the failure modes and scenarios identified in Step 1 (MBSE modeling), Simulink modeling of failure conditions and failure handling behaviors is performed, iterating the model and design logic. Design issues are identified through testing the Simulink model (checking whether the model output matches the expected results under specific model scenario input conditions) (a one-to-one correspondence between the failure modes in the Simulink model and the SysML model), and feedback is used for design iteration and corresponding model updates (including synchronous updates of the SysML and Simulink models). During the design process of the AOT system, the following system failure modes and their combinations are mainly considered (see the security analysis in Part 3 below): known failure of the instance; complete loss of instance functionality; partial loss of instance functionality; unknown failure of the instance.

[0086] For functional failures and unknown faults in instances, simulation using real components is often difficult and can only be performed in the later stages of system design (after the establishment of a real test environment). Once design problems arise and changes are needed, the costs are extremely high. However, thorough testing of the system model early on can expose design problems and allow for corresponding design modifications, enabling iterative design improvements and significantly reducing the cost of later integration and verification.

[0087] Another major aspect of designing the Simulink model for AOT is supporting virtual integration experiments on the host model. To enable synchronized and coordinated co-simulation with other models, the AOT model specifically features an interface for model mode control and corresponding mode switching functionality. The operating modes currently required to be supported by the model include:

[0088] Model loading; Model unloading; Model initialization;

[0089] Model Run; Model Hold; Model Reset;

[0090] The design of mode switching logic between models is as follows: Figure 4 As shown.

[0091] Initially, the model is typically in an unloaded state, in which it is not executable. By setting a model loading command, the model enters a loading state. This mode is a necessary prerequisite for model initialization and subsequent execution. When the model is in the loading state and is executed for the first time, it first enters the initialization state, during which preparations and related operations are performed. After initialization is complete, the model automatically enters the run mode and executes according to the preset settings. During model execution, execution can be paused by setting a pause command. In paused mode, execution can resume by setting an execute command. When the model is in execution or paused mode, execution can be restarted by setting a reset command (model initialization will not be performed in this mode). If an unload command is set while the model is in execution or paused mode, the model will unload; only the model loading command will be responded to, and the model will not respond to other control commands.

[0092] III. Qualitative Security Analysis of the Detention System

[0093] The AOT system has four software instances residing on different computer hardware (different IMA computing modules in different racks). To meet the integrity requirements of a DAL A-level system, the final output configuration data needs to be determined by a voting mechanism among the four instances (each instance votes based on its own data and the data of other instances). Considering the asynchronous operation of the four IMA computers (the power-on sequences of different IMA racks and different computing modules within the same rack are different), and taking into account scenarios such as computing module or IMA rack restarts, there can be various combinations of AOT operating scenarios (primarily affecting the voting logic between different AOT instances) and fault combinations that need to be considered in the security analysis. The AOT system design must ensure that under all the operating scenarios and fault combinations described below, the system can output acceptable results, and the probability of unacceptable output results must be sufficiently low (meeting the probability requirements of DAL A-level systems).

[0094] Possible work scenarios for AOT include:

[0095] The scenario where 4 instances are working almost simultaneously (4 computers start up almost at the same time) - ID A1;

[0096] Case A2: One instance starts early, and the remaining three instances start late (almost simultaneously).

[0097] Two instances start early (almost simultaneously), and the remaining two instances start late (almost simultaneously) (e.g., two computers in one rack restart) - ID A3;

[0098] Case A4: Three instances start early (almost simultaneously), and the remaining instance starts late (e.g., one computer restarts).

[0099] Four instances were started sequentially (not simultaneously, with the start time difference exceeding the voting time window) - ID A5;

[0100] One instance starts early, then two more instances start almost simultaneously, and finally the last instance starts - instance number A6;

[0101] Two instances start early (almost simultaneously), and the remaining two instances start sequentially (not simultaneously) - ID A7;

[0102] Two instances are started sequentially (not at the same time), and the remaining two instances are started later (basically at the same time) - ID A8.

[0103] The fault conditions include:

[0104] Four instances are normal - number F0;

[0105] Case F1: One instance has lost functionality.

[0106] Case F2: A known fault occurred in one instance.

[0107] One instance experienced an unknown failure - case number F3;

[0108] Case F4: 2 instances have lost functionality.

[0109] Two instances of known faults occurred - number F5;

[0110] Two instances of unknown failures occurred - Case number F6;

[0111] Case number F7: One instance is disabled and another instance experiences a known failure.

[0112] Case number F8: One instance is inoperable and another instance experiences an unknown failure.

[0113] Case F9: One instance experiences a known fault and one instance experiences an unknown fault.

[0114] Case F10: 3 instances of lost functionality.

[0115] Three instances of known faults occurred - number F11;

[0116] Case number F12: Two instances are out of service and one instance has a known fault.

[0117] Case number F13: One instance is disabled and two instances have known failures.

[0118] Case number F14: Two instances have lost functionality and one instance has experienced an unknown failure.

[0119] Case number F15: Two instances have known faults and one instance has an unknown fault.

[0120] Case number F16: One instance is disabled, one instance has a known failure, and one instance has an unknown failure.

[0121] By conducting qualitative security analysis of the AOT system under combinations of working scenarios and fault conditions (qualitatively assessing the worst-case security impact of system behavior under each combination), we can evaluate whether the AOT system design meets the system's security requirements and drive updates to the system design.

[0122] This invention uses a matrix diagram to describe the results of the security analysis. The rows of the matrix represent the eight operating scenarios (A1-A8) of the AOT system, and the columns represent the fault modes (F0-F16). Figure 5 Dark gray represents a combination of scenarios and failure modes that pose a security risk in the security assessment; light gray represents a combination of scenarios and failure modes that are acceptable in the security assessment after security design; and no background represents a combination of scenarios and failure modes that pose no risk in the security assessment.

[0123] Following the first round of security assessments, under the existing design, multiple combinations of operating scenarios and faults will lead to unacceptable security consequences for the overall functionality of the AOT system, such as... Figure 5 As shown, safety-related considerations need to be added to the current system design to improve the design outcome. Adding independent monitoring functionality for AOT status is a feasible safety design consideration. By monitoring AOT fault status (monitoring AOT reported faults, known faults, or AOT functional loss separately), corresponding faults can be handled safely, thereby effectively mitigating the ultimate aircraft-level safety impact caused by AOT faults.

[0124] With the addition of independent monitoring capabilities for known faults, a new round of security analysis and assessment was conducted. The overall security of the AOT system was significantly improved, and the combined security impact of all operating scenarios under the three fault modes was effectively mitigated. Figure 6 As shown, the scenarios include: 3 instances experiencing known failures, 1 instance losing functionality and 2 instances experiencing known failures, and 1 instance experiencing an unknown failure and 2 instances experiencing known failures.

[0125] Building upon this foundation, after adding independent monitoring functionality for AOT loss, and undergoing another round of security analysis and assessment, the only unacceptable failure scenarios for the AOT system across all possible operating scenarios are the following two failure modes: simultaneous unknown failures in two instances, or one instance losing functionality, one instance experiencing a known failure, and one instance experiencing an unknown failure. Figure 7 As shown. After analysis and confirmation by the security team, the probability of the above two scenarios is extremely low (which meets the security requirements of a DAL A-level system). Therefore, the risk of the system design in these two scenarios is acceptable, and from a security perspective, there is no need to add any further security design.

[0126] The proposed solution was implemented in a typical on-the-ground (AOT) application of Integrated Modular Avionics (IMA). Compared with traditional document-based system design and existing MBSE-based system design, the proposed solution has the following technical advantages and achievements:

[0127] 1. This invention is the first to apply the technical solution proposed in this paper to the design of an Integrated Modular Avionics (IMA) resident application system. It obtains the SysML model of the AOT system, which better supports detailed system design. Compared to traditional document-based system design schemes or existing MBSE design schemes, it is more suitable for iterative forward design of the system from scratch.

[0128] 2. By combining MBSE modeling of resident applications with Simulink modeling of software, a seamless process of forward design and rapid verification iteration before product implementation is achieved. This ensures that the system design and requirements have reached a certain level of maturity before detailed product design, avoiding repeated modifications to system requirements or designs during later product implementation and integration phases. Furthermore, the Simulink model can be used to support the integration and verification of digital prototypes on the host machine or the design and iteration of test cases for digital environment integration and verification in the early stages of R&D, thus better supporting host machine integration and verification.

[0129] 3. The qualitative safety analysis method based on working scenarios and fault combinations closely integrates requirements analysis and system design, providing more information for safety analysis and system design, effectively supporting the trade-offs in system architecture design, and is more suitable for the application of civil aircraft airborne integrated modular avionics system design scenarios.

[0130] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications and improvements without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be defined by the claims.

Claims

1. A model-based design method for a modular avionics dwell system for civil aircraft, characterized in that, Includes the following steps: S1. Requirements modeling and verification of resident systems based on customized MBSE method; S2. Functional logic modeling of resident application software based on Simulink model; S3. Qualitative security analysis of resident systems based on functional scenarios and fault combinations; The input to step S1 comes from the technical protocol of the resident system issued by the host. Through modeling iteration, the requirements of the resident system are captured and sent to step S2. Step S2 provides feedback on system design issues identified during the modeling process to support iterative design and updates of system requirements; Step S1 simultaneously sends the requirements of the resident system to Step S3, while Step S3 provides feedback on the identified security requirements and constraints to Step S1 to support iterative system requirements; Step S2 outputs the design information of the resident application software to Step S3, and simultaneously obtains the security constraints of the resident application software identified by the security analysis from Step S3. Step S1 divides the modeling and design work of the resident application system into two stages: the problem domain and the solution domain, and clarifies the tasks within each stage and the inputs and outputs between them. The activities within the two phases are iterated in cycles to meet the system's design requirements; the activities between the two phases are also iterated to ensure that the solution domain model and the problem domain model remain consistent.

2. The model-based design method for a modular avionics dwell system for civil aircraft as described in claim 1, characterized in that, Step S1 employs a tailored AOT system MBSE design method, dividing the problem domain modeling activity into the following steps: S11, AOT System Requirements Analysis and Modeling: Obtain customer requirements for the AOT system, and create corresponding requirement diagrams in the Magicdraw environment. Each requirement is created as a requirement object. S12. AOT System Scenario Analysis and Modeling: Establish a Use Case diagram for the AOT system and identify the working scenarios and interaction objects of the AOT system; S13. Functional Analysis and Modeling of AOT System: For various different work scenarios, analyze the functional logic or functional flow of the AOT system using activity diagrams, sequence diagrams, or state machine diagrams. S14. AOT System Architecture Analysis and Modeling: Analyze the architecture of the AOT system using class diagrams and internal structure diagrams, and identify the input / output interfaces and input / output information of the AOT system. S15. Modeling and analysis of the traceability relationship between the AOT system model and high-level requirements: Tracing the model elements with system requirements to show that the requirements are covered by the problem description.

3. The model-based design method for a modular avionics dwell system for civil aircraft as described in claim 2, characterized in that, Step S1 further includes: after the model matures, by introducing relevant parties of the AOT system to review the modeling design content, identify errors or omissions in the model, and provide key design input information so that the problem domain model can correctly describe the design problems of the AOT system; if the model is not mature enough, the problem domain modeling work is iterated, and the problem domain model of the AOT system is updated by acquiring more design information, engineering experience and design assumptions.

4. The model-based design method for a modular avionics dwell system for civil aircraft as described in claim 2, characterized in that, Step S1 divides the solution domain modeling activity into the following steps: S15. Functional Analysis and Modeling of AOT System: Analyze the functional logic or functional flow of AOT system sub-functions using activity diagrams, sequence diagrams, or state machine diagrams. S16. AOT System Architecture Analysis and Modeling: Analyze the architecture of AOT system sub-functions using class diagrams and internal structure diagrams, and identify the input / output interfaces and input / output information of each sub-function. S17. AOT System Model Simulation Verification: Based on the activity diagram or state machine diagram of the solution domain model, perform model simulation testing to check and verify the system design scheme; S18, AOT System Requirements Analysis and Modeling: Identify model content or design constraints not covered in the requirements through modeling, and convert them into system requirements for management in the requirements diagram; at the same time, establish a solution domain requirements diagram for the requirements; S19. Modeling and analysis of the traceability relationship between the AOT system model and system requirements: After iteratively updating the requirements, a traceability relationship is established between model elements and AOT system requirements in the solution domain to represent that the requirements are covered by the design solution; at the same time, a traceability relationship is also established between the requirements of the solution domain and the requirements of the problem domain; if a situation where there is no complete coverage is identified, new requirements are captured or the design is modified to achieve complete coverage of the traceability relationship.

5. The model-based design method for a modular avionics dwell system for civil aircraft as described in claim 4, characterized in that, Step S1 further includes: once the model is mature, by introducing relevant parties of the AOT system to review the modeling design content, identifying errors or omissions in the model, and providing key design input information so that the solution domain model can accurately reflect the design scheme of the AOT system, and all designs that meet customer needs are correctly captured; the solution domain modeling process is iterated multiple times, with each iteration updating the system requirements and the corresponding solution design, until all design content that meets the requirements of the problem domain is captured in the model.

6. The model-based design method for a modular avionics dwell system for civil aircraft as described in claim 1, characterized in that, Step S2 includes: First, the software architecture is designed. Based on the high-level requirements of the resident application software, a reference architecture scheme is proposed as the starting point for the iterative model design. The reference architecture needs to describe the software's module division, the basic input and output interfaces between modules, and the functional requirements of each functional module. Based on the reference architecture, the design of software functional modules is carried out. There are two cases: i) If the function of the software module can be directly implemented by the characteristic algorithm or logic, the design of the software functional module is considered to be completed. At the same time, it is necessary to identify the impact of the implementation scheme of the software functional module on the software architecture; ii) If the function of the software module cannot be directly implemented by the algorithm or logic, it is regarded as a new software black box. First, the architecture design of the black box is proposed by analysis, and then its sub-modules are designed iteratively. After the software model design matures, the architectural requirements or constraints identified in the software model design are fed back into the software architecture design to carry out overall software model architecture design iterations in order to improve the overall design of the software model; the final output of the resident application software design is the resident application software model. After the resident application software model discovers requirements or design problems, it is fed back into the MBSE modeling work to iteratively update the AOT system design and requirements.

7. The model-based design method for a modular avionics dwell system for civil aircraft as described in claim 6, characterized in that, The top layer of the resident application software model consists of the Simulink modules corresponding to the four AOT instances and the input / output interfaces for interaction between them. The lower layer of each AOT instance module is the specific software function implementation of the AOT module, including the design of the AOT fault injection interface and the model mode control interface.

8. The model-based design method for a modular avionics dwell system for civil aircraft as described in claim 1, characterized in that, Step S3 describes the security analysis results in the form of a matrix diagram; the rows of the matrix represent the operating scenarios of the AOT system, and the columns represent the failure modes; step S3, through multiple rounds of security assessment, needs to ensure that the object system outputs acceptable results under all operating scenarios and failure combinations, and that the corresponding security requirements are met with a probability for cases where the output results are unacceptable. i. With the addition of independent monitoring function for known faults, conduct a new round of safety analysis and assessment; ii. After adding an independent monitoring function for the loss of AOT function, conduct a new round of security analysis and evaluation.

9. The model-based design method for a modular avionics dwell system for civil aircraft as described in claim 2, characterized in that, The work scenarios include ground work scenarios, air work scenarios, and data loading scenarios; the interaction objects include airborne systems with input / output interfaces to the AOT system, airborne functions, and operators of various systems.

Images