Civil aircraft automatic flight control system mode conversion modeling and verification method based on SysML

Abstract

The invention discloses a method for modeling and verifying civil aircraft automatic flight system mode conversion based on a SysML language, and the method comprises the steps: firstly analyzing the key problems of high-level abstraction, hierarchical design, mode conversion logic and priority features in formalized modeling oriented to the field in detail, and constructing a meta-model for flight control mode design and conversion; secondly, expanding the formalized modeling language SysML based on the provided meta-model, and encoding the formalized modeling language SysML into a SysML profile file with a specific field; and then designing in an automatic flight system mode conversion modeling project of a certain type of civil aircraft by using an expanded SysMLprofile, and verifying the safety and correctness of the model by adopting an NUSMV. The invention provides a relatively complete and unified model building thought in the related fields of the automatic flight system, and can effectively ensure the system design quality and improve the system development efficiency and safety.

Description

Technical Field

[0001] The present invention relates to the fields of automatic flight control systems, formal modeling and verification, and in particular to a SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method. Background Art

[0002] After presetting the system functions and working status, the Automatic Flight Control System (AFCS) can receive input signals from relevant flight sensors and the pilot's command selection in real time during the flight, without the need for direct operation by the pilot, and can automatically control and stabilize the aircraft's attitude, track, and airspeed. The automatic flight system covers dozens of flight modes. In different stages of automatic flight, the essence is flight mode conversion, and the automatic flight control system implements the control task, and each control task corresponds to one or more control modes. Flight mode conversion determines flight safety, and confusion in flight mode conversion logic will lead to serious system hazards or disasters.

[0003] Traditional and widely used text-based system engineering (TSE) in the aviation field has defects: relying only on text and simple graphics to express system design solutions cannot fully convey the design details and key information of complex systems; system design documents may have problems with vague or ambiguous expressions, affecting subsequent design understanding and implementation; the lack of an effective team information interaction mechanism leads to design information islands and low team collaboration efficiency. These defects seriously restrict the efficient design and development of complex aviation systems, and meeting the stringent requirements of modern aviation systems for safety and reliability will face major challenges. Therefore, innovative system engineering methods are urgently needed to make up for the above shortcomings in order to better support the design and development of aviation systems.

[0004] However, since the aviation system takes safety as the key goal, the modeling results and requirement models using various system modeling languages ​​such as SIMULINK have consistency and safety verification problems. Different from complex systems in other fields, aviation systems have stringent requirements for safety. Due to the characteristics of multi-level and multi-dimensional system structure, numerous flight modes, complex mode conversion logic, and priority relationships between event triggers in the field, the modeling of the system in the field is very complex. Taking the event trigger priority as an example, in the traditional automatic flight system modeling, the traditional SIMULINK-based modeling method uses basic logic gate circuits such as NOT gates, AND gates, and OR gates for combined modeling to achieve priority determination. However, with the increase in the scale and complexity of flight control systems, this simple logic gate circuit modeling method has gradually become inflexible and inmaintainable.

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

[0006] Although SysML is a relatively mature system modeling language, it is still a semi-formal modeling language in essence. The underlying semantics of the SysML model are difficult to fully express, such as key features such as the relationship between input / output ports. This lack of semantic expression makes it impossible to fully automate the SysML model in the early stages of system design. Formal modeling and verification techniques are particularly important for complex and critical aviation systems such as automatic flight control systems. They can make up for the shortcomings of the SysML modeling language, help engineers comprehensively analyze the various behavioral characteristics of the system in the early stages of design, 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: The present invention provides a SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method, which effectively ensures the design quality of the civil aircraft automatic flight control system and improves development efficiency and safety.

[0008] Technical solution: The SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method of the present invention specifically includes the following steps:

[0009] (1) Analyze the high-level abstraction, hierarchical design, mode transition logic and priority feature issues in the formal modeling of automatic flight control, and build a domain-based meta-model for mode transition of AFCS;

[0010] (2) Extend the formal modeling language SysML based on the proposed metamodel and encode it into domain-specific SysML profile files;

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

[0012] (4) Combined with the structural information of the semi-formal SysML model, the FSM text description is extracted from the model, and the corresponding CTL specification is generated in combination with the extracted system safety requirements. The security and correctness of the model are verified using NUSMV.

