Modeling and analysis of civil aircraft top level RNP system architecture

In recent years, the international aviation organization has implemented new performance-based navigation technology and issued the operational requirements of required navigation performance (RNP). It involves the cross-linking of multiple complex systems, which puts forward higher requirements for aircraft development and management. In this paper, the development process of RNP functional architecture model is defined by using magic grid software. The modeling is completed from three aspects: problem domain, solution domain and implementation domain. The decomposition and implementation of complex functions are completed from top to bottom. This method can effectively solve the complexity problem of civil aircraft system, and lay the foundation for demand-based model forward design.


Introduction
At present, most civil aircraft in China conduct navigation and airport approach by receiving the guidance signal from the ground navigation station. In this navigation mode, route planning and flight procedure design are constrained and restricted by the ground navigation station, and lack of economy, flexibility and efficiency. With the continuous updating, increasing complexity and accuracy of aircraft airborne equipment, the navigation accuracy is getting higher and higher. The international aviation organization has implemented new performance-based navigation technology and issued the operation requirements of required navigation performance (RNP). That is to say, under the corresponding navigation infrastructure conditions, the aircraft must determine the navigation performance accuracy when operating in a certain airspace, route or terminal area.
RNP not only puts forward relevant operation requirements for aircraft airborne navigation equipment (such as FMS), but also puts forward corresponding requirements for navigation system (such as GPS) supporting corresponding RNP airspace. It involves the cross-linking of multiple complex systems and puts forward higher requirements for aircraft development and management. After comprehensive weighing, it is proposed to be based on mbse concept and ARP 4754a aircraft development process model, using modeling software to carry out the functional architecture modeling of RNP system architecture design.

Selection of modeling software and methods
MagicGrid is a system architecture based on SysML language, which has strong mathematical basis, can adapt to different systems and tools, and can be updated flexibly according to the changes of system or environment. According to the modeling process of MagicGrid, the development process of RNP functional architecture model is defined, including the problem domain, solution domain and implementation domain. (1) The problem domain is divided into two parts: black box and white box. The interaction between the system and the outside is viewed from the perspective of black box, and then the function is analyzed from the perspective of white box, and the internal module diagram (IBD) interaction of the logic subsystem is constructed.
(2) The solution domain is divided into multiple levels from the top to the bottom of the system layer, and the solution architecture of the system is designed in multiple detailed levels.
(3) The implementation domain is not a part of MBSE except for the requirements specification, so it appears outside the scope of the MagicGrid method.

Figure 1 MagicGrid modeling process matrix
As you can see from the figure, each domain definition includes four different aspects of the system to be considered and captured in the model. These aspects match the four pillars of SysML: requirements, behavior, structure, and parameters. The cell at the intersection of a row (field) and a column (pillar) represents the view of the system model, which can be composed of one or more presentation components. A representation component can be a graph, a mapping matrix, or a table.
It should be pointed out that this project adds the "physical architecture" package in the solution domain of the above MagicGrid process, establishes the allocation from logical architecture to physical architecture, and describes the physical architecture.

3.Problem domain of RNP system architecture modeling
This paper analyzes the regulatory documents of airworthiness authorities and industry standards related to RNP operation, including but not limited to RTCA technical documents and AC Advisory notices, so as to support the capture of aircraft level requirements related to RNP operation. Requirements capture and definition are divided into three levels The "initial stakeholder needs" of T0 layer mainly combs the basic requirements for RNP operation according to the above standards and specifications as the input of modeling; the "updating stakeholder needs" of T1 layer updates the stakeholder needs according to the analysis of system black box behavior in the black box analysis stage; the "RNP system requirements" of T2 layer is based on the white box function after the white box modeling is completed .Analyze and sort out the aircraft level requirements of RNP system. Examples are as follows:

Solution domain of RNP system architecture modeling
Once the problem domain analysis is completed and the stakeholder needs are transferred to the model, the analysis solution domain can be considered. The purpose of the solution domain is to provide one or more solutions to the problems defined by the problem domain. The solution domain needs to analyze the system logic, design the precise model of the system, and even design several different system solutions. For these solutions, trade-off analysis can be carried out to select the best solution to implement the system.

RNP system requirements
After the preliminary function analysis of RNP system based on black box and white box activity diagram, the RNP system requirements need to be defined based on updating stakeholders. After the completion of the model, the requirements need to be allocated to model elements to realize the allocation of requirements to subsystems.

Subsystem design
Through the analysis and integration of RNP system requirements, the system behavior and structure models of 12 subsystems, such as GNESS, NAV and FCM, are established. Now take NAV as an example

Subsystem behavior
NAV subsystem receives the positioning information from GPS, IRS, ads, radio and other navigation systems, and judges its availability, so as to determine the aircraft navigation mode. On this basis, the navigation data fusion is completed to obtain the optimal positioning results, and the actual navigation performance of the navigation mode is calculated. Finally, the navigation sensor status and navigation results are output to other subsystems, and the activity diagram is as follows.

Subsystem Structure
CI_ FMS_ NAV configuration items are mainly composed of navigation mode management, data fusion, navigation performance calculation module and input / output management module. CI_ FMS_ The block definition structure of Nav configuration items is as follows: Figure 3 CI_ FMS_ Internal IBD diagram of Nav configuration item

Implementation domain of RNP system architecture modeling
For RNP system, the allocation from logical architecture to physical architecture is established, and the relationship between specific physical architectures is defined. The logical modules are finally allocated to various physical devices. Figure 4 is the physical device definition diagram of RNP system. After the association between logical configuration items and physical devices is completed, the cross-linking relationship of the corresponding physical architecture is constructed, and the RNP system configuration item IBD is determined. As shown in Figure 5 below. Figure 5 IBD diagram of physical architecture

Summary
This paper describes the modeling process and results of RNP system functional architecture based on magicgrid process. In the solution domain, a design oriented RNP subsystem is established based on the configuration items in the aircraft development process. The problem domain subsystem is mapped to the solution domain subsystem, and the behavior and structure model of the configuration item subsystem is established based on the activity diagram and IBD diagram. Finally, the physical architecture of the system is defined, and the logical subsystem is allocated to the physical architecture. This method has been successfully applied to the development of civil aircraft model, solved the complexity problem of civil aircraft system, and laid the foundation for demand-based model forward design.