MBSE-based civil aircraft cabin door signal system modeling method and system

Abstract

The invention discloses a civil aircraft cabin door signal system modeling method based on MBSE, and the specific operation comprises the following steps: (1) building an operation analysis layer of a cabin door signal system, analyzing the operation condition of the system in a real environment, and defining the context and operation scene of the system; (2) establishing a system analysis layer of the cabin door signal system, identifying functional requirements and non-functional requirements which need to be met by the system, and determining targets of the system; (3) establishing a logic architecture layer of the cabin door signal system, designing logic components of the system on the basis of system analysis, and describing functional modules and mutual relations thereof; and (4) establishing a physical architecture layer of the cabin door signal system, converting a logic architecture into specific physical implementation, and defining hardware and software components. According to the method, a complete civil aircraft cabin door signal system model is constructed, the risk and the problem of traditional document-based requirements are effectively avoided, and fusion between a system architecture and all determined requirements is facilitated.

Description

Technical Field

[0001] The present invention relates to the technical field of civil aircraft electrical system design, and in particular to a civil aircraft cabin door signal system modeling method and system based on MBSE. Background Art

[0002] The cabin door signal system of civil aircraft adopts a centralized control architecture, and the system uses the proximity sensor electronic unit PSEU as the main controller. High-precision magnetic flux sensors arranged on each door and its mechanism of the fuselage are used as the core detection elements, supplemented by terminal indication components such as display panels and indicator lights installed on and near the cabin doors, to achieve status monitoring of the entire aircraft's boarding doors, service doors, emergency doors, cargo doors, E / E doors, cockpit emergency doors, refueling caps, slide pre-position status, and cabin door flight locks, as well as comprehensive alarm indications. In addition, the cabin door signal system also has flight lock lock / unlock control functions, cargo door actuation system power supply control functions, and in-flight self-detection functions. The architecture of the cabin door signal system of civil aircraft is as follows: Figure 1 shown.

[0003] With the increasing complexity of the door signal system of civil aircraft, the traditional document-based system engineering design scheme has become increasingly difficult to meet its design characteristics of multi-disciplinary collaboration and rapid iteration of design schemes. There are problems such as non-standard text requirements that make it more difficult to verify its consistency and integrity. In addition, they are limited to expressing requirements, which makes it difficult to describe solutions and understand their complexity, and it is also difficult to organize the development process. Model-based system engineering (MBSE) can solve the above problems to a large extent. MBSE describes the system through models, including the whole process of system function definition, requirement analysis, and system architecture comprehensive design. MBSE starts with the system requirement analysis and uses models to express the system. By processing the model, the system is gradually refined and optimized. Due to the introduction of the model description, the traceability between the various stages is strengthened. When each requirement or function changes, there is no cumbersome text to describe the function, data, and relationship. Instead, there are clear models, direct interactions between models, and corresponding relationships between the various stages. By processing the model, the entire system process is gradually established, which also makes the connection between the various subsystems closer. Summary of the invention

[0004] The present invention relates to a modeling method and system for a cabin door signal system of a civil aircraft based on MBSE, aiming to improve the design efficiency and accuracy of the cabin door signal system. The present invention adopts Capella, an open source platform based on the MBSE standard, for systematic modeling, and by establishing a unified model, a clear definition and traceability of requirements are achieved throughout the design process. The model integrates functional requirements, logical components, physical components and their corresponding relationships, ensures consistency and verifiability during the system design process, intuitively displays the architecture and behavior of the cabin door signal system, facilitates optimization of design decisions, reduces design error rates, and thus improves system safety and reliability.

[0005] The present invention is achieved through the following technical solutions:

[0006] A modeling method for a door signal system of a civil aircraft based on MBSE, the specific operation includes the following steps:

[0007] (1) Establish the operation analysis layer of the door signal system,

[0008] Analyze the operation of the system in a real environment and define the system's context and operation scenarios;

[0009] (2) Establish the system analysis layer of the door signal system,

[0010] Identify the functional and non-functional requirements that the system needs to meet and clarify the system's goals;

[0011] (3) Establish the logical architecture layer of the door signal system,

[0012] Based on system analysis, design the logical components of the system and describe the functional modules and their interrelationships;

[0013] (4) Establish the physical architecture layer of the door signal system,

[0014] Translate the logical architecture into a concrete physical implementation, defining the hardware and software components.