[0013] Furthermore, the metamodel 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 interactions; and defines domain characteristics including mode and module attribute characteristics, and communication interactions between modes and modules; for the system core mode conversion, the metamodel uses the state machine diagram as a prototype, defines mode conversion and state migration 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 equipment that are coupled and interacted with the flight modes; the metamodel distinguishes and defines the formal semantics of trigger events and conditions involved in flight mode conversion; the event is a comparison of changes between two consecutive states before and after the system behavior, which is used to indicate a specific operation or condition that occurs, and refers to a transient behavior; the 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.

[0015] Furthermore, the mode conversion and state migration are defined by a state machine diagram and extended in the metamodel, and the constraint relationship of the mode logic is introduced to define the conversion logic; the entire mode state transfer 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 Respectively represent the input / output attribute sets of state transitions; represents a state transition set, cond represents a state transition condition set consisting of a specific value combination of input attributes; the transition from the source mode state to the target mode state can be written as δ:s s ×cond→s t ; s0∈S, represents the initial state; s f ∈S represents the final state; Represents a composite state, nested substates within it, and transitions between substates.

[0016] Furthermore, the attribute characteristics of the communication interaction between the modes and modules include variables and events; the variables are used to describe the change and transfer of states, parameters or data.

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

[0018] Define the standard syntax for the basic semantic elements of the domain metamodel, and build new modeling element stereotypes based on the SysML profile extended from the UML definition, including:<Flight_Modes_Atomic> > and <<Flight_Modes_Coupled> >Extended from SysML::< <block>>; Structural type< <event>>Describes the event information of the mode transition domain extended from SysML< <attribute>>; Structural type< <process>>Description mode internal state transfer extended from < <statemachine>> Extend the domain profile element with additional features using profile relationship and tag attributes.

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

[0020] According to the functional requirement analysis, the block definition diagram is used to describe the static structure information of the system; at the mode level of the flight approach and landing phase, it is divided into horizontal and vertical according to the dimensional information; the mode level flight mode of the near landing phase is constructed through the affiliation relationship and the connection between the specific modes under the level; the high-level flight mode achieves the flight goal by integrating and coordinating multiple low-level specific flight modes, and is connected through SysML's <<partial connection>> to form a diagrammatic hierarchical flight mode model structure; during the approach, there is a complex interactive relationship between the flight mode and the external avionics equipment and the flight personnel. The structural <<module>> is used to build the subsystem that interacts with the flight mode, and is connected through the extended interactive relationship.

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

[0022] Mode conversion is defined in the internal block diagram of each flight mode. A "process" structure that can be divided into three layers vertically is built in the ibd of the structural type <<mode>> heading selection mode, including two input processes, three encapsulation processes and three output processes. In terms of execution sequence, it can be seen that there is an execution direction of input process->encapsulation process->output process. Information exchange between functions is through <<flow>>, and the execution order and hierarchical relationship are maintained. Processes at different levels can only obtain <<variables>> and <<events>> of the previous level or the current level.

[0023] The modules are consistent with the mode management and control layer in terms of execution order and attribute processing;

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

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

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

[0027] The naming is consistent with the naming of the internal function Process of the SysML profile mode. The parameters called inside the function are the Attributes and Events that the Process needs to call. The calling relationship of the function describes the interaction between the mode and the module.

[0028] In the mapping of the NuSMV model text description, the variables and events of the mode call are defined in the parameter part; the variables define the state of the mode; the variable assignment defines the transition between states; the NuSMV VAR is used to describe the possible values ​​of the flight mode state category or the event or variable processed by the module, and the init statement is used at the ASSIGN to initialize the above information, and the value is updated in the next statement according to the combined conditions in the submodule parameter, that is, the state migration of the original STM;

[0029] In the conversion process, consistent with the hierarchical structure of the constructed model, the above specifications and CTL specifications are combined into a NuSMV module, and the module is input into the NuSMV model for inspection to obtain the verification results; after verification, all security verification statements are TRUE, and the system is judged to meet the security requirements; after all behaviors in the mode conversion field are verified correctly, the entire model is judged to have passed the verification.

[0030] Beneficial effects: Compared with the prior art, the present invention has the following beneficial effects:

