SysML-based modeling and verification method for mode transition of civil aircraft automatic flight control system

Abstract

This invention discloses a method for modeling and verifying mode conversion in civil aircraft automatic flight systems based on the SysML language. First, it analyzes in detail the key issues in formal modeling for this field, including high-level abstraction, hierarchical design, mode conversion logic, and priority characteristics, constructing a meta-model for flight control mode design and conversion. Second, based on the proposed meta-model, the formal modeling language SysML is extended and encoded into a domain-specific SysML profile file. Subsequently, the extended SysML profile is used in a mode conversion modeling project for an automatic flight system of a certain type of civil aircraft, and the safety and correctness of the model are verified using NUSMV. This invention provides a relatively complete and unified model building approach for the field of automatic flight systems, effectively ensuring system design quality and improving system development efficiency and safety.

Description

Technical Field

[0001] This invention relates to the fields of automatic flight control systems, formal modeling and verification, and specifically to a SysML-based method for mode conversion modeling and verification of civil aircraft automatic flight control systems. Background Technology

[0002] The Automatic Flight Control System (AFCS), after its functions and operating states are pre-set, can receive input signals from relevant flight sensors and pilot commands in real time during flight. It can automatically control and stabilize the aircraft's attitude, trajectory, and airspeed without direct pilot intervention. The AFCS encompasses dozens of flight modes. The different phases of automatic flight essentially involve flight mode transitions, with the AFCS performing the control tasks. Each control task corresponds to one or more control modes. Flight mode transitions determine flight safety, and confusion in the flight mode transition logic can lead to serious system hazards or even disasters.

[0003] Traditional and widely used text-based system engineering (TSE) in the aerospace field has several shortcomings: relying solely on text and simple graphics to express system design schemes fails to fully convey the design details and key information of complex systems; system design documents may contain ambiguities or vague expressions, affecting subsequent design understanding and implementation; and the lack of effective team information exchange mechanisms leads to information silos and low team collaboration efficiency. These shortcomings severely restrict the efficient design and development of complex aerospace systems, posing a significant challenge to meeting the stringent safety and reliability requirements of modern aerospace systems. Therefore, innovative systems engineering methods are urgently needed to overcome these deficiencies and better support the design and development of aerospace systems.

[0004] However, due to the safety-critical nature of aviation systems, consistency and safety verification issues arise between modeling results and requirement models using various system modeling languages ​​such as SIMULINK. Unlike complex systems in other domains, aviation systems have stringent safety requirements. Due to the multi-level and multi-dimensional nature of their structure, numerous flight modes, complex mode transition logic, and priority relationships between event triggers within the domain, system modeling is extremely complex. Taking event trigger priority as an example, in traditional automatic flight system modeling, the traditional SIMULINK-based modeling method uses combinations of basic logic gates such as NOT gates, AND gates, and OR gates to determine priorities. However, as the scale and complexity of flight control systems increase, this simple logic gate modeling approach gradually becomes inflexible and unmaintainable.

[0005] Although the System Modeling Language (SysML) provided by the Object Management Group (OMG) is specifically designed for the field of systems engineering, most features in the mode transition modeling of automatic flight control systems do not have direct corresponding modeling elements in standard SysML. Directly using the generic elements provided by SysML for modeling will make it difficult to comprehensively and accurately capture the complex logic and semantic features of automatic flight control system mode transitions, affecting the consistency and completeness of requirements modeling, and further impacting the accuracy and reliability of subsequent design.

[0006] Although SysML is a relatively mature system modeling language, it is essentially a semi-formal modeling language. The underlying semantics of SysML models are difficult to fully express, such as key features like the relationships between input / output ports. This limitation in semantic expression prevents SysML models from undergoing complete automated verification in the early stages of system design. For complex and critical aerospace systems like automated flight control systems, formal modeling and verification techniques are particularly important. They can compensate for the shortcomings of the SysML modeling language, helping engineers comprehensively analyze various behavioral characteristics of the system early in the design phase and verify whether key requirements such as safety and functionality are met, laying a solid foundation for subsequent detailed design. Summary of the Invention