[0015] As a preferred embodiment, the step (1) establishes an operation analysis layer of the cabin door signal system, which is used to identify the usage scenarios of the cabin door signal system, such as passenger boarding, cabin door opening and closing, to ensure the understanding of the external environment and user needs. The specific implementation includes the following steps:

[0016] Define the system context:

[0017] Determine the external environment of the door signal system and related systems (such as flight control system, passenger service system);

[0018] Describe the system boundaries and clarify which parts belong to the door signal system and which parts belong to the external system;

[0019] Identify stakeholders:

[0020] Identify stakeholders related to the door signaling system (e.g. pilots, passengers, maintenance personnel);

[0021] Gather their needs and expectations and ensure that the system design meets those needs;

[0022] Analysis operation scenario:

[0023] Identify how the door signaling system operates in different operational scenarios, such as: door opening and closing, signal processing in emergency situations, and signaling during passenger boarding and disembarking;

[0024] Draw activity diagrams or sequence diagrams for each scenario, detailing the system's behavior and interactions;

[0025] Define operational requirements:

[0026] List the specific operational requirements that the door signal system needs to meet in each operational scenario, including functional requirements (such as status indication, alarm) and non-functional requirements (such as response time, reliability);

[0027] Identify key events:

[0028] Identify key events that affect the operation of the door signal system, such as door anomalies and signal failures;

[0029] Analyze the impact of these events on system functionality and users;

[0030] Build a use case model:

[0031] Create a use case diagram to describe the main use cases of the door signal system (such as "monitor door status", "send enable signal") and their relationship with stakeholders;

[0032] Edit a detailed use case description for each use case, specifying its preconditions, triggering conditions, and postconditions.

[0033] As a preferred embodiment, the step (2) establishes a system analysis layer of the door signal system, which is used to define key functions of the door signal system, such as door status monitoring and signal transmission, to ensure the integrity and consistency of the functions. The specific implementation includes the following steps:

[0034] Create a system analysis view:

[0035] Add a new "System Analysis" view to the project as the basis for the system analysis layer;

[0036] Define functional requirements:

[0037] In the "Requirement View", list all functional requirements related to the door signal system, including main functions (such as door status monitoring, signal processing) and non-functional requirements (such as safety, reliability);

[0038] Building a functional architecture:

[0039] In the "Functional Architecture View", identify and create the main functional modules of the door signal system;

[0040] Layer the functional modules and clarify the responsibilities and functions of each module;

[0041] Define functional relationships:

[0042] Use the "Function Chain View" to establish the relationship between function modules and describe the input, output and interaction logic;

[0043] Determine the calling relationship of each functional module to ensure the correctness of information flow;

[0044] Identify data needs:

[0045] In the "Data Flow View", define the data types and data flows required by the system to ensure that each functional module can obtain and process the required data;

[0046] Build the state model:

[0047] In the "State View", define the state changes of the door signal system, such as the different states of the door (open, closed, locked) and their transition conditions;

[0048] Use case refinement:

[0049] In the "Use Case View", refine the use cases in the previous layer and clarify how each use case implements the corresponding functional requirements;

[0050] Add detailed scenario descriptions for each use case, covering both normal operations and abnormal situations.

[0051] As a preferred embodiment, the step (3) establishes a logical architecture layer of the door signal system, which is used to construct a logical model of the door signal system, define the role of each functional module (such as proximity sensor, controller) and its interaction mode, and the specific implementation includes the following steps:

[0052] Create a logical schema view:

[0053] Add a new "Logical Architecture" view to the project so that you can build the logical architecture model in this view;

[0054] Define the logical components:

[0055] Identify and create the main logical components (such as control units, sensors, indicators) according to the functional requirements of the system analysis layer;

[0056] Define the function and role of each component;

[0057] To establish component relationships:

[0058] Use the "Structure Diagram" view to describe the relationships and interactions between logical components;

[0059] Determine the flow path of data and control signals to ensure the coherence of the logical architecture;

[0060] Define the interface:

[0061] Define the interface for each logic component, including input and output signals;

[0062] Clarify the communication protocols and data formats between components;

[0063] Build a state machine model:

[0064] Establish state machines for important logic components (such as control units) and define their behaviors and transition conditions in different states;

[0065] Identify key features:

[0066] Identify the key functions of each logical component to ensure that each component can meet the overall needs of the system.