[0031] The present invention comprehensively considers the concepts and characteristics of the civil aviation field, semantically defines SysML at the metamodel level, and encodes it into a SysMLprofile, which can provide display semantics for modeling elements used for automatic flight control mode conversion; uses NUSMV to strictly analyze and verify the model, and if there is a verification counterexample that does not meet the safety requirements, the error is tracked, located, modified and re-verified through the counterexample; adopts strict formal modeling and verification to effectively ensure the design quality in the field of flight control systems and improve development efficiency and safety. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 is a schematic diagram of the present invention;

[0033] Figure 2 This is a schematic diagram of the metamodel of the automatic flight control system for civil aircraft;

[0034] Figure 3 SysML profile definitions for components and flows;

[0035] Figure 4 SysML profile definitions for attributes and processes;

[0036] Figure 5 Design diagram of block definition diagram for civil aircraft automatic flight control system;

[0037] Figure 6 Design diagrams for the internal block diagrams of flight modes;

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

[0039] Figure 8 Design diagram for the internal block diagram of flight mode priorities. DETAILED DESCRIPTION

[0040] The present invention is further described in detail below with reference to the accompanying drawings.

[0041] like Figure 1 As shown, the present invention provides a SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method, adopts formal modeling and verification methods, defines the metamodel of the civil aircraft automatic flight control system and extends the SysML profile for modeling in this field, and uses NUSMV to verify the security and correctness of the modeling results, effectively ensuring the design quality in the flight control system field and improving the development efficiency and safety, specifically including the following steps:

[0042] Step 1: Metamodel design.

[0043] Obtain the mode conversion requirements of civil aircraft automatic flight systems and the airworthiness regulations and industry standards related to automatic flight control systems at home and abroad, and sort out the key issues in demand modeling such as high-level abstraction, hierarchical design, mode conversion logic and priority characteristics based on the system engineering documents in the field. According to the above requirements and modeling problems, the system-based model engineering MSBE method is used to build a domain metamodel, expand and design information such as components, features and functions in the field. The metamodel divides the high-level abstraction of the system into a collection of components that manage flight modes separately and participate in mode interaction. And define the characteristics in the domain, including mode and module attribute characteristics, mode and module communication interaction, etc. For the core mode conversion of the system, the metamodel uses the state machine diagram as the prototype, defines the mode conversion and state migration functions, and constructs the constraint relationship with the mode logic.

[0044] Mode conversion and state migration are defined through state machine diagrams and extended in the metamodel. The constraint relationship of mode logic is introduced to define the conversion logic. The entire mode state transfer 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 Respectively represent the input / output attribute sets of state transitions; represents a state transition set, cond represents a state transition condition set consisting of a specific value combination of input attributes; the transition from the source mode state to the target mode state can be written as δ:s s ×cond→s t ; s0∈S, represents the initial state; s f ∈S represents the final state; Represents a composite state, nested substates, and transitions between substates. When a composite state is activated, it first enters the subinitial state; during the activation of a composite state, only one substate is always active.

[0045] The modeling elements included in SysML can meet most of the description requirements of system-oriented modeling. Considering the domain characteristics of AFCS mode conversion, it is first expanded and designed at the metamodel level. For the present invention, the metamodel is a model that can provide specified concepts for research domain modeling. Therefore, in actual modeling, each view of the system exists as an instance of the metamodel. Figure 2 The meta-model proposed by the present invention based on the AFCS mode conversion domain requirements is shown. All elements in the figure provide directions for the extension based on SysML.

[0046] The metamodel divides the core components into a set of multi-dimensional flight modes (flight mode atomic set) and a set of flight electronic equipment (such as flight control panel) that are coupled and interacted with the flight modes (flight mode coupling); the metamodel distinguishes and defines the formal semantics of trigger events and conditions involved in flight mode conversion. Events are essentially the change comparison between two consecutive states before and after the system behavior; conditions are predicates satisfied on 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 to represent the set of events such as device reception, sending variables, and state changes, and data input / output represents the set of events such as flight mode reception, sending variables, and state changes. The specification of the corresponding port defines the transmission name and type.