[0007] Purpose of the invention: This invention provides a SysML-based method for modeling and verifying mode conversion in civil aircraft automatic flight control systems, which effectively ensures the design quality of civil aircraft automatic flight control systems and improves development efficiency and safety.

[0008] Technical Solution: The SysML-based modeling and verification method for mode conversion in civil aircraft automatic flight control systems, as described in this invention, specifically includes the following steps:

[0009] (1) Analyze the problems of high-level abstraction, hierarchical design, mode conversion logic and priority characteristics in formal modeling in the field of automatic flight control, and construct a meta-model based on AFCS mode conversion.

[0010] (2) Based on the proposed meta-model, the formal modeling language SysML is extended and encoded into a domain-specific SysML profile file;

[0011] (3) Layered modeling of the automatic flight control system mode switching domain: structural modeling of mode switching, mode switching modeling and event priority modeling;

[0012] (4) Combining the structural information of the semi-formal SysML model, the FSM text description was extracted from the model, and the corresponding CTL specification was generated by combining the extracted system security requirements. The security and correctness of the model were verified by using NUSMV.

[0013] Furthermore, the meta-model described in step (1) divides the high-level abstraction of the system into a set of components that manage flight modes separately and participate in mode interaction; and defines domain features including mode and module attribute features, and communication and interaction between modes and modules; for the core mode transformation of the system, the meta-model uses a state machine diagram as a prototype to define mode transformation and state transition functions, and constructs constraint relationships with mode logic.

[0014] Furthermore, the core components of the metamodel in step (1) are divided into a set of multi-dimensional flight modes and a set of flight electronic devices that are coupled and interact with the flight modes; the metamodel distinguishes and defines the formal semantics of the triggering events and conditions involved in the flight mode transition; the event is a comparison of changes between two consecutive states before and after the system behavior, used to represent a specific operation or condition that occurs, referring to a transient behavior; the condition is a predicate satisfied in a single state, and can be further defined with more complex semantics such as conditional events based on variable state semantics.

[0015] Furthermore, the mode transition and state transition are defined using a state machine diagram and extended within the meta-model, introducing constraints of mode logic to define the transition logic; the entire mode state transition is a tuple STM = (S, v i ,v o ,δ,cond,s0,s f ,CS); where S represents the set of all states; v i v o These represent the sets of input and output attributes for state transitions, respectively. The state transition set is represented by δ:s, where cond represents the set of state transition conditions consisting of specific combinations of input attribute values. The transition from the source mode state to the target mode state can be written as δ:s. s ×cond→s t ; s0∈S, representing the initial state; s f ∈S represents the final state; It represents a composite state, nested substates, and transitions between substates.

[0016] Furthermore, the attributes of the mode and inter-module communication interaction include variables and events; the variables are used to describe changes and transmissions of states, parameters, or data.

[0017] Furthermore, the implementation process of step (2) is as follows:

[0018] The basic semantic elements of the domain-specific metamodel are defined with a standardized syntax. New modeling element stereotypes are constructed based on SysMLprofile, which extends the UML definition, and include:<Flight_Modes_Atomic> > and <<Flight_Modes_Coupled> >Extended from SysML::< <block>>;structural type< <event>The description of schema transformation domain event information is extended from SysML's < <attribute>>;structural type< <process>>Description pattern internal state transitions extended from < <statemachine>> Use profile relationships and tag attributes to extend additional features to domain profile elements.

[0019] Furthermore, the structural modeling implementation process for the mode conversion described in step (3) is as follows:

[0020] Based on the functional requirements analysis, a block definition diagram is used to describe the static structural information of the system. At the mode level during the flight approach and landing phase, the modes are divided into lateral and longitudinal dimensions. During the approach and landing phase, the flight modes at the mode level establish connections between specific modes at each level through hierarchical relationships. Higher-level flight modes integrate and coordinate multiple lower-level specific flight modes to achieve flight objectives, connected through SysML's <<Partial Relationships>>, forming a diagrammatic hierarchical flight mode model structure. During approach, complex interactions exist between the flight modes and external avionics equipment and flight personnel. Constructed <<Modules>> are used to build subsystems that interact with the flight modes, and these are connected through extended interaction relationships.

[0021] Furthermore, the mode transformation modeling implementation process described in step (3) is as follows:

[0022] Mode transitions are defined within the block diagrams of their respective flight modes. The ibd of the constructed <<mode>> heading selection mode builds a vertically divided "process" structure, including two input processes, three encapsulation processes, and three output processes. In terms of execution sequence, the overall execution direction is visible as input process -> encapsulation process -> output process. Information exchange between functions is achieved through <<flow>>, maintaining the execution order and hierarchical relationship. Processes at different levels can only access <<variables>> and <<events>> from the previous or current level.

[0023] The module maintains consistency with the pattern management and control layer in terms of execution order and attribute processing;

[0024] Establish interactive channels for pattern state information and flight events between patterns and between patterns and modules to achieve a coupled and compatible multi-dimensional static structure; define extended inputs and outputs at the boundaries of pattern and module structures.

[0025] Furthermore, the implementation process of step (4) is as follows:

[0026] When generating the finite state machine model, the design is based on SysML configuration files and NuSMV. First, the individual patterns and function call relationships within the modules are roughly defined in text.

[0027] The naming is consistent with the internal function Process naming in the SysMLprofile pattern. The parameters called inside the function are the Attributes and Events that the Process needs to call. The function call relationship describes the interaction relationship between the pattern and the module.

[0028] In the mapping of the NuSMV model text description, the variables and events for mode calls are defined in the parameter part; the states of the modes are defined by variables; the transitions between states are defined by variable assignment; the possible values ​​of the flight mode state categories or events or variables processed by the module are described using NuSMV's VAR; the above information is initialized at ASSIGN using the init statement; and the values ​​are updated in the next statement according to the combination conditions in the submodule parameter, i.e., the state transition of the original STM.

[0029] In accordance with the hierarchical structure of the model during the conversion process, the above specifications and CTL specifications are combined into a NuSMV module. This module is then input into the NuSMV model for verification to obtain the verification results. After verification, all security verification statements result in TRUE, indicating that the system meets the security requirements. After verifying that all behaviors in the pattern conversion domain are correct, the entire model is deemed to have passed verification.

[0030] Beneficial effects: Compared with the prior art, the beneficial effects of the present invention are as follows:

[0031] This invention comprehensively considers the concepts and characteristics of the civil aviation field, defines the semantics of SysML at the meta-model level, and encodes it as SysMLprofile, which can provide explicit semantics for modeling elements used for automatic flight control mode switching; it uses NUSMV to perform rigorous analysis and verification of the model, and if verification counterexamples that do not meet safety requirements are found, the errors are tracked, located, modified, and re-verified through counterexamples; it adopts rigorous formal modeling and verification, which effectively ensures the design quality of flight control systems and improves development efficiency and safety. Attached Figure Description

[0032] Figure 1 This is an architectural diagram of the present invention;

[0033] Figure 2 A schematic diagram of the meta-model of a civil aircraft automatic flight control system;

[0034] Figure 3 SysML profiles define components and flows;

[0035] Figure 4 Define the SysML profile for attributes and procedures;

[0036] Figure 5 Block definition diagram design for civil aircraft automatic flight control system;

[0037] Figure 6 Internal block diagram design for flight mode;

[0038] Figure 7 Design a state machine diagram for flight mode;

[0039] Figure 8 Internal block diagram design for flight mode priority. Detailed Implementation

[0040] The present invention will now be described in further detail with reference to the accompanying drawings.

[0041] like Figure 1 As shown, this invention provides a SysML-based modeling and verification method for mode conversion in civil aircraft automatic flight control systems. It employs formal modeling and verification methods, defines a meta-model of the civil aircraft automatic flight control system, and extends SysML through profiling for modeling in this domain. NUSMV is used to verify the safety and correctness of the modeling results, effectively ensuring the design quality of the flight control system domain and improving development efficiency and security. Specifically, it includes the following steps:

[0042] Step 1: Meta-model design.