[0067] As a preferred embodiment, the step (4) establishes a physical architecture layer of the door signal system, which is used to describe the actual components of the door signal system, such as sensors, actuators, and control units, and to clarify the interfaces and communication methods between the components. The specific implementation includes the following steps:

[0068] Create a physical schema view:

[0069] Add a new "Physical Architecture" view to the project so that you can build the physical architecture model in this view;

[0070] Define the physical components:

[0071] According to the logical components in the logical architecture diagram, identify and create corresponding physical components (such as actual sensors, controllers, and indicator lights);

[0072] Define the function and role of each physical component;

[0073] To establish component relationships:

[0074] Use the "Physical Structure Diagram" view to describe the connection relationship between physical components;

[0075] Determine the communication method (e.g., wired, wireless) and data flow between physical components;

[0076] Define the interface:

[0077] Define interfaces for each physical component, including electrical interfaces, data interfaces, and control interfaces;

[0078] Clarify the protocol and data format of the interface to ensure compatibility between components;

[0079] Identify hardware requirements:

[0080] Determine the hardware resources required for each physical component, such as power requirements, size, and weight;

[0081] System integration considerations:

[0082] Consider system integration issues in the physical architecture diagram to ensure that the physical components can work together effectively;

[0083] Identify possible integration challenges and plan solutions;

[0084] Verification and review:

[0085] Review physical architecture diagrams with team members and stakeholders to ensure accuracy and plausibility of physical components and connections, and make necessary revisions and adjustments based on feedback.

[0086] Beneficial effects: This technology adopts Capella, an open source platform based on MBSE standards, and builds a complete civil aircraft door signal system model by integrating four working levels: operation analysis, system analysis, logical architecture, and physical architecture. It effectively avoids the risks and problems of traditional document-based requirements and helps to integrate the system architecture with all identified requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0087] Figure 1 This is the architecture diagram of the door signal system for civil aircraft;

[0088] Figure 2 It is a flow chart of the door signal system modeling method based on MBSE;

[0089] Figure 3 It is the operation architecture diagram of the hatch door signal system;

[0090] Figure 4 It is the system architecture diagram of the hatch door signal system;

[0091] Figure 5 It is the logical architecture diagram of the hatch door signal system;

[0092] Figure 6 This is the physical architecture diagram of the hatch door signal system. DETAILED DESCRIPTION

[0093] The following is a detailed description of an embodiment of the present invention in conjunction with the accompanying drawings: This embodiment is implemented on the premise of the technical solution of the present invention, and a detailed implementation method and a specific operation process are given, but the protection scope of the present invention is not limited to the following embodiments.

[0094] 1. Establish the Operational Analysis (OA) layer of the door signal system:

[0095] Analyze the operational user's problem by identifying the parties that must interact with the door signaling system, including their activities and the interactions between them. Specific implementation method:

[0097] Provide a comprehensive description of the requirements of stakeholders of the door signal system and identify the operational capabilities of the door signal system.

[0098] Create the operational capabilities, operational entities / executors of the cabin door signal system, and the relationships between these structural elements, and link the operational capabilities to the entities / executors in the domain under discussion. The operational entities of the cabin door signal system of civil aircraft include: proximity sensor electronic unit PSEU, proximity sensor and display components, etc.; the operational activities include: providing cabin door status indication function, providing flight lock locking / unlocking control function, providing cargo door actuation system power supply control function, providing cabin residual pressure indication function, providing slide status indication function, etc.

[0099] Create a set of operation activities linked together by mutual relationships for each operation capability of the door signal system, and bring all operation activities together. Assign operation activities to operation entities or executors in the operation analysis. Taking the door status indication function as an example, the proximity sensor electronic unit PSEU sends an excitation signal to the proximity sensor, and continuously solves the corresponding relationship between the magnetic flux and the relative displacement of the mechanism between the proximity sensor and the corresponding target. When the relative physical displacement of the mechanism calculated by PSEU is greater than the set approach-distance conversion point, PSEU determines that the sensor has moved away from the target. At this time, PSEU will perform operations according to the set system alarm logic, and send the alarm status information to the indication recording system through the bus, and finally issue an alarm indication on the aircraft crew alarm system CAS and the schematic page. The operation architecture of the door signal system is as follows: Figure 3 shown.

[0100] 2. Establish the system analysis layer (SA layer) of the hatch signal system:

[0101] External functional analysis, as a response to identifying the system functions required by users (such as "collect sensor signals" and "issue alarm indication"), is restricted by the required non-functional attributes. Specific implementation method:

[0103] Initialize the system layer, utilize the modeling work that has been done in the operation layer, obtain the system layer functions from each operation activity through the function conversion between the operation layer and the system layer, or obtain the system layer executor from each operation layer entity / executor, etc.

[0104] Decompose some functions of the cabin door signal system and then partially assign them to the system. Only "leaf" functions (those that cannot be decomposed) have input / output ports, so once the function is decomposed into sub-functions, the functional interaction must be assigned to the sub-functions that are subordinate to the parent function. Based on the detailed analysis of the scenario and data flow diagram, the aircraft-level function of "providing and controlling normal external entry and exit for passengers" can be decomposed into four system-level functions: "monitoring cabin door status", "providing automatic cabin door locking control", "providing flight lock actuation" and "monitoring flight lock status".

[0105] Perform functional analysis of the door signal system layer. Create system data flows for the main system functions, and finally create a complete system data flow, collecting all the "leaf" functions to visualize the global data flow of the system layer. Create a system-level function chain in the door signal system data flow, select a series of function interactions (implicitly select the source function and the target function), and activate the context menu.

[0106] Assign functions to the door signal system or the executor. At the system analysis level, functions can only be assigned to the system itself, which is considered a "black box", or to an external executor. Assign functional interactions to component interactions between the system and the executor. For two functions assigned to two behavioral components, the functional interaction between them must be assigned to a single component interaction between the two components, which represents all the functional interactions it implements.

[0107] Create a corresponding functional scenario for each functional chain. A functional scenario is a system data flow arranged in chronological order, with functions represented by vertical lines and functional interactions represented by horizontal arrows arranged sequentially from top to bottom.

[0108] Specify the expected behavior of the door signal system as a state machine. In particular, when the system must respond to events from the executor in a set order, some physical components usually require state machines to indicate in which states their functions are available. For example, in the door signal system, the behavior of the flight lock on the ground is different from that in the air or at high altitude on the physical layer. The door signal system controls the locking and unlocking of the flight lock on each boarding door, service door, and emergency door according to the aircraft engine operation status signal and wheel load signal. The specific implementation logic is as follows: When the aircraft is in the air and the airspeed is greater than 80 knots, and the engine operation status information is true, and the locking sensor targets of the boarding door, service door, and emergency door are close, the door signal system controls the flight lock to lock; if the above conditions are not met, the door signal system sends a flight lock unlocking signal.

[0109] The modes of the door signaling system depend on the choices made, usually by the operator, while the states are the result of events that occur in the system. The states (or modes) of the door signaling system are linked together by transitions, which describe the response of the structural elements when an event occurs (the elements usually change state as a result). A transition contains a "Source State", a "Trigger" and a "Target State". It can also include a "Guard Condition" and an "Effect".

[0110] Data modeling at the system level. In order to ensure consistency between the data managed in the system and the data interacted with by external executors, interactions, data, information, material flows, etc. are standardized to avoid multiple definitions of a single data segment in different areas of the system. Data structures are modeled with the desired accuracy, connecting them to functional interactions (functions) or component ports (interfaces), etc. The system architecture of the hatch signal system is as follows: Figure 4 shown.

[0111] 3. Establish the Logical Architecture (LA) layer of the door signal system:

[0112] Internal system function analysis: that is, the sub-functions that must be performed and combined to establish the "user" function determined in the previous stage;

[0113] The logical components that perform these internal sub-functions are identified by integrating the non-functional constraints that the modeler chooses to address at this level. Specific implementation method:

[0115] Start creating the logical layer based on the work done at the system layer, and create as many logical functions as system functions by using the conversion tool that converts system functions to the logical layer, while preserving function interactions and function chains. If a system function is missing at the logical layer, add it to the system layer intact and reapply the relevant conversion. Apply the conversion tool that converts the actors to the logical layer to convert the external actors, and the actors defined at the system layer are exactly the same as those defined at the logical and physical layers. Restore the component ports and component interactions between the door signal system and the actors, and maintain the assignment relationship from function interactions to component interactions.

[0116] First, identify structural elements called "Logical Components" by enforcing the exclusion of all technical considerations or implementation decisions (which is the goal of physical architecture when defining the "real" concrete components that make up the system). Name logical components and physical components differently, and only give names that refer to explicit technologies to physical components.