[0047] Attributes, states, and transition functions are the meta-model parts that constitute the coupled flight equipment, representing its attribute characteristics (flight variables or events), internal states, and transition function sets. The above models are combined to form the internal model of the coupled equipment and are implemented through the state machine model. Mode attributes, states, and transition functions are the meta-model parts that constitute the flight mode, representing the attribute characteristics of the mode, multi-dimensional mode states, and mode transition function sets. Attributes are refined into events and variables, and the flight parameter values ​​they represent are subject to flight mode logic constraints; 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 mode state sets and their values, and their values ​​are determined by the combination of internal variables / events of the transition conditions; transition conditions, output functions, and input functions are subject to mode logic constraints and constitute mode transition functions.

[0048] Step 2: Based on the proposed metamodel, the formal modeling language SysML is extended and encoded into a domain-specific SysMLprofile file.

[0049] Define the standard syntax for the basic semantic elements of the domain model. Construct new modeling element stereotypes based on the SysML profile extended from the UML definition, including:<Flight_Modes_Atomic> > and <<Flight_Modes_Coupled> >Extended from SysML::< <block>>; Structural type< <event>>Describes the event information of the mode transition domain extended from SysML< <attribute>>; Structural type< <process>>Description mode internal state transition extended from < <statemachine>>. Use profile relationship and tagged value attributes to extend the domain profile element with additional features.

[0050] This embodiment extends SysML based on the proposed metamodel concept and encodes it into a SysMLprofile file. Based on the automatic flight domain mode conversion feature, it provides a specific syntax for specifying appropriate stereotypes and the relationship between stereotypes. Figure 3 It indicates that it extends the profile definition of the model composition and the flow of information interaction. <<Flight Mode_Atom>> and <<Flight Mode_Coupling>> are the flight modes and coupling components classified in the metamodel, which are extended from SysML::Block Definition Diagram. It is further refined into the stereotypes <<Mode>> and <<Module>>, where <<Mode>> contains four flight dimensions <<Dimension>>. According to different interactive devices, it is further divided into the stereotypes <<Sensor Module>> and <<Display Module>> under the module. The stereotypes used to represent the interaction relationship between modes / modules are extended from << <dependency>>.

[0051] In the model, the functional modules process the input data to generate output data, that is, the modules interact with each other through the signal, material or energy flow. In the actual flight process, the mode of the flight control system processes the input information of the interactive mode / module to perform mode conversion and generate output information. Our metamodel expresses the interactive information with the flow attribute stereotype. The stereotype <<flow>> connects the output port of the source module / mode and the input port of the target module / mode, and binds the stereotype <<communication>> extended from <<flow attribute>> through tagged value. Combined with the attribute characteristics of the metamodel, SysMLprofile constructs the stereotypes <<variable>> and <<event>>. According to the sending direction, <<communication>> binds the attribute characteristics of the output level.

[0052] The attribute features <<variable>> and <<event>> defined in the Profile are extended from SysML::Attribute and encode the respective elements on the metamodel transmission, such as Figure 4 As shown in the figure. The structure type <<variable>> describes the flight status or aviation parameters (flight altitude, vertical speed, etc.), and the structure type <<event>> describes the flight event, such as the change of flight status. And combined with the hierarchical characteristics, it is further generalized and divided into input, encapsulation and output, corresponding to the hierarchical processing. In order to express the priority of the event, the structure type <<priority>> extended from SysML::Block is constructed.

[0053] Based on the characteristics of the domain, in the automatic flight system, the state transition between the main functional modes and the internal processing of the attributes of the related modes / modules can be represented by the state transition in the state machine, so the structural type < <process>>Extended from SysML::StateMachine. In specific modeling, the execution process inside a single mode / module has a direction and execution sequence, so Figure 4 The <<process>> is vertically layered and also divided into input, encapsulation and output. In order to maintain the hierarchical characteristics within the mode / module and establish the connection between the process and the variable / event in the metamodel, the process and the variable / event at the same level in the profile are connected and represented by tagged value. The process is only allowed to receive the variable / event output of the process at the previous level or the same level as the input of the current level. The construction type <<transition matrix>> extended from SysML::block definition diagram is defined to represent the conditions for mode state transition, such as the value combination of flight events.

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

[0055] Based on the example of AFCS mode transition project, we apply the extended SysMLprofile to model the system mode transition domain and then formally verify the model.First, the automatic flight system mode transition domain is hierarchically modeled.

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

