Extending Model-Based Systems Engineering into Integrated Platform Designed for Civil Aircraft Development

With the continuous development and application of modeling technology, civil aircraft designers urgently need to apply model-based systems engineering (MBSE) theory and methods into the field of civil aircraft development. However, the existing modeling tools, which combined with MBSE methodologies, only focus on one particular area, such as requirement modeling, functional modeling and design synthesis. This kind of low coupling design system makes it difficult to link the upstream and downstream designers in the early stage of system development. This paper introduces the MBSE development process of civil aircraft and then establishes an integrated platform composed of six work stations for civil aircraft development based on this process. Commercially available modeling tools, such as IBM Rational DOORS and enterprise architect (EA), are conducted in the platform. The development of flight control system is taken as an example to test the feasibility and efficiency of our integrated platform in logic layer. This platform can complete the activities of aircraft life cycle function analysis, requirement and model management. The loose coupling between the modules and the high cohesive nature allows different system engineers to maintain their design independence and consistency at different stages of development.


INTRODUCTION
Civil aircraft development is a complex system engineering problem, including the identification and capture of stakeholders and system requirements, establishing functional structure of aircraft systems and the derivation of functional analysis (Anderson 2009; Mordecai et al. 2018;Zhang et al. 2018). The entire research and development (R&D) process involves various stakeholders, professional tools in different subjects, constraints between different system functions, as well as interactions between hardware and software. Model-based system engineering (MBSE) has been used in many complex systems engineering fields, such as aircraft design, weapon system development and embedded system development (Anwar et al. 2017(Anwar et al. , 2019(Anwar et al. , 2020Madni and Sievers 2018;Ramos et al. 2011).
The novelty of our platform lies in the integration of MBSE concepts and methods, in the form of LAN database connection to replace the traditional text file transmission, which allows different system engineers to maintain design independence and consistency at different stages of development. Also, the integration of requirement management, functional modeling and process management can establish traceability between requirements, functions and design products, which is not available in a single modeling software, such as IBM rational rhapsody, MagicDraw and EA. In addition, the integration of commercial software can be replaced in the subsequent development work with a certain degree of independent intellectual property rights and adaptability for different projects.

CIVIL AIRCRAFT DEVELOPMENT PROCESS BASED ON MBSE
Systems engineering is an interdisciplinary field between engineering and engineering management which focuses on how to design and manage complex systems over their life cycle. Figure 1 shows the typical system engineering workflow.
As shown in Fig. 1, considering requirements as the beginning of system design, stakeholders and shareholder requirements are also the ultimate goals and constraints of design and development in the whole life cycle. The requirements and development constraints are determined through requirement analysis. Then the analysis and allocation of functions are carried out, decomposing the functions to the next level and defining the functional interfaces. After that, the functional architecture is designed and used as input to the comprehensive design, defining alternative system solutions, configuration items, physical interfaces and output physical architecture. Products which ultimately meet customer needs are iteratively obtained through all levels of design confirmation processes (Hoffmann 2011).
However, the traditional texted-based system engineering is becoming more and more difficult to satisfy the complex system engineering requirements, when MBSE has emerged (Andersson 2009;Dickerson and Mayris 2013;Madni and Sievers 2018). Model-based system engineering is very different from traditional TSE methods in the design and development of large-scale civil aircraft. The main differences, also the advantages, can be summarized as follows: Firstly, in the requirements development process, the requirements are linked to models which describe the system behavior (dynamic) and structure (static) of the operational scenario. The relationship between requirements and models is realized through the model traceability link, association matrix and other processes. This process should ensure that requirements can be accurately identified and decomposed, and traceability relationship can be established with the function of the system (Topper and Horner 2013).  Secondly, in the detailed design of the system, the activities and states of the system are described by intuitive model diagrams.
The integrity, coordination and compliance verification of the system functional descriptions can be illustrated through the simulation of the system models, so that the verification and validation can be finished simultaneously with design development.
By using this design architecture, it is ready to avoid the continuous impact of the system top-level requirements/design errors on subsequent development (Bozhi and Haomin 2013;Chi et al. 2017;Holt et al. 2015).
Thirdly, extending the system engineering method, MBSE implements the association of the requirement model to the system model.
Through the continuous decomposition and expansion of the model, which describes the system and its simulation operation, the forward and consistent development of the system can be realized. Using requirements as constraints and target nodes, the process from use case analysis (task scenario analysis), functional analysis, architecture design (technical path and functional model framework for system function implementation) to physical design (physical implementation form of logical architecture) can be realized. Finally, the model simulation is performed to verify the compliance with the design and requirements within the system life cycle (Cloutier et al. 2014).
Combined with the typical MBSE workflow and the V model, this paper proposes a requirement-based MBSE civil aircraft development process as shown in Fig. 2. This process is a collection of practices that integrates system engineering personnel with work product definitions. After the project is launched, stakeholder requirements, system requirements, architecture analysis and design are transferred to downstream projects, which will be performed in coordinate with the specifications. The difference from the traditional V process is that when there are more top-level requirements, usually the stakeholder requirements, the activities are repeated several times and the development engineering data is incrementally transferred to the downstream project for more detailed development. By using this cycle, we can directly connect the stakeholder requirements with the bottom layer of development, updating products more satisfying and acceptable to the market.
In the following sections, this paper designed the civil aircraft MBSE integration platform and verified with the civil aircraft FCS, using commercial software DOORS to capture the airworthiness requirements and importing to the requirement management and analysis platform for requirements analysis. According to the operational scenario of the FCS, the UML class diagram is used to establish the scenario model and structuralize the functional network. The activity diagram (ACT) is used to describe the internal activities of the FCS. The block definition diagram (BDD) and the internal block diagram (IBD) are used to describe its internal organization. This top-down incremental iteration method can closely combine requirements with functions, simulation and verification, establish traceability of requirements and significantly shorten the development cycle of civil aircraft.

ARCHITECTURAL DESIGN AND IMPLEMENTATION OF THE INTEGRATED PLATFORM
In order to realize the aforementioned process, the platform architecture design has been established, which is shown in Fig. 3. The platform enables all functional modeling development, verification/evaluation and requirements management, also the integration of functional modeling analysis at the aircraft level. This architecture is based on the MBSE methodologies and proposed in conjunction with the development process of the civil aircraft. From this architecture, the hardware platform modules can be extracted as follows.
As shown in Table 1, there are a total of six platforms/stations. The requirement management and analysis station (RMAS) is used to analyze, verify and review the requirements, which have been imported from outside of the system or created inside the platform. The functional structure and analysis station (FSAS) receives system requirements from RMAS and connects civil aircraft operation scenario with system requirements and build a requirement oriented civil aircraft functional network structure. Inside the functional structure, System Modeling Language (SysML) and commercially available software EA are used to describe its behaviors and structures. During this whole procedure, the Process Management Station (PMS) is used for risk management when requirement changes and the Integrated Display Station (IDS) is used to display the overall project progress and two databases are integrated into the platform simultaneously for model management and data interaction.  The specific information flow labeled in solid line is shown as follows. As an instruction for Fig. 5.
1. Requirements can be either created inside or imported from outside of the platform.

2.
The rich text format (RTF) report is exported from the requirement database to the RMAS for generating the verification word report and the CSV format file exported from DOORS, which describes the detailed requirements information, is for the requirement editing and modification.

3.
Requirements are imported into the FSAS in CSV UTF-8 format for constructing the functional network structure and functional analysis.
4. The functional model established in the FSAS are exported into the model database in XML format for data interaction. 5. The complete and incomplete functional models can be extracted from the model database to the FSAS still in XML format. 6. The functional models connected with system requirements are exported to the PMS for risk assessment and requirement coverage calculation. 7. The test reports describing the completion of the functional flow by FSAS are exported to the requirement database. 8. The verification reports are exported in Word format and the requirements in the RMAS are synchronized to the requirements database in CSV format. 9. Trace the completion of requirements and display them in IDS. Began with RMAS, we captured stakeholder requirements and converted to system requirements. With certain modification exported to FSAS, we connected civil aircraft operation scenes with system requirements and built a requirement-oriented civil aircraft functional network structure. System modeling language was used to describe its behaviors and structures.

7
The completion of requirements was calculated and exported back to RMAS to generate the requirement verification report. During the whole procedure, the PMS was used to control project risk when requirement changes. Integrated display station was used to display the overall project progress and the two databases were integrated into the platform simultaneously for model management.
The existing modeling tools, such as IBM rational rhapsody, EA and MagicDraw designed for the system development are hardly able to establish the traceability among stakeholder requirements, system requirements, functional requirements, functional model and downstream design products. Thus, our platform focusses on the whole process of civil aircraft development instead of requirements or functional modeling only, which significantly improves the development efficiency of the complex system by integrating requirements, models and processes in one single design system. Through the distributed but integrated way to achieve the system architecture, we can improve the participation of all system related designers at the early stage in system design.

PLATFORM VERIFICATION OF CIVIL AIRCRAFT FLIGHT CONTROL SYSTEM
Typical civil aircraft systems include FCS, Landing Gear System (LGS), Environmental Control System (ECS), Fuel System and Fire Protection System (FPS). Modern civil aircraft FCS is the core of the whole aircraft airborne system, and it is also one of the most complex systems of the whole aircraft. Thus, here we chose FCS as the target case study to verify the aforementioned development process and platform.
Based on the previous research of civil aircraft development process and integrated platform, this section carries out the research on MBSE requirements and functional modeling for the FCS of civil aircraft. The verification process is mainly divided into the following three steps: 1. According to the airworthiness requirements of the FCS, the requirements template is defined by (DOORS eXtension Language) DXL language and loaded into DOORS for further editing. 2. Using the scene meta-model, a class diagram is created in the EA to describe the operational scenario of the FCS. Based on the function of the FCS, a use case model of the flight scenario is established. 3. According to the relationship between functions and different scenario, the corresponding requirements are associate with functional network. The ACT is used to describe the activities (dynamic) of the FCS, the BDD and the IBD are used to describe its internal organization structure. Finally, the effectiveness and correctness are verified by logical simulation. The first step is finished in RMAS and the last two are complete in FSAS with two databases participated in the whole process. In the MBSE requirement and functional modeling of the civil aircraft FCS, the PMS is used to display the coverage of the requirements, identifying and managing the risk in the iteration process and the completion report of the project is realized on the IDS. This section applies the civil aircraft MBSE integrated platform, taking the FCS as an example to test the feasibility and efficiency of our integrated platform for further development and verification. In the meantime, the databases integrated in this platform are created in SQL Server 2008. And the tables are created in binary format to store the models and requirements into the databases in their original format of XML and CSV.

Flight control system requirements modeling
Requirement is the first to be analyzed and defined in civil aircraft design process. Requirement modeling involves two steps: requirement capture and requirement analysis (Bourque and Fairley 2014) and the requirement capture process can be generally decomposed by the following two steps:

Identify the stakeholder
Stakeholders refer to any living or nonliving bodies that are affected by the system. Currently, the domain method is to divide the relevant stakeholders into affirmative stakeholders, prospective stakeholders and potential stakeholders according to the number of stakeholders' legality, rights and urgency attributes to the company. And this classification method is easier to implement in operation. For civil aircraft development, the affirmative stakeholders are mainly aircraft developers, civil aviation companies, civil aviation bureaus, airports, government departments, pilots and various flight attendants. The prospective stakeholders are mainly the people who have boarded the aircraft and the competitors and the potential stakeholders are mainly all the citizens (Chi et al. 2017;Bozhi and Haomin 2013).

Capture the stakeholder expectations (requirements)
After identifying the stakeholders of the project, the original needs have to be obtained from the stakeholders through various research techniques. Typical research techniques include field research, questionnaires, interviews and joint requirements planning (JRP).
In order to design the system, detailed and formal definitions of these stakeholder requirements are required to obtain aircraft-level requirements. The analysis of civil aircraft requirements is to translate the requirements and constraints put forward by stakeholders into a language that the system designers can understand. Converting these languages into the functions and constraints required by the system and then provide a detailed theoretical basis for the subsequent system design.
Users can extend the DOORS function based on DXL, not only to extend the DOORS user interface in the form of plug-ins, but also to support programmatic integration with peripheral systems. For end users, DXL can be used to develop applications that seamlessly interface with graphical user interfaces (Wei 2012). The requirements modeling process is completed in the RMAS and template is edited with DXL language and loaded into DOORS for improvement. As shown in Fig. 6, according to the airworthiness requirements, the FCS requirements template is written in DXL language and loaded into DOORS to complete the requirements modeling.

Flight control system functional network structure modeling
The development of functional network structure is based on the capture of operational scenario, which is the direct environment for identifying and confirming the requirements. Therefore, the analysis and development of operational scenario is an important activity of system engineering. A scenario encompasses the expected behavior of a system or system of systems, and all activities of the system are generally not adequately described by a single scenario. Thus, a behavioral model built on a single scenario only describes the lower bounds of the expected behavioral boundaries of the system. The attribute is a description of the characteristics that the system behavior must conform to, and provides the upper limit of the behavior boundary for the behavior modeling of the expected system based on attribute completion. This paper uses the scenario meta-model to establish the basic three operational scenarios for the FCS, which are flying, environment and failure. And the flying scenario is shown in Fig. 7. After establishing a functional model, it is necessary to confirm and supply the requirements to some extent. This paper uses SysML to complete the initial modeling of the FCS and uses the ACT to describe the system activities. The BDD and IBD are used to describe the internal organization of system. Finally, the correctness is verified by simulation.

Flight Control System ACT
The typical FCS consists of three parts: the rudder circuit, the stabilization circuit, and the control circuit. A steering gear, a feedback component and an amplifier build up the rudder circuit, which is used to improve the quality of the steering gear to meet the requirements of the FCS, and the rudder circuit is essentially a follow-up system that keeps the output signal synchronized with the input signal. The measuring component that measures the aircraft's flight attitude plus the rudder circuit constitutes the AP. The AP and the controlled object (aircraft) form the stabilization circuit, which is mainly responsible for track stability and aircraft flight attitude control. The control circuit consists of a stabilization circuit, a kinematics section describing the geometric relationship of the aircraft's spatial position, and a position measuring component of the center of gravity of the aircraft, which is responsible for stabilizing and controlling the trajectory of the aircraft (Sentang and Yuhua 2005).
The above-mentioned control method is currently used by most aerospace vehicles, and the FCS ACT is built upon this, as shown in Fig. 9. Note that the Fork/Join node in Fig. 9 represents synchronous execution, that is, synchronously executing the deflection rudder surface and measuring feedback information after driving the steering gear; after the aircraft motion is controlled by the rudder surface deflection the calculation of the kinematics of aircraft space position and the measurement of the track attitude are simultaneously performed. The control circuit is responsible for judging the exit condition, which is whether the current height h is equal to the expected height H, and the guards of the two exits are: [H==h] and [else], respectively.
The acquisition of the driving rod instruction, the aircraft attitude deviation calculation, and the angular position rate deviation calculation in Fig. 9 belong to the action, while the other rounded rectangles represent the activity. The activity in the ACT can create a child diagram, such as a Composite Structure Diagram, an ACT, a State Machine; and Action as the smallest unit of the ACT can only add Child Elements, such as Operation pin (Action Pin). The angular position rate deviation calculation operation completes the control signal calculation of the rudder circuit (achieved by the Effect of the Action unit), and the eccentric angle of the rudder surface is obtained by inverse Fourier transform, and is transmitted to the rudder surface via the amplified signal.  Figure 9. Flight Control System ACT.

12
In order to improve the reliability of the teletype control system, the redundancy technology is widely used in the design of the steering gear in the design of modern civil aircraft. For the driving servo activity in Fig. 9, a subdiagram as shown in Fig. 10 is constructed as a complex combination structure diagram of the double redundancy steering gear. The two channels of the servo are composed of a potentiometer, a power amplifier, etc., and the output of the two-channel motor shaft is collectively referred to as one by using a speed reduction mechanism. The digital servo controller also undertakes servo control and margin management. The controller can control the servo motion of the servo by integrating the output signal of the position sensor (Zhou et al. 2017

Flight Control System BDD
The FCS is generally composed of a sensor subsystem for measuring the flight state of the aircraft, a computer subsystem for performing data processing and transmitting control commands, a servo actuating subsystem for driving the deflection of the control surface, a control display subsystem for the human-computer interaction interface, and an internal self-test subsystem. The typical civil aircraft FCS generally includes five subsystems: a flight control computer system, a servo actuation system, a sensor system, a control display system and an internal self-test system.
The BDD of the FCS is shown in Fig. 11, and its subsystems typically have three or more design margins. The redundancy information is represented in a multiplicity manner in the BDD. As illustrated in Fig. 11, the flight control computer subsystem (fccs) and the FCS are aggregated. [+ fccs2.4] indicates that the FCS has 2 to 4 computer subsystems, and + indicates that the access rights are public.  Figure 11. Flight Control System BDD.

Flight Control System IBD
The IBD describes the blocks inside the system, the nesting relationship between the blocks, the information exchange between the blocks, and the data interface between the system and the external, as shown in Fig. 12. If the FCS fails in a short period of time, a mechanical backup of the rudder and horizontal stabilizer is used to complete the safe flight and landing mission of the aircraft. The computer automatically assigns system tasks, and when one computer processes the task, the other computers are in standby. When the working computer is damaged, another replacement work is arranged in accordance with a pre-set priority order, and the switching process does not cause a sudden deflection of the steering surface.

Process Management and Integrated Display
The PMS platform is based on C++ language. It controls project activities, including the following three nested parallel tasks. 1. Overall progress of the project and traceability of requirements; 2. Project pending issues include problem descriptions, applying metrics, and handling project issues; 3. Propose solutions to project problems and carry out risk assessment; conduct daily meeting, coordinate design and management team to reach short-term task consensus. The PMS is used to store, mark and classify the FCS model established by the MBSE process in the model database, and display the coverage of the requirements in a certain scenario, achieving the traceability from functions to requirements. Risk identification and management of the project during each iteration, prioritizing high-risk activities.
The IDS is mainly responsible for displaying the engineering progress of the MBSE integrated platform, including presenting the work content of other platforms, querying the person in charge of a certain requirement and progress, as well as visualization of engineering data.

CONCLUSION
Based on the V model of traditional system engineering, this paper designed the requirement-based civil aircraft MBSE Research and Development process and built an integrated platform with six work stations, including all the activities in the development process of complex system. The functions of the platform and all six stations as well as the information flow have been fully discussed. Based on our platform, the requirement modeling, functional modeling and process management were completed for the civil aircraft flight control system. The test results showed the feasibility and efficiency of our platform in complex system development. The comparison with existing modeling tools and integrated platforms verified the advantages of our platform.