[0043] This study gathers the mode switching requirements of civil aircraft automatic flight systems, as well as relevant domestic and international airworthiness regulations and industry standards for automatic flight control systems. Based on system engineering documents within the domain, it identifies key issues in requirements modeling, such as high-level abstraction, hierarchical design, mode switching logic, and priority characteristics. According to these requirements and modeling issues, a domain-based meta-model is constructed using the System-Based Model Engineering (MSBE) approach. This meta-model expands and designs information on domain components, features, and functions. The meta-model divides the system's high-level abstraction into a set of components that manage flight modes independently and participate in mode interactions. It defines domain characteristics, including mode and module attribute features, and communication interactions between modes and modules. For the core mode switching of the system, the meta-model uses a state machine diagram as a prototype to define mode switching and state transition functions and constructs constraint relationships with mode logic.

[0044] Mode transitions and state transitions are defined using state machine diagrams and extended within the metamodel, introducing constraints from the mode logic to define the transition logic; the entire mode state transition is a tuple STM = (S, v i ,v o ,δ,cond,s0,s f ,CS); where S represents the set of all states; v i v o These represent the sets of input and output attributes for state transitions, respectively. The state transition set is represented by δ:s, where cond represents the set of state transition conditions consisting of specific combinations of input attribute values. The transition from the source mode state to the target mode state can be written as δ:s. s ×cond→s t ; s0∈S, representing the initial state; s f ∈S represents the final state; This represents a composite state, its nested sub-states, and the transitions between them. When a composite state is activated, it first enters a sub-initial state; during the activation of a composite state, only one sub-state is active at any given time.

[0045] SysML contains modeling elements that can meet most of the descriptive needs for system-oriented modeling. Considering the domain characteristics of AFCS schema transformation, the expansion and design are first carried out at the metamodel level. For this invention, the metamodel is a model that provides specified concepts for modeling the research domain. Therefore, in actual modeling, each view of the system exists as an instance of the metamodel. Figure 2 This paper presents a meta-model based on the domain requirements of AFCS mode conversion proposed in this invention. All elements in the figure provide direction for SysML-based extensions.

[0046] The metamodel divides core components into a set of multi-dimensional flight modes (flight mode atom sets) and a set of flight electronic devices (such as flight control panels) that are coupled and interact with flight modes (flight mode coupling). The metamodel distinguishes and defines the formal semantics of triggering events and conditions involved in flight mode transitions. An event is essentially a comparison of changes between two consecutive states before and after a system behavior; a condition is a predicate satisfied in a single state, and more complex semantics, such as conditional events, can be further defined based on variable-state semantics. Input / output coupling is defined as the set of events such as device receiving and sending variables and state changes, while data input / output represents the set of events such as flight mode receiving and sending variables and state changes. The specifications for the corresponding ports define the transmission name and type.

[0047] Attributes, states, and transition functions constitute the metamodel of a coupled flight device, representing its attribute characteristics (flight variables or events), internal states, and transition function sets. These models together form the internal model of the coupled device, implemented through a state machine model. Mode attributes, states, and transition functions, as the metamodel of a flight mode, represent the mode's attribute characteristics, multi-dimensional mode states, and mode transition function sets. Attributes are refined into events and variables, representing flight parameter values ​​constrained by flight mode logic; mode states represent flight mode states and are associated with enumerated values ​​of four flight dimensions through mapping; state sets and set state values ​​represent the mode state set and its values, determined by the combination of internal variables / events of transition conditions; transition conditions, output functions, and input functions are constrained by mode logic and constitute the mode transition functions.

[0048] Step 2: Extend the formal modeling language SysML based on the proposed meta-model and encode it into a domain-specific SysML profile file.

[0049] Define the standard syntax for the basic semantic elements of the domain-specific model. Based on SysMLprofile, which extends the UML definition, construct new modeling element stereotypes, including:<Flight_Modes_Atomic> > and <<Flight_Modes_Coupled> >Extended from SysML::< <block>>;structural type< <event>The description of schema transformation domain event information is extended from SysML's < <attribute>>;structural type< <process>>Description pattern internal state transitions extended from < <statemachine>>. Additional features are added to domain profile elements using profile relationships and tagged attributes (TaggedValue).