[0057] According to the functional requirements analysis, the block definition diagram is used to describe the static structure information of the system, such as Figure 5 As shown. In the mode hierarchy of the flight approach and landing phase, it is first divided into horizontal and vertical modes according to dimensional information. The flight mode of this layer (such as the horizontal mode) is connected to the specific modes (such as the heading selection mode) under the hierarchy through the subordinate (sub-mode) relationship. The high-level flight mode integrates and coordinates multiple low-level specific flight modes to achieve the flight goal, and is connected through SysML's <<partial connection>> to form a diagrammatic hierarchical flight mode model structure; during the approach, there is a complex interactive relationship between the flight mode and the external avionics equipment and the flight personnel. The subsystem that interacts with the flight mode is constructed using the structural <<module>> and connected through extended interactive relationships. It includes the flight control management panel, as well as related conceptual entities such as flight guidance and autopilot.

[0058] Next, in order to maintain the hierarchical characteristics of the model, the execution order and attribute processing of the relevant modules are consistent with the mode management and control layer. This is reflected in the execution order and attribute processing of the process on the internal block diagram IBD.

[0059] In the flight mode conversion during the approach phase, there are many coupling situations between modes of different dimensions, involving the interaction of conversion conditions. Therefore, it is necessary to establish interactive channels for mode state information and flight events between modes and between modes / modules to achieve a coupled and compatible multi-dimensional static structure. Define extended input / output at the boundary of the mode and module structure. Take 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 working mode, which is used to instruct the aircraft to maintain the heading selected on the flight control management panel. The pilot presses the heading selection mode switch on the flight control management panel to turn it on. The panel sends the flight event <<When the heading selection mode is pressed>> to the heading selection mode to update its internal mode state to be turned on. These events are stored through the stream attribute <<Flight Control Panel->Heading Selection Mode>> and connected through streams and ports.

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

[0061] Step 3.2: Mode transition modeling.

[0062] Mode conversion is a core modeling requirement within the AFCS system, involving many flight modes and complex logic. Mode conversion is defined in the internal block diagram of each flight mode, such as Figure 6 As shown in the figure, a "process" structure that can be divided into three layers vertically is built in the ibd of the structural type <<mode>> heading selection mode, including two input processes, three encapsulation processes and three output processes. In terms of the execution sequence, it can be seen that there is an execution direction of input process->encapsulation process->output process. The information exchange between functions is through <<flow>>, and the execution order and hierarchical relationship are maintained. Processes at different levels can only obtain <<variables>> and <<events>> of the previous level or the current level.

[0063] Specific to HDG mode, such as Figure 7 As shown, the modeling of the state machine diagram is shown. The state transition of the HDG mode is affected by the flight events in the mode that release the heading selection mode and select the heading selection mode. The combination of these event values ​​is used as the condition for the mode state transition. When the heading selection mode selection event is 1, that is, the value is true, and the previous state of the HDG mode is clear, the HDG state transitions to selection, indicating that it is connected. The value of another event that releases the heading selection mode has no effect and is marked as x. In the modeling, <<State Transition Matrix>> stores the conditional values, and by extending << <transition>> and bind the stereotype of the transition matrix <<transfer>> to connect the transformed states.

[0064] Step 3.3: Event priority modeling.

[0065] SysML profile extends the SysML language and uses a combination of stereotypes, priorities, events, and processes for handling events in specific modeling, which can better express the requirements of specific fields. Figure 8 For specific explanation. Taking the module FMCP requirement as an example, there is a priority relationship between flight events such as the pilot pressing the mode button on the FMCP. Taking the heading selection mode (HDG) and approach mode (APPR) mode in the approach and landing phase as an example, no other lateral mode is pre-positioned when the HDG mode is executed. When the pilot presses the APPR switch on the FMCP, APPR is turned on and the aircraft begins to approach. Once the LOC is activated from the pre-position, the HDG is canceled. The priority of the APPR button press event is higher than the HDG button press event.

[0066] The specific 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 needs to be blocked. When modeling, the approach mode is used as a pre-processing process with no event priority higher than the heading selection mode, and the change in the value of the corresponding flight event with the same name will affect the priority within the subsequent process, that is, the condition of the module state migration, and then determine whether to block the subsequent processing flow. This modeling method can accurately express the event priority determination relationship and output it to the required mode or module for use.

[0067] Step 4: Verify the security of modeling results.