[0117] Perform the allocation of logical functions. The transformations from the execution side retain their functional allocation and insert them into the logical architecture whiteboard diagram using the same System Layer Editor command: "Insert All Allocated Functions". To verify that all logical functions have been allocated, apply the "Manage Function Allocation" command to any structural element. If the selection is empty, it means that all functions have been allocated. Assign external ports to components by dragging component ports from the boundary of the logical system to the relevant logical component.

[0118] Verify that the logical system no longer has any ports by changing the color of the logical system outline so that it barely appears. Also further refine the assignment of functional ports, which can be lost when moving a component's interface. To identify this, open the property sheet for the component port and check the functional port in question in the "Allocated Ports" area. If the logical functional interaction crosses the boundary of two components, create a new intra-component interaction to assign it.

[0119] The logical layer scenario is initialized by locating in the system layer interaction scenario and activating the context-related command: "Transition-Systems Exchange Scenario to Logical Exchange Scenario Initialization". After completing the transformation, first create the "Capability Realization" with the same name as the "System Capability" and the interaction scenario with the same name as the door signal system interaction scenario. The vertical lines of the logical scenario represent the same executors and the expected logical components. By applying the same filters as in the system layer, the interaction items are displayed on the functional interaction. Constraints, new messages or new functions corresponding to the created model elements are added completely based on the logical layer to ensure the consistency of the interaction and the executors, and operations can be performed on the relevant levels to complete the logical scenario diagram.

[0120] In order to give a concise and quick overview of the logical architecture layer, the logical components are decomposed into logical sub-components and the ports of the logical sub-components are assigned. Start with the logical architecture diagram and simplify it by retaining only the executors and components that are linked to the door signal system. Then, create three logical sub-components in the door signal system: the "Proximity Sensor" component, the "Proximity Sensor Electronic Unit" component, and the "Indicator" component, and assign corresponding logical functions to these three components. The logical architecture of the door signal system is as follows: Figure 5 shown.

[0121] 4. Establish the physical architecture layer (PA layer) of the hatch signal system:

[0122] The goals of this level are consistent with those of the logical architecture, except that it defines the final architecture of the door signaling system that must be created;

[0123] It adds the functionality required for specific implementation and technology choices and emphasizes the behavioral components (e.g., software units) that perform these functions, which are then implemented using implementation components (e.g., processors) that provide the necessary physical resources. Specific implementation method:

[0125] First, the functions and implementations generated in the logical architecture layer are automatically recovered in the physical architecture layer. Then, by making certain technical choices, the specific physical components in the system are created. At the same time, the functions of the physical layer are assigned to these physical components, and the process requires decomposing or combining these functions originated from the logical layer.

[0126] The logical architecture was previously initiated by "opening the black box" to identify the structural elements called logical components and the properties and relationships between them. Ensuring that all technical considerations or implementation choices are excluded within the logical architecture layer is the goal of the physical architecture when defining the "real" concrete components that make up the door signaling system.

[0127] The physical architecture layer is created based on the logical architecture layer. This transformation is similar to the transformation used when going from operational analysis to system analysis and then from system analysis to logical architecture. It creates as many physical functions as logical functions by retaining functional interactions and functional chains, and automatically creates implementation links between each physical element (function, functional interaction, functional chain) and the corresponding logical element. The transformation is iterative and incremental. If a logical function or system function is lost when running on the physical layer, return to the highest level and apply the transformation again after adding the logical function or system function. Next, the transformation of the external executor is applied. The executor identified on the logical architecture layer is exactly the same as the physical architecture layer.

[0128] There are two types of physical components in the physical architecture layer: behavioral physical components and node physical components. Behavioral physical components belong to the components of the system analysis layer, which are responsible for performing certain functions assigned to the system by interacting with other behavioral components and external executors. Node physical components host a certain number of behavioral components, and they host by providing the behavioral components with the resources they need to interact with the environment. A single behavioral component is hosted by a single node physical component.