[0050] This embodiment extends SysML based on the proposed meta-model concept, encoding it into a SysMLprofile file. Leveraging the characteristics of pattern transformation in the autonomous flight domain, it provides specific syntax for specifying appropriate stereotypes and the relationships between them. Figure 3 This indicates that the model composition and the flow as information interaction are profiled and extended. <<Flight Mode_Atom>> and <<Flight Mode_Coupled>> are flight modes and coupling components categorized in the metamodel, extended from the SysML:: block definition graph. It is further refined into stereotypes <<Pattern>> and <<Module>>, where <<Pattern>> contains four flight dimensions <<Dimension>>. Based on different interaction devices, modules are further distinguished into stereotypes <<Sensor Module>> and <<Display Module>>, with stereotypes used to represent the interaction relationships between patterns / modules extended from <<...>>. <dependency>>

[0051] In the model, functional modules process input data to generate output data, i.e., through interactions between modules via signals, matter, or energy flows. During actual flight, the flight control system's modes process the input information of the interaction modes / modules to perform mode transitions and generate output information. Our metamodel expresses this interaction information as flow attribute stereotypes. The stereotype <<flow>> connects the output port of the source module / mode and the input port of the target module / mode, and binds to the stereotype <<communication>>, which extends from <<flow attribute>>, via tagged values. Combining the attribute features of the metamodel, SysMLprofile constructs stereotypes <<variable>> and <<event>>, and binds <<communication>> to output-level attribute features based on the transmission direction.

[0052] The attribute features <<variables>> and <<events>> defined in the Profile extend from SysML::Attribute, encoding their respective elements in the metamodel transport, such as... Figure 4 As shown. The stereotypes `<<variable>>` describe flight states or aviation parameters (flight altitude, vertical speed, etc.), and the stereotypes `<<event>>` describe flight events, such as changes in flight states. Furthermore, combining hierarchical characteristics, it is generalized into inputs, encapsulations, and outputs, corresponding to hierarchical processing. To express event priority, a stereotype `<<priority>>` extending from `SysML::Block` is constructed.

[0053] Based on the characteristics of the domain, in an automated flight system, the state transitions between the main functional modes, as well as the internal processing of attributes by related modes / modules, can be represented by state transitions in a state machine. Therefore, the stereotype < <process>Extended from SysML::StateMachine. In specific modeling, the execution process within a single pattern / module has direction and execution sequence, therefore... Figure 4 The <<process>> is vertically layered, also divided into inputs, encapsulations, and outputs. To maintain the hierarchical characteristics within the schema / module and establish the relationships between processes and variables / events in the metamodel, processes and variables / events at the same level in the profile are connected using tagged values. A process is only allowed to receive variables / events output from the previous level or the same level as input to the current level. A constructed type <<transition matrix>>, extended from the SysML::block definition graph, is defined to represent the conditions for schema state transitions, such as combinations of flight event values.

[0054] Step 3: Formal model building and security verification:

[0055] Based on the example of the AFCS mode transition project, we apply the extended SysMLprofile to model the system mode transition domain and subsequently perform formal verification of the model. First, we perform layered modeling of the automatic flight system mode transition domain.

[0056] Step 3.1: Structural modeling of AFCS mode conversion.

[0057] Based on the functional requirements analysis, a block definition diagram is used to describe the static structure information of the system, such as... Figure 5 As shown, in the flight approach and landing phase, the flight modes are first divided into lateral and longitudinal modes based on dimensional information. Flight modes at this level (such as the horizontal mode) establish connections with specific modes below the level (such as the heading selection mode) through hierarchical (sub-mode) relationships. Higher-level flight modes integrate and coordinate multiple lower-level specific flight modes to achieve flight objectives, connected through SysML's <<partial connections>>, forming a diagrammatic hierarchical flight mode model structure. During approach, complex interactions exist between flight modes and external avionics and flight personnel. Constructed <<modules>> are used to build subsystems that interact with flight modes, connected through extended interaction relationships. This includes the flight control management panel and related conceptual entities, such as flight guidance and autopilot.

[0058] Next, to maintain the hierarchical nature of the model, the relevant modules are kept consistent with the schema management and control layers in terms of execution order and attribute processing. This is reflected in the constraints on the execution order and attribute processing of processes in the internal block diagram (IBD).

[0059] During flight mode transitions in the approach phase, various coupling scenarios exist between modes of different dimensions, involving the interaction of transition conditions. Therefore, it is necessary to establish interaction channels for mode state information and flight events between modes and between modes / modules to achieve a coupled and compatible multi-dimensional static structure. Extended inputs / outputs are defined at the boundaries of the mode and module structures. Taking the interaction between the flight control management panel and the heading selection mode as an example: During the approach and landing phase, the heading selection mode is the default operating mode, used to instruct the aircraft to maintain the heading selected on the flight control management panel. It is activated by the pilot pressing the heading selection mode switch on the flight control management panel. The panel sends a flight event <<When Heading Selection Mode is Pressed>> to the heading selection mode to update its internal mode state to activated. These events are stored through the flow attribute <<Flight Control Panel -> Heading Selection Mode>> and connected via streams and ports.

[0060] Finally, through the above hierarchical division and modeling methods, the system achieves structured management and control of flight mode switching, ensuring that the system can effectively process data and interact during operation.

[0061] Step 3.2, Pattern Transformation Modeling.

[0062] Mode transitions are a core modeling requirement within the AFCS system, involving numerous flight modes and complex logic. Mode transitions are defined within the block diagrams of their respective flight modes, such as... Figure 6 As shown, the ibd structure of the constructed <<pattern>> heading selection pattern is built with a vertically divided three-layer "process" structure, including two input processes, three encapsulation processes, and three output processes. In terms of execution sequence, the overall execution direction is visible as input process -> encapsulation process -> output process. Information exchange between functions is through <<flow>>, maintaining the execution order and hierarchical relationship. Processes at different levels can only access <<variables>> and <<events>> from the previous or current level.

[0063] Specifically, in HDG mode, such as Figure 7 The diagram illustrates the modeling of the state machine diagram. The state transitions in the HDG mode are influenced by the flight events "Cancel Heading Selection Mode" and "Select Heading Selection Mode." The combination of these event values ​​serves as the condition for the mode's state transitions. When the "Select Heading Selection Mode" event is 1 (true) and the previous HDG mode state is "Clear," the HDG state transitions to "Select," indicating it is "On." The "Cancel Heading Selection Mode" event has no effect and is marked as "x." In the modeling, the <<State Transition Matrix>> stores the conditional values, which are then extended from << <transition>>And bind the preform <<transition>> of the transition matrix to connect the transformed state.

[0064] Step 3.3, Event Priority Modeling.

[0065] SysML profiles extend the SysML language by combining stereotype priorities, events, and processes for handling those events in the modeling process, allowing for a better expression of the specific needs of a particular domain. Figure 8 To illustrate, taking the FMCP module requirements as an example, flight events such as the pilot pressing a mode button on the FMCP have a priority relationship. Taking the Heading Selection (HDG) and Approach Mode (APPR) modes during the approach and landing phase as examples, no other lateral mode is pre-positioned when HDG mode is executed. When the pilot presses the APPR switch on the FMCP, APPR is activated, and the aircraft begins the approach. Once the LOC (Landing on Control) is activated from its pre-position, HDG is canceled. The APPR button press event has a higher priority than the HDG button press event.

[0066] Specifically, the modeling implementation in the internal block diagram of FMCP is as follows: When the HDG button is pressed, it is necessary to consider whether a higher-priority flight event has occurred in the current FMCP. If the APPR button is pressed, the HDG button event must be blocked. During modeling, the approach mode is treated as a preprocessing flow with no event priority higher than the heading selection mode, and changes in the value of the corresponding flight event will affect the priority of subsequent flows, i.e., the conditions for module state transitions, thus determining whether to block subsequent processing flows. This modeling method can accurately express the event priority determination relationship and output it to the required mode or module.

[0067] Step 4: Security verification of modeling results.

[0068] In the field of AFCS schema transformation, SysMLprofile, an extension of the original SysML modeling language, is used to build hierarchical domain models. However, since the modeling language is inherently semi-formal, the resulting model cannot be directly verified. To address this issue, the invention selected NuSMV as the model checker, which can automatically verify finite state machine (FSM) systems and system specifications based on CTL or LTL descriptions.

[0069] The verification process is divided into the following key steps: First, the FSM text description is extracted from the model by combining its structural information; then, system security requirements are extracted to generate corresponding CTL specifications; finally, the extracted FSM model and CTL specifications are combined into a NuSMV module to be verified for automatic verification. If verification fails, the checker will return corresponding counterexamples for model modification.

[0070] The Process function, as an extension of the state machine, can directly map model elements to FSM text descriptions. Furthermore, the proposed SysML profile file set's schema conversion requirements and hierarchical characteristics allow the core ideas of the modeling language to be reused within the FSM text.

[0071] The FSM model generation is based on SysMLprofile and NuSMV language. First, the function call relationships within individual patterns / modules are roughly defined in text. Taking the HDG pattern as an example, the HDG pattern converts bdd and < in the AFCS pattern. <mode>The structure of HDG's ibd is visible. Figure 5 and Figure 6 Combining structural and internal schema transformation information, the natural language description is defined as follows: During the complete system operation, if state / event E occurs, state / event F will occur, which will lead to state / event G. The corresponding logical expression is: AG(E->AX(F->G)). The corresponding CTL expression in NuSMV is:

[0072] AG((HDG=Cleared)->AX((When_HDG_Switch_Pressed_Seen.result)->(HDG=Selected))).

[0073] The naming is consistent with the internal function Process naming in the SysMLprofile pattern. The parameters called inside the function are the Attributes and Events that the Process needs to call. The function call relationship describes the interaction relationship between the pattern / module.

[0074] In the NuSMV module text description mapping, the parameters define the variables / events for mode calls; the variable definition (VAR section) defines the mode states; and the variable assignment (ASSIGN section) defines the transitions between states. NuSMV's VAR describes the possible values ​​of flight mode state categories or events or variables processed by the module. The `init` statement initializes this information at the `ASSIGN` point, and the `next` statement updates the values ​​based on the combined conditions in the submodule parameter, representing the original STM state transitions. Consistent with the hierarchical structure of the model during the transformation process, the above specifications and CTL specifications are combined into a NuSMV module. This module is then input into the NuSMV model for verification, yielding the results. Verification shows that all security verification statements result in TRUE, indicating that the system meets security requirements. After verifying the correctness of all behaviors in the mode transformation domain, the entire model verification is considered successful.

[0075] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / mode> < / transition> < / process> < / dependency> < / statemachine> < / process> < / attribute> < / event> < / block> < / statemachine> < / process> < / attribute> < / event> < / block>

Claims

1. A method for modeling and verifying mode conversion in a civil aircraft automatic flight control system based on SysML, characterized in that, Includes the following steps: (1) Analyze the problems of high-level abstraction, hierarchical design, mode conversion logic and priority characteristics in formal modeling in the field of automatic flight control, and construct a domain-specific meta-model based on AFCS mode conversion; (2) Based on the proposed meta-model, the formal modeling language SysML is extended and encoded into a SysMLprofile file; (3) Layered modeling of the automatic flight control system mode switching domain: structural modeling of mode switching, mode switching modeling and event priority modeling; (4) Combining the structural information of the semi-formal SysML model, the FSM text description was extracted from the model, and the corresponding CTL specification was generated by combining the extracted system security requirements. The security and correctness of the model were verified by using NUSMV. The implementation process of step (2) is as follows: The basic semantic elements of the domain-specific metamodel are defined with a standardized syntax. New modeling element stereotypes are constructed based on SysMLprofile, which extends the UML definition, and include:<Flight_Modes_Atomic> > and <<Flight_Modes_Coupled> >Extended from SysML <block>>;structural type< <event>The description of schema transformation domain event information is extended from SysML's < <attribute>>;structural type< <process>>Description pattern internal state transitions extended from < <statemachine> > Use profile relationships and tag attributes to extend additional features to domain profile elements;< / statemachine> < / process> < / attribute> < / event> < / block> The structural modeling implementation process for the mode conversion in step (3) is as follows: Based on functional requirements analysis, a block definition diagram is used to describe the static structural information of the system. At the mode level during the approach and landing phase, the system is divided into lateral and longitudinal dimensions. During the approach and landing phase, the flight modes at the mode level establish connections between specific modes at each level through hierarchical relationships. Higher-level flight modes integrate and coordinate multiple lower-level specific flight modes to achieve flight objectives, connected through SysML's <<Partial Connections>>, forming a diagrammatic hierarchical flight mode model structure. During approach, complex interactions exist between the flight modes and external avionics equipment and flight personnel. Constructed <<Modules>> are used to build subsystems that interact with the flight modes, and these are connected through extended interaction relationships. The implementation process of the mode transformation modeling in step (3) is as follows: Mode transitions are defined within the block diagrams of their respective flight modes. The ibd of the constructed <<mode>> heading selection mode builds a vertically divided "process" structure, including two input processes, three encapsulation processes, and three output processes. In terms of execution sequence, the overall execution direction is visible as input process -> encapsulation process -> output process. Information exchange between functions is achieved through <<flow>>, maintaining the execution order and hierarchical relationship. Processes at different levels can only access <<variables>> and <<events>> from the previous or current level. The module maintains consistency with the pattern management and control layer in terms of execution order and attribute processing; Establish interactive channels for pattern state information and flight events between patterns and between patterns and modules to achieve a coupled and compatible multi-dimensional static structure; define extended inputs and outputs at the boundaries of pattern and module structures.

2. The method for modeling and verifying mode conversion of civil aircraft automatic flight control system based on SysML according to claim 1, characterized in that, The meta-model described in step (1) divides the high-level abstraction of the system into a set of components that manage flight modes independently and participate in mode interaction; and defines domain features including mode and module attribute features, and communication and interaction between modes and modules; For the core mode transition of the system, the metamodel is based on the state machine diagram, defines the mode transition and state transition functions, and constructs the constraint relationship with the mode logic.

3. The method for modeling and verifying mode conversion of civil aircraft automatic flight control system based on SysML according to claim 1, characterized in that, The core components of the metamodel in step (1) are divided into a set of multi-dimensional flight modes and a set of flight electronic devices that are coupled and interact with the flight modes; the metamodel distinguishes and defines the formal semantics of the triggering events and conditions involved in the flight mode transition; the event is a comparison of the changes between two consecutive states before and after the system behavior, used to represent the operation or condition that occurred, referring to a transient behavior; The condition is a predicate that is satisfied in a single state, and more complex semantics such as conditional events can be further defined based on the semantics of variable states.

4. The method for modeling and verifying mode conversion of civil aircraft automatic flight control system based on SysML according to claim 2, characterized in that, The mode transition and state transition are defined by a state machine diagram and extended in the meta-model, introducing the constraint relationship of the mode logic to define the transition logic; The entire mode state transition is a tuple ;in, Represents the set of all states; These represent the sets of input and output attributes for the state transition, respectively. , representing the set of state transitions, This represents the set of state transition conditions formed by combinations of input attribute values; The transition from the source pattern state to the target pattern state can be written as... ； Indicates the initial state; Indicates the final state; , represents a composite state, with nested substates and transitions between substates.

5. The method for modeling and verifying mode conversion of civil aircraft automatic flight control system based on SysML according to claim 2, characterized in that, The attributes of the mode and inter-module communication interaction include variables and events; the variables are used to describe changes and transmissions of state, parameters or data.

6. The method for modeling and verifying mode conversion of civil aircraft automatic flight control system based on SysML according to claim 1, characterized in that, The implementation process of step (4) is as follows: When generating the finite state machine model, the design is based on SysML configuration files and NuSMV. First, the individual patterns and function call relationships within the modules are roughly defined in text. The naming is consistent with the internal function Process naming of the SysML profile pattern. The parameters called inside the function are the Attributes and Events that the Process needs to call. The function call relationship describes the interaction relationship between the pattern and the module. In the mapping of the NuSMV model text description, the variables and events for schema invocation are defined in the parameter section; the variables define the state of the schema. The transition between variable assignment and definition states is described; the VAR of NuSMV is used to describe the possible values ​​of flight mode state categories or events or variables processed by modules, and the above information is initialized at ASSIGN using the init statement, and the value is updated in the next statement according to the combination conditions in the submodule parameter, that is, the state transition of the original STM. Consistent with the hierarchical structure of the model during the conversion process, the above specifications and CTL specifications are combined into a NuSMV module. This module is then input into the NuSMV model for inspection to obtain the verification results. After verification, all security verification statements result in TRUE, indicating that the system meets the security requirements. Once all behaviors in the pattern transformation domain have been verified as correct, the entire model is considered to have passed verification.

Images