[0068] In the field of AFCS mode conversion, SysMLprofile, an extension of the original modeling language of SysML, is used to build domain hierarchical models. However, since the modeling language is semi-formal in nature, it is impossible to directly verify the resulting model. To solve this problem, NuSMV was selected as a model checker, which can automatically verify finite state machine (FSM) systems and system specifications based on CTL or LTL descriptions.

[0069] In the verification process, the key steps are divided into the following parts: first, the FSM text description is extracted from the model in combination with the structural information of the model; then the system safety requirements are extracted to generate the corresponding CTL specifications; finally, the extracted FSM model and CTL specifications are combined into the NuSMV module to be verified for automatic verification. If the verification fails, the checker will return the corresponding counterexample for model modification.

[0070] As an extension of the state machine, the function Process can directly realize the mapping of model elements to the FSM text description. On the other hand, the proposed SysMLprofile file collects model conversion requirements and hierarchical characteristics, and the core ideas of the modeling language can be reused in the FSM text.

[0071] In the FSM model generation, based on SysMLprofile and NuSMV language, the function call relationship within a single mode / module is roughly defined in text. Taking HDG mode as an example, HDG mode converts bdd and < <mode>>The structure of HDG's ibd is visible Figure 5 and Figure 6 , combined with the structure and internal mode transition information, a natural language description is defined: During the complete system operation, if state / event E occurs, state / event F will occur and will cause state / event G to occur. The corresponding logical expression is: AG(E->AX(F->G)). The CTL expression corresponding to NuSMV is:

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

[0073] The naming is consistent with the naming of the internal function Process of the SysML profile mode. The parameters called inside the function are the Attributes and Events that the Process needs to call. The calling relationship of the function describes the interaction relationship between modes / modules.

[0074] In the mapping of the NuSMV module text description, the variables / events of the mode call are defined in the parameter part; the variable definition (VAR part) defines the state of the mode; and the variable assignment (ASSIGN part) defines the transition between states. The NuSMV VAR is used to describe the possible values ​​of the flight mode state category or the event or variable processed by the module, and the init statement is used at the ASSIGN to initialize the above information, and the value is updated in the next statement according to the combination conditions in the submodule parameter, that is, the state migration of the original STM. In the conversion process, consistent with the hierarchical structure of the constructed model, the above specifications and CTL specifications are combined into a NuSMV module, and the module is input into the NuSMV model check to obtain the verification results. After verification, the results of all safety verification statements are TRUE, and the system is judged to meet the safety requirements. After all behaviors in the mode conversion field are verified correctly, it can be judged that the entire model has passed the verification.

[0075] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as 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 SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method, characterized in that: The following steps are involved: (1) Analyze the high-level abstraction, hierarchical design, mode transition logic and priority feature issues in the formal modeling of automatic flight control, and build a domain-based meta-model for mode transition of AFCS; (2) Extend the formal modeling language SysML based on the proposed metamodel and encode it into domain-specific SysML profile files; (3) Conduct hierarchical modeling of the automatic flight control system mode transition domain: structural modeling of mode transition, mode transition modeling, and event priority modeling; (4) Combined with the structural information of the semi-formal SysML model, the FSM text description is extracted from the model, and the corresponding CTL specification is generated in combination with the extracted system safety requirements. The security and correctness of the model are verified using NUSMV.

2. The SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method according to claim 1 is characterized in that: The metamodel in step (1) divides the high-level abstraction of the system into a set of components that manage flight modes individually and participate in mode interactions; and defines domain features including mode and module attribute features, and communication interactions between modes and modules; For the core mode transition of the system, the metamodel uses the state machine diagram as a prototype, defines the mode transition and state migration functions, and constructs constraint relationships with the mode logic.

3. The SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method according to claim 1, characterized in that: Step (1) The core components of the metamodel are divided into a set of multi-dimensional flight modes and a set of flight electronic equipment that are coupled and interacted with the flight modes; the metamodel distinguishes and defines the formal semantics of trigger events and conditions involved in flight mode conversion; the event is a comparison of changes between two consecutive states before and after the system behavior, which is used to indicate a specific operation or condition that occurs, and refers to a transient behavior; The conditions are predicates satisfied on a single state, and more complex semantics such as conditional events can be further defined based on variable state semantics.