[0129] First, create node physical components corresponding to the door signal system and subcomponents of the same type, such as the cargo door actuator in the cargo door actuation system and the display panel and status indicator light in the cabin door. Create node physical components in the initial physical architecture whiteboard diagram, and then deploy behavioral physical components to allocate system functions. The three behavioral physical components contained in the door signal system are PSEU, proximity sensor, and display component. The cargo door actuation system includes cargo door controller, cargo door actuator, cargo door control panel, and transmission flexible shaft. The flight lock system is mainly the flight lock actuator. The cockpit door control system includes password board, EDCM, and electromagnetic lock. Change the "Behavior / Node" property in the physical component property table, and specify the "Physical Component Kind" property of the component type as software, hardware, computer, etc. For example, the avionics central computer in the integrated modular avionics IMA is marked as "computer hardware". You can continue to create and deploy behavior components on the node components through the "Deploy Behavior PC" command on the editor in the physical architecture whiteboard diagram. A behavior component is hosted by one and only one node physical component. Conversely, a node physical component can host multiple behavior components. Complete the physical architecture whiteboard diagram by inserting the physical actors that are automatically recovered by the transformation. Even if you choose not to recover the logical component and its associated component interactions, the transformation will be passed to the actor's ports.

[0130] Assign functions to physical components. For those actors that have been automatically recovered by the reduced order conversion, they can be inserted graphically into the view through the "Insert Allocated Functions" command in the editor. For systems that have been automatically recovered by the reduced order conversion, the "Manage Function Allocation" command in the editor is used to assign behavioral physical components.

[0131] Create a function chain for the physical layer. First, delete the link to the decomposed function by using the "Delete from Model" command. Then, add the missing sub-function "Send Motivational Signal" by using the "Involve Function" command. Next, use the "Involve Functional Exchange" command to link the sub-functions.

[0132] Create the necessary component interactions between the behavioral physical components and the corresponding physical links between the node physical components. First, copy the physical architecture whiteboard diagram and then simplify the new diagram by removing all the actors through the "Delete from Diagram" command. The simplified physical architecture whiteboard diagram represents the internal structure of the door signal system. Assign the "Integrated Data" functional interaction to the component interaction and create a component interaction between the "Proximity Sensor Electronic Unit" and "Remote Data Integration Unit" components. Name this component "Integrated Modular Avionics to Proximity Sensor Electronic Unit (IMA to PSEU)" component and continue to assign functional interactions to it, which completes its definition by locating the implementation link to the component interaction at the logical level. Assign this component interaction to the "Physical Link" between the node physical components in turn, create a "Data Bus" type physical link between the proximity sensor electronic unit and the integrated modular avionics, and then assign the component interaction. A physical link is a way of communication, transmission or connection between two node physical components to support component interaction. It connects the physical ports of two components and can directly link subcomponents to each other. Figure 6 shown.

[0133] The above shows and describes the basic principles and main features of the present invention and the advantages of the present invention. It should be understood by those skilled in the art that the present invention is not limited to the above embodiments. The above embodiments and descriptions are only for explaining the principles of the present invention. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, which fall within the scope of the present invention to be protected. The scope of protection of the present invention is defined by the attached claims and their equivalents.

Claims

1. A modeling method for a civil aircraft door signal system based on MBSE, characterized in that: The specific operation includes the following steps: (1) Establish the operation analysis layer of the door signal system, Analyze the operation of the system in a real environment and define the system's context and operation scenarios; (2) Establish the system analysis layer of the door signal system, Identify the functional and non-functional requirements that the system needs to meet and clarify the system's goals; (3) Establish the logical architecture layer of the door signal system, Based on system analysis, design the logical components of the system and describe the functional modules and their interrelationships; (4) Establish the physical architecture layer of the door signal system, Translate the logical architecture into a concrete physical implementation, defining the hardware and software components.

2. According to claim 1, a modeling method of a civil aircraft door signal system based on MBSE is characterized in that: The step (1) establishes an operation analysis layer of the cabin door signal system, which is used to identify the use scenarios of the cabin door signal system, such as passenger boarding, cabin door opening and closing, to ensure the understanding of the external environment and user needs. The specific implementation includes the following steps: Define the system context: Determine the external environment of the door signal system and related systems (such as flight control system, passenger service system); Describe the system boundaries and clarify which parts belong to the door signal system and which parts belong to the external system; Identify stakeholders: Identify stakeholders related to the door signaling system (e.g. pilots, passengers, maintenance personnel); Gather their needs and expectations and ensure that the system design meets those needs; Analysis operation scenario: Identify how the door signaling system operates in different operational scenarios, such as: door opening and closing, signal processing in emergency situations, and signaling during passenger boarding and disembarking; Draw activity diagrams or sequence diagrams for each scenario, detailing the system's behavior and interactions; Define operational requirements: List the specific operational requirements that the door signal system needs to meet in each operational scenario, including functional requirements (such as status indication, alarm) and non-functional requirements (such as response time, reliability); Identify key events: Identify key events that affect the operation of the door signal system, such as door anomalies and signal failures; Analyze the impact of these events on system functionality and users; Build a use case model: Create a use case diagram to describe the main use cases of the door signal system (such as "monitor door status", "send enable signal") and its relationship with stakeholders; Edit a detailed use case description for each use case, specifying its preconditions, triggering conditions, and postconditions. As a preferred embodiment, the step (2) establishes a system analysis layer of the door signal system, which is used to define key functions of the door signal system, such as door status monitoring and signal transmission, to ensure the integrity and consistency of the functions. The specific implementation includes the following steps: Create a system analysis view: Add a new "System Analysis" view to the project as the basis for the system analysis layer; Define functional requirements: In the "Requirement View", list all functional requirements related to the door signal system, including main functions (such as door status monitoring, signal processing) and non-functional requirements (such as safety, reliability); Building a functional architecture: In the "Functional Architecture View", identify and create the main functional modules of the door signal system; Layer the functional modules and clarify the responsibilities and functions of each module; Define functional relationships: Use the "Function Chain View" to establish the relationship between function modules and describe the input, output and interaction logic; Determine the calling relationship of each functional module to ensure the correctness of information flow; Identify data needs: In the "Data Flow View", define the data types and data flows required by the system to ensure that each functional module can obtain and process the required data; Build the state model: In the "State View", define the state changes of the door signal system, such as the different states of the door (open, closed, locked) and their transition conditions; Use case refinement: In the "Use Case View", refine the use cases in the previous layer and clarify how each use case implements the corresponding functional requirements; Add detailed scenario descriptions for each use case, covering both normal operations and abnormal situations.

3. The method for modeling a cabin door signal system of a civil aircraft based on MBSE according to claim 1, characterized in that: The step (3) establishes a logical architecture layer of the door signal system, which is used to construct a logical model of the door signal system and define the roles of various functional modules (such as proximity sensors and controllers) and their interaction methods. The specific implementation includes the following steps: Create a logical schema view: Add a new "Logical Architecture" view to the project so that you can build the logical architecture model in this view; Define the logical components: Identify and create the main logical components (such as control units, sensors, indicators) according to the functional requirements of the system analysis layer; Define the function and role of each component; To establish component relationships: Use the "Structure Diagram" view to describe the relationships and interactions between logical components; Determine the flow path of data and control signals to ensure the coherence of the logical architecture; Define the interface: Define the interface for each logic component, including input and output signals; Clarify the communication protocols and data formats between components; Build a state machine model: Establish state machines for important logic components (such as control units) and define their behaviors and transition conditions in different states; Identify key features: Identify the key functions of each logical component to ensure that each component can meet the overall needs of the system.

4. The MBSE-based modeling method for a civil aircraft door signal system according to claim 1, characterized in that: The step (4) establishes the physical architecture layer of the door signal system, which is used to describe the actual components of the door signal system, such as sensors, actuators, and control units, and to clarify the interfaces and communication methods between the components. The specific implementation includes the following steps: Create a physical schema view: Add a new "Physical Architecture" view to the project so that you can build the physical architecture model in this view; Define the physical components: According to the logical components in the logical architecture diagram, identify and create corresponding physical components (such as actual sensors, controllers, and indicator lights); Define the function and role of each physical component; To establish component relationships: Use the "Physical Structure Diagram" view to describe the connection relationship between physical components; Determine the communication method (e.g., wired, wireless) and data flow between physical components; Define the interface: Define interfaces for each physical component, including electrical interfaces, data interfaces, and control interfaces; Clarify the protocol and data format of the interface to ensure compatibility between components; Identify hardware requirements: Determine the hardware resources required for each physical component, such as power requirements, size, and weight; System integration considerations: Consider system integration issues in the physical architecture diagram to ensure that the physical components can work together effectively; Identify possible integration challenges and plan solutions; Verification and review: Review physical architecture diagrams with team members and stakeholders to ensure accuracy and plausibility of physical components and connections, and make necessary revisions and adjustments based on feedback.

Images