4. The SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method according to claim 2 is characterized in that: The mode conversion and state migration are defined by the state machine diagram and extended in the metamodel, and the constraint relationship of the mode logic is introduced to define the conversion logic; the entire mode state transfer 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 Respectively represent the input / output attribute sets of state transitions; represents a state transition set, cond represents a state transition condition set consisting of a specific value combination of input attributes; the transition from the source mode state to the target mode state can be written as δ:s s ×cond→s t ; s0∈S, represents the initial state; s f ∈S represents the final state; Represents a composite state, nested substates within it, and transitions between substates.

5. The SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method according to claim 2 is characterized in that: The attribute characteristics of the communication interaction between the modes and modules include variables and events; the variables are used to describe the change and transfer of states, parameters or data.

6. The SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method according to claim 1, characterized in that: The implementation process of step (2) is as follows: Define the standard syntax for the basic semantic elements of the domain metamodel, and build new modeling element stereotypes based on the SysML profile extended from the UML definition, including:<Flight_Modes_Atomic> > and <<Flight_Modes_Coupled> >Extended from SysML::< <block>>; Structural type< <event>>Describes the event information of the mode transition domain extended from SysML< <attribute>>; Structural type< <process>>Description mode internal state transition extended from < <statemachine> > Extends the domain profile element with additional features using profilerelationship and tag attributes.< / statemachine> < / process> < / attribute> < / event> < / block> 7. The SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method according to claim 1, characterized in that: The structural modeling implementation process of the mode conversion in step (3) is as follows: According to the functional requirement analysis, the block definition diagram is used to describe the static structure information of the system; at the mode level of the flight approach and landing phase, it is divided into horizontal and vertical according to the dimensional information; the mode level flight mode of the near landing phase is constructed through the affiliation relationship and the connection between the specific modes under the level; the high-level flight mode achieves the flight goal by integrating and coordinating multiple low-level specific flight modes, and is connected through SysML's <<partial connection>> to form a diagrammatic hierarchical flight mode model structure; during the approach, there is a complex interactive relationship between the flight mode and the external avionics equipment and the flight personnel. The structural <<module>> is used to build the subsystem that interacts with the flight mode, and is connected through the extended interactive relationship.

8. The SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method according to claim 1, characterized in that: The mode conversion modeling implementation process in step (3) is as follows: Mode conversion is defined in the internal block diagram of each flight mode. A "process" structure that can be divided into three layers vertically is built in the ibd of the structural type <<mode>> heading selection mode, including two input processes, three encapsulation processes and three output processes. In terms of execution sequence, it can be seen that there is an execution direction of input process->encapsulation process->output process. Information exchange between functions is through <<flow>>, and the execution order and hierarchical relationship are maintained. Processes at different levels can only obtain <<variables>> and <<events>> of the previous level or the current level. The modules are consistent with the mode management and control layer in terms of execution order and attribute processing; Establish interactive channels for mode state information and flight events between modes and between modes and modules to achieve a coupled and compatible multi-dimensional static structure; Define the inputs and outputs of extensions at the schema and module structure boundaries.

9. The SysML-based civil aircraft automatic flight control system mode conversion modeling and verification method according to claim 1, characterized in that: The implementation process of step (4) is as follows: When generating a finite state machine model, the design is based on the SysML profile and NuSMV. First, the function call relationships within the individual modes and modules are roughly defined in text; The naming is consistent with the naming of the internal function Process of the SysML profile mode. The parameters called inside the function are the Attributes and Events that the Process needs to call. The calling relationship of the function describes the interaction between the mode and the module. In the mapping of the NuSMV model text description, the variables and events of the pattern call are defined in the parameter part; the variables define the state of the pattern; Define the transition between states in variable assignment; use NuSMV's VAR to describe the flight mode state category or the possible values ​​of the event or variable processed by the module, and use the init statement at ASSIGN to initialize the above information, and update the value according to the combination conditions in the submodule parameter in the next statement, that is, the state migration of the original STM; In the conversion process, the above specifications and CTL specifications are combined into a NuSMV module in accordance with the hierarchical structure of the constructed model. The module is input into the NuSMV model for inspection to obtain the verification results. After verification, all security verification statements are TRUE, and the system is judged to meet the security requirements. After all behaviors in the mode conversion field are verified to be correct, the entire model is considered to have passed verification.

Images