Modeling method, medium and equipment for formal demand model with hierarchical features

Abstract

The invention provides a modeling method, a medium and equipment for a formal demand model with hierarchical characteristics, which comprises the following steps of: according to a natural language demand to be processed, dividing according to a system hierarchy, dividing demand entries in a demand document into sets according to a logical relationship, and dividing each set into a module; according to the divided demands, mode conversion type demands are separated from each module to be summarized, and for the remaining demands, the remaining demands are classified into conditional demands and event type demands according to the modules; constructing a domain concept library according to the divided original requirements; modeling the condition / event type demand according to the demand standardization template and generating an equivalent formalized description process; and generating an HVRM model according to the traceability relationship among the modeling elements. According to the method, the model-driven technology is adopted, the problem can be effectively recognized from the software requirement level, the problem can be accurately positioned, and therefore the development quality and safety of an airborne software system are greatly improved.

Description

Technical Field

[0001] The present invention belongs to the field of formal modeling, analysis and verification of airborne safety-critical software, and particularly relates to a modeling method, medium and device for a formal requirement model with hierarchical characteristics. Background Art

[0002] The Automatic Flight Control System (AFCS) is one of the crucial safety-critical systems in modern aircraft, which includes components such as the Flight Guidance Control System (FGCS), Auto Thrust (AT), and Auto Land (AL). The design and verification of the automatic flight control system require extremely high precision and reliability, because any error may lead to serious consequences. Therefore, formal methods play an increasingly important role in the design and verification of the automatic flight control system.

[0003] The formal method is a technique that uses mathematical language to describe and verify system specifications. The advantage of this method is that it can provide strict mathematical proofs to ensure the correctness and safety of the system. In the automatic flight control system, the formal method can be used to model and verify the flight mode transition logic. The flight mode transition logic refers to how the system switches from one mode to another under different flight states. Since there are dozens of flight modes and the mode transition logic is very complex, problems such as mode confusion are likely to occur. Through the formal method, the correctness and safety of the system can be improved. Summary of the Invention

[0004] Aiming at the problems of lack of precision and automated verification in the traditional way of describing requirements in natural language, the present invention proposes a modeling method, medium and device for a formal requirement model with hierarchical characteristics. The present invention first proposes a formal model VRM, designs a method to convert the original requirements described in natural language with ambiguity into a formal model with unique semantics, and introduces hierarchical semantics into the model to support larger-scale modeling of the safety requirements of the system, forming the HVRM model; finally, the present invention constructs an ART requirement tool platform to support the above content and can provide support for the integrity and consistency analysis of the subsequent HVRM model.

[0005] To achieve the above object, the present invention adopts the following technical solutions:

[0006] In the first aspect, the present invention provides a modeling method for a formal requirement model with hierarchical characteristics for an automatic flight system, including the following steps:

[0007] Step 1: Clearly define the requirements described in natural language and eliminate ambiguous information in the requirements;

[0008] Step 2: Determine the interaction relationships between different requirements and classify the hierarchical relationships of the requirements;

[0009] Step 3: Split the requirements, extract domain entities; after removing the domain entities, classify the requirements into conditional requirements, event-based requirements, and pattern conversion requirements by using the remaining words and sentences in the requirements and combining with the current domain characteristics;

[0010] Step 4: Build a domain concept library based on the domain entities extracted in Step 3;

[0011] Step 5: According to the domain concept library and the requirement content, fill each requirement into a two-dimensional table in the format of a set requirement template to convert it into a standardized requirement. The two-dimensional table includes a condition table, an event table, and a pattern conversion table, corresponding to conditional requirements, event-based requirements, and pattern conversion requirements respectively;

[0012] Step 6: For the constructed two-dimensional table, establish the dependency relationships of the same variable in different tables;

[0013] Step 7: According to the constructed domain concept library and standardized requirements, perform semantic conversion with the HVRM model, and fill in the elements required by the HVRM model item by item to generate the HVRM model.

[0014] Optionally, Step 1 includes: analyzing the requirement source, analyzing the context of the requirement, refining the requirement, defining the terms used in the requirement, and confirming the understanding of the requirement.

[0015] Optionally, Step 2 includes: according to the requirement content, divide the FGCS into AP, FD, and pattern conversion from the top level; AP is responsible for turning on and off the automatic driving; FD is responsible for turning on and off the flight guidance; the pattern conversion is responsible for the three-axis attitude control of the aircraft, and is abstracted into three independent mode sets: lateral mode, longitudinal mode, and multi-axis mode according to the hierarchical relationship;

[0016] The mode set is defined as <key, M, SM, m_parent>, representing the name of the mode set, the modes included in the mode set, the conversion events between different modes in the mode set, and the parent mode of the mode set respectively; the definition of the mode is <key, isStart, isEnd>, representing the name of the mode, whether it is the initial mode, and whether it is the end mode respectively.

[0017] Optionally, in step 3, when the requirement entity is a feedback on a premise, if it focuses on preservation, it is identified as a conditional requirement, and if it focuses on change, it is identified as an event-based requirement; when there is a pattern conversion rule in the requirement, it is identified as a pattern conversion requirement.

[0018] Optionally, in step 4, the domain concept library includes terms, data types, input variables, intermediate variables, output variables, constants, and a pattern set;

[0019] The input variables, intermediate variables, and output variables are respectively the entity elements in the requirement that are input from the outside, used internally alone, and output to the outside.

[0020] The data types are set as follows: for the extracted variables, find the positions where their corresponding entity information appears in the requirement, and based on the possible actions or the value ranges of the signal quantities, sort out the value ranges and set the corresponding data types;

[0021] The value ranges are divided into integer value ranges, floating-point value ranges, enumerated value ranges, and boolean value ranges;

[0022] The pattern set is constructed according to a directed graph. Each pattern is a node of the directed graph, and each model conversion relationship specified in the requirement is an edge between the corresponding nodes in the directed graph.

[0023] Optionally, in step 5, the set requirement template formats include a general condition / event template and a display condition / event template. The display condition / event template is used to normatively represent the condition / event-based requirements that determine the display formats of certain data or images of system components, while the condition / event-based requirements for other functions are normatively represented using the general condition / event template;

[0024] The specified requirement is defined as <originalID, mode, content>. originalID records which original requirement the specified requirement comes from, mode indicates in which working mode of the system the requirement content defines the response situation, and content is the main content of the specified requirement.

[0025] Optionally, in step 6, the dependency relationship includes a first type of mapping from an intermediate variable to an input variable and a second type of mapping from an intermediate variable to an intermediate variable.

[0026] Optionally, in step 7, the HVRM model includes V, MODULE, F, and MAPPING; V represents a variable dictionary, indicating the variables owned by the autopilot system; MODULE represents a module, indicating the hierarchical relationship of the autopilot system; F includes a condition table, an event table, and a pattern conversion table; MAPPING includes a first type of mapping and a second type of mapping.

[0027] In a second aspect, the present invention provides a computer-readable storage medium storing a computer program, which causes a computer to execute the method for modeling a formal requirements model with hierarchical characteristics as described in the first aspect.

[0028] In a third aspect, the present invention provides an electronic device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the method for modeling a formal requirements model with hierarchical characteristics as described in the first aspect is implemented.

[0029] The beneficial effects of the present invention are as follows: The present invention fully considers the deficiencies in the prior art in requirements modeling and analysis based on specific formal methods, and independent tools and frameworks, and proposes an HVRM model for relatively large requirements documents with a hierarchical structure, and correspondingly designs a complete modeling process framework and a corresponding tool platform. The present invention adopts model-driven technology, and can systematically analyze and verify the HVRM model generated from software requirements in the future, and can effectively identify problems at the software requirements level and accurately locate the problems, thereby greatly improving the development quality and safety of airborne software systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 It is a flowchart of a method for modeling a formal requirements model with hierarchical characteristics.

[0031] Figure 2 It is the judgment basis for determining whether the original requirements are conditional or event-based requirements.

[0032] Figure 3 It is a schematic structural diagram of the HVRM model of FGCS in the generated automatic flight control system. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0033] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0034] In one embodiment, the present invention proposes a method for modeling a formal requirements model with hierarchical characteristics, and the specific process is as Figure 1As shown in the figure. According to the natural language requirements to be processed, first, the chapter entries are divided according to the system level, and the requirement entries in the requirement document are divided into sets according to the logical relationship, and each set is divided into a module; according to the divided requirements, first, the pattern conversion requirements are separated from each module for summary. For the remaining requirements, they are classified into conditional requirements and event requirements according to the module; according to the divided original requirements, a domain concept library is constructed, terms are modeled, model elements are constructed, a pre-built pattern set is constructed, variables are extracted, patterns are filled, pattern conversion events are filled, and variable mapping relationships are generated; according to the requirement normalization template, conditional / event requirements are modeled and an equivalent formal description process is generated; according to the traceability relationship between the modeling elements, an HVRM model is generated.

[0035] Next, taking the requirements of the FGCS part in an automatic flight control system as an example, combined with the attached drawings, the generation process of the HVRM model will be introduced in detail.

[0036] Step 001: Clarify the requirement content and eliminate requirement ambiguity.

[0037] If a complex system is to be formally analyzed and verified, it is first necessary to ensure that there is no obvious ambiguous information in the requirements described in natural language. The general process is as follows:

[0038] Requirement source analysis: First, it is necessary to analyze the requirement source to reduce the ambiguity caused by unclear requirement sources.

[0039] Context analysis: It is necessary to analyze the specific context of each requirement. When the requirements are expressed in natural language, in many cases, ambiguity is caused by the lack of specific context. The same requirement may lead to different understandings in different contexts. A clear context can make the context of the requirement clearer and help eliminate ambiguity.

[0040] Requirement refinement: With the help of intermediate variables, complex requirements are decomposed into smaller sub-requirements. Through refinement, the specific content of the requirements can be determined more accurately, avoiding ambiguity caused by overly general overall requirements; at the same time, determine the boundary range of each requirement, that is, clarify what is included in the requirement and what is not within the scope of the requirement, to prevent ambiguity in the understanding of the requirements.

[0041] Term definition: For professional terms, industry-specific vocabulary or custom-defined concepts used in the requirements, clear definitions are given to avoid ambiguity caused by different understandings of the terms.

[0042] Requirement confirmation and feedback: In the understanding of requirements, record the discovered problems in a timely manner, and regularly organize requirement review meetings with the Party A to ensure that both parties have the same understanding of the requirements and there is no ambiguity.

[0043] Step 002: Sort out the interaction relationships and consider the requirement hierarchy.

[0044] After clarifying the requirement content, due to the complex mode conversion and hierarchical relationships in the automatic flight control system, it is necessary to sort out the interaction relationships between different modes, extract different mode sets, and at the same time consider each requirement hierarchy, and ensure the interaction and information association of each hierarchy through module ports. For a complex system, obvious hierarchical characteristics will be reflected in the internal interaction of the system. For example, many smaller subsystems can be coupled into a larger system to jointly implement a function. If the model lacks hierarchical semantics, the hierarchical characteristics in the requirements will be ignored, the boundaries of the subsystems within the system cannot be clarified, and only overall modeling can be carried out.

[0045] The specific steps of Step 002 are as follows:

[0046] According to the original requirement content, FGCS is divided into AP, FD, and mode conversion from the top level. The mode conversion can be further divided into lateral mode, longitudinal mode, and multi-axis mode.

[0047] AP is responsible for the on / off of autopilot. The states of AP include APEngage state, APDisengage state, and APAvailable state. FD is responsible for the on / off of flight guidance. The states of FD include FD Engage state, FD Disengage state, FD Available state, and FD STDBY state. The value of each state of AP and FD is either true or false. Engage means on, Disengage means off, Available means meeting the minimum configuration for on, and STDBY means in the armed state. If APEngage is true, it means AP is in the on state. If APEngage is false, it means AP does not meet the on condition at this time.

[0048] The mode conversion is responsible for the three-axis attitude control of the aircraft. During the modeling process, according to the hierarchical relationship, it can be abstracted into three independent mode sets.

[0049] In the HVRM model, the definition of the mode set is <key, M, SM, m_parent>, which respectively represent the name of the mode set, the modes included in the mode set, the conversion events between different modes in the mode set, and the parent mode of this mode set; the definition of the mode is <key, isStart, isEnd>, which respectively represent the name of the mode, whether this mode is the initial mode, and whether this mode is the end mode.

[0050] Taking the lateral control mode as an example, it includes the ROLL mode (roll mode), HDG mode (Heading Select), TRK mode (Track Select), LNAV mode (FMS horizontal navigation mode), LOC mode (localizer approach mode), BC mode (automatic back-course mode), and LFLS mode (horizontal FMS landing system mode). Among them, the ROLL mode is the basic mode of the lateral control mode, that is, the initial mode. The initial mode ROLL further includes four modes: Roll hold, Wings Level, Heading Hold, and Track hold. The nesting between modes reflects the hierarchical relationship between models.

[0051] Taking ROLL as an example, from the perspective of the high-level lateral control mode, ROLL is the initial mode of the lateral control mode. From the low-level perspective, the lateral control mode is the parent mode of the ROLL mode, and Roll hold is the initial mode of the ROLL mode.

[0052] Step 003: Summarize the domain characteristics and extract domain entities.

[0053] After clarifying the interaction relationships between different requirements, dividing the hierarchical relationships, and determining the requirement levels, summarize the domain characteristics and extract domain entities according to the divided requirements to assist in judging conditional requirements and event-based requirements.

[0054] (1) When in the LNAV mode and the main FMS (Flight Management System) switches to another FMS, the ROLL mode should be activated.

[0055] (2) When the selected FMS fails, a desynchronization command (FMS_Synchronous = 0) is issued and the AFCS (Automatic Flight Control System) activates the FMS landing (FMS Landing System) mode, the ROLL mode should be activated.

[0056] (3) When in the FMS landing mode and the main FMS fails, when the main FMS switches to the standby FMS within two seconds, the FMS landing mode will continue to run, and in other cases, the ROLL mode will be activated.

[0057] (4) When in the BC or LFLS mode, the AP (autopilot) is activated and the longitudinal mode is not the FPA (flight path angle select) mode, and the APPR pushbutton signal changes from on to off, the ROLL mode should be activated.

[0058] (5) When in the LOC mode, with the AP activated and the longitudinal mode not being the FPA mode, and the auto-landing not being engaged, when the APPR pushbutton signal (the signal emitted when the approach button on the flight mode control panel is triggered) changes from being on to off, the ROLL mode should be activated.

[0059] (6) When in the LOC mode and the auto-landing not being engaged, when any longitudinal mode is engaged after the GS (glide slope approach mode) is activated, enter the Roll Hold sub-mode.

[0060] Taking the above 6 original requirements related to the lateral mode conversion as an example, for the description of step 003, first split each single requirement. Taking (1) as an example, first extract the domain entities, including the LNAV mode, the main FMS, another FMS, and the ROLL mode. The domain entities can be abstracted as variables and mode sets in the construction of the subsequent domain concept library.

[0061] After removing the domain entities, with the help of the remaining words and sentences in the requirements combined with the current domain characteristics, and in combination with the definitions of the condition table and the event table, classify the conditional and event-based requirements. When "being in" appears in the main body of a certain requirement, it can be regarded as a conditional requirement; when "switching", "converting", or "changing to" appears, it can be regarded as an event-based requirement; when "when changing from... to..." appears, it can be regarded as an event-based requirement; when the conversion rules of the mode appear in the requirement, it can be regarded as a mode conversion type requirement, and words such as "conversion" and "changing to" often appear. If it is difficult to judge a requirement, it can be combined with Figure 2 for judgment.

[0062] Step 004: Extract modules, variables, and mode sets to construct the domain concept library.

[0063] Based on the domain entities extracted in step 003, construct the domain concept library, which includes terms, data types, input variables, intermediate variables, output variables, constants, and mode sets.

[0064] The specific steps of step 004 are as follows:

[0065] Each domain concept needs to be named. If it is extracted as an input variable, it generally starts with the prefix "ip", the intermediate variable starts with the prefix "t", the output variable uses the prefix "op", the mode set uses the prefix "mc", and the mode uses the prefix "m". After the prefix, it is concatenated according to the upper camel case naming method with an English phrase that can clearly represent the entity's meaning. It can also use the abbreviated form of the word, in which case it does not need to satisfy the upper camel case. The concatenated string is called the name identifier of the entity.

[0066] A term is an auxiliary function defined on an input variable, a mode, or other terms, which helps to simplify the specification.

[0067] Analyze the entities in the requirements of the domain. In the premise part and the main body part of the requirements, search for the entity elements that have been clearly defined in the requirements as belonging to external input, internal sole use, or external output. Since they have been clearly defined, they can be directly classified as input variables, intermediate variables, and output variables respectively. Among them, the premise part of the requirements is the explanatory text, which generally only contains variable names; the main body of the requirements is the main content of the requirements, which is a constraint on the premise of the requirements and generally contains the values and states of the variables.

[0068] After ignoring the above-classified entity information from the requirements, parse all the requirements again to find the entity information that is only involved in the premise part of the requirements but not in the main body part of the requirements. Obviously, for the entity information that appears in the premise, the system needs to obtain its value; but since it does not appear in the main body of any requirement, its value is not determined by the current system. Based on these two characteristics, this type of entity information is an input variable.

[0069] After ignoring the above domain entities from the requirements again, parse all the main bodies of the requirements. These main bodies of the requirements should all be extracted as intermediate variables or output variables. Since for both intermediate variables and output variables, the current system requirements may judge their values in the premise, it is impossible to distinguish between intermediate variables and output variables based on whether they appear in the premise part of a certain requirement. The difference between them is that only the output variables will be obtained by other external systems, while the intermediate variables will only be called within the system. Therefore, to distinguish between them, organize them and confirm with the engineers whether these entity information will be used as the output of the system. If so, classify it as an output variable; otherwise, classify it as an intermediate variable.

[0070] In the requirements, if there are very complex premises, and in subsequent modeling, they may correspond to very complex and difficult-to-understand conditions or events, some sub-items can be split from the premises, and a Boolean intermediate variable can be artificially defined to make it equivalent to the split sub-items.

[0071] The setting method of the data type is as follows: for all the extracted variables, find the positions where their corresponding entity information appears in the requirements, and based on the possible actions of these components or the possible values of the signal quantities, sort out their value ranges Range and set the corresponding data types.

[0072] Value ranges can mainly be divided into four different categories: integer value ranges, floating-point value ranges, enumeration value ranges, and boolean value ranges. Among them, the value ranges of the first two types are both numerical value ranges. Their characteristic is that when judging variable values, not only can the symbols = and ≠ be used for equality judgment, but also <, >, ≤, and ≥ can be used for size comparison. The number of possible values in the value range is generally large; while the latter two value ranges are both discrete value ranges. They are composed of several discrete values, can only perform equality judgment, and the number of possible values in the value range is small. The properties are shown in Table 1.

[0073] Table 1 Properties of the Four Types of Value Ranges

[0074]

[0075] The construction of the pattern set can be carried out according to the directed graph. According to the conversion relationship specified in the pattern conversion type requirements, draw a directed graph representing this conversion relationship between patterns. Each pattern is a node of the directed graph, and each conversion relationship specified in the requirements is an edge between the corresponding nodes in the directed graph. It is necessary to record which original requirement each edge comes from to facilitate the subsequent filling operation of pattern conversion. For each connected component in the directed graph, establish a pattern set and name it.

[0076] Step 005: Fill the two-dimensional table according to the requirement content.

[0077] After completing the construction of the domain concept library, it is necessary to fill the two-dimensional table according to the requirement content, including the condition table, event table, and pattern conversion table.

[0078] The specific steps of Step 005 are as follows:

[0079] With the help of the content of the established domain concept library, standardize each requirement and convert it into the requirement template format agreed with the computer program.

[0080] The standardized requirement is defined as: <originalID, mode, content>. originalID records which original requirement this standardized requirement comes from. mode indicates in which working mode of the system the response situation is defined by the requirement content. The content part is the main content of the standardized requirement, that is, the standardized requirement text obtained after standardizing the original requirement. Different standardization representation templates also constrain this part of the content.

[0081] For the requirement content, set the general condition / event template and the display condition / event template. Among them, the display condition / event template is used to standardize the condition / event type requirements that determine the display format of certain data or images of system components, while the condition / event type requirements for other functions can all use the general condition / event template for standardization.

[0082] Taking the general condition / event template as an example, the format of the general condition template is: When the following conditions are met, <subject>Should be able to be set to <value> ： <condition>。The general event template format is: When the following events occur, <subject>Should be able to be set to <value> ： <event>. Among them, <subject>That is, the subject variable, which is the variable of the subject extracted from this requirement in the preprocessing process. <value>That is, the value is filled with the value corresponding to the feedback of the requirement subject in this original requirement within the value range of the subject variable. For <condition>, construct a condition based on the premise in the original requirement for judging the value of the variable corresponding to the entity information involved in the premise, and represent this condition in an AND-OR table and fill it in <condition>Part; For <event>, construct an event based on the values of the variables corresponding to the entity information in the premise in the pre-state and the current state respectively, and represent this event in the form of an event expression and fill it into <event>Part.

[0083] The pattern conversion table has been pre - constructed in the domain concept library stage, defined as <m_from, e, m_to>. In the pre - construction stage, each original pattern m_from and target pattern m_to in the pattern set have been filled. At this stage, filling the event table e can obtain the complete pattern conversion table.

[0084] Considering the privacy of real - world requirements, taking the water - level control system of a nuclear power plant as an example, the filling of two - dimensional tables is described. Table 2 is the condition table, Table 3 is the event table, and Table 4 is the pattern conversion table.

[0085] Condition table of variable SafetyInjection in Table 2

[0086]

[0087] Event table of variable Overridden in Table 3

[0088]

[0089] Pattern conversion table of pattern set PressureLevel in Table 4

[0090] Original Mode Event Target Mode Too Low @T(Water Press ≥ Low) Permitted Permitted @T(Water Press < Low) Too Low Permitted @T(Water Press ≥ Permit) High High @T(Water Press < Permit) Permitted

[0091] Step 006: Construct variable mapping according to the two - dimensional table.

[0092] After the two - dimensional table is constructed, it is necessary to construct the dependency relationship of the same variable in different tables to ensure that the model has complete requirement semantic information.

[0093] The specific steps of Step 006 are as follows:

[0094] According to the constraint semantics provided in the requirements, considering the constraint semantics provided in a single requirement, the value propagation relationship between these variables can be constructed in the form of a table; when considering the constraint semantics included in the requirement set related to a certain pattern set, the mapping relationship between the common entities included in different requirements in the requirement set also needs to be considered.

[0095] Variable mapping refers to the association relationship between the variables inside the two - dimensional table and the entity variables. The two - dimensional table includes the condition table, event table, and pattern conversion table. The entity variables include input variables, intermediate variables, output variables, and pattern sets. The VRM model uses the two - dimensional table as a medium. For the time being, the mapping relationship between variables can be divided into two types: the mapping from the intermediate variable to the input variable (type - one mapping), and the mapping from the intermediate variable to the intermediate variable (type - two mapping). Taking type - one mapping as an example for illustration:

[0096] Type - one mapping consists of a quadruple <T mc , T c / e , Ts, Is>, the result of a type of mapping consists of a set of binary tuples, f mc = <Ts, Is>. Among them, T mc represents the set of intermediate variables extracted from the pattern conversion table considering the pattern conversion mapping, T mc = {tv1, tv2, tv3,..., tv n}. T c / e represents the set of condition tables or event tables c / e associated with each intermediate variable in the set T mc , T c / e consists of the set of binary tuples <tv, c / e>, T c / e = {<tv1, c / e1>, <tv2, c / e2>, <tv3, c / e3>,..., <tv n , c / e n >}, tv ∈ T mc . Ts consists of the set of binary tuples <tv, ivs>, where tv represents the intermediate variable and ivs represents the set of input variables associated with it, ivs = {iv1, iv2, iv3,..., iv n}, Ts = {<tv1, ivs1>, <tv2, ivs2>, <tv3, ivs3>,..., <tv n , ivs n >}, tv ∈ T mc . Is consists of the set of binary tuples <iv, tvs>, where iv represents the input variable and tvs represents the set of intermediate variables associated with it, tvs = {tv1, tv2, tv3,..., tv n}, tv ∈ T mc , Is = {<iv1, tvs1>, <iv2, tvtvs2>, <iv3, tvs3>,..., <iv n , tvs n >}, tvs n ∈ T mc .

[0097] A type of mapping associated with the pattern set mc1 Then the mapping represents the semantics as:

[0098]

[0099] Specifically, if a working pattern set mc can be found in the system, then there exists a type of mapping <T mc , T c / e , Ts, Is>, the relationship between the intermediate variables associated with each mode in the current working mode set mc in the mode conversion mapping and the internal input variables of the two-dimensional table on which the VRM model depends can be found, and the results are written into the Ts and Is sets.

[0100] Step 007: Generation of the HVRM model.

[0101] Step 007 is to establish an HVRM automatic construction algorithm to automatically generate the HVPM model. Subsequently, the generated HVRM model can be analyzed, verified, and test cases can be generated to ensure the correctness of the original requirements. Specifically as follows:

[0102] Through the semantic conversion between the domain concept library and the specification requirements constructed previously and the HVRM model, the elements required by the HVRM model are filled in one by one. The simplified HVRM model structure of the automatic flight control system is as Figure 3 shown.

[0103] V represents the variable dictionary, which explains the variables owned by the automatic flight control system. MODULE represents the module, which explains the hierarchical relationship of the automatic flight control system. F includes three table functions, namely the condition table, the event table, and the mode conversion table. MAPPING includes the mapping between two variables in the HVRM model. In the figure, m, c, a and m, e, a are both equivalent to triples representing table functions, where m represents the mode set where the variable related to the table function is located, c or e represents the condition table or event table where the variable related to the table function is located, and a represents the value of a certain variable after passing through the table function.

[0104] In another embodiment, the present invention proposes a computer-readable storage medium storing a computer program, and the computer program causes a computer to execute the modeling method for a formal requirement model with hierarchical characteristics in the foregoing embodiment.

[0105] In another embodiment, the present invention proposes an electronic device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the modeling method for a formal requirement model with hierarchical characteristics in the foregoing embodiment.

[0106] In the embodiments disclosed in the present application, a computer storage medium may be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. The computer storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of the computer storage medium would include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0107] Those of ordinary skill in the art will appreciate that the units and algorithm steps of the examples described in connection with the embodiments disclosed in the present application can be implemented in electronic hardware or in a combination of computer software and electronic hardware. Whether these functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present application.

[0108] The above are only the preferred embodiments of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions falling within the concept of the present invention belong to the protection scope of the present invention. It should be noted that for those of ordinary skill in the art, several improvements and refinements made without departing from the principle of the present invention should be regarded as within the protection scope of the present invention.< / event> < / event> < / condition> < / condition> < / value> < / subject> < / event> < / value> < / subject> < / condition> < / value> < / subject>

Claims

1. A modeling method for a formalized requirement model with hierarchical characteristics for an automatic flight control system, characterized in that: The steps include: Step 1: Clarify the requirements described in natural language and eliminate ambiguous information in the requirements; Step 2: Determine the interaction between different requirements and divide the hierarchical relationship of requirements; Step 3: Split the requirements and extract domain entities. After removing the domain entities, use the remaining words and sentences in the requirements and combine them with the current domain characteristics to classify the requirements into conditional requirements, event requirements, and mode conversion requirements. Step 4: Build a domain concept library based on the domain entities extracted in step 3; Step 5: According to the domain concept library and the demand content, fill each demand in a two-dimensional table according to the set demand template format and convert it into a standard demand. The two-dimensional table includes a condition table, an event table and a mode conversion table, which correspond to conditional demands, event demands and mode conversion demands respectively; Step 6: For the constructed two-dimensional tables, establish the dependency relationship of the same variable in different tables; Step 7: Based on the constructed domain concept library and specification requirements, convert the semantics between the HVRM model, fill in the elements required by the HVRM model one by one, and generate the HVRM model.

2. The modeling method for a formalized demand model with hierarchical characteristics according to claim 1, characterized in that: The step 1 includes: analyzing the source of requirements, analyzing the context of requirements, refining requirements, defining terms used in requirements, and confirming understanding of requirements.

3. The modeling method for a formalized demand model with hierarchical characteristics according to claim 1, characterized in that: The step 2 includes: dividing the FGCS into AP, FD and mode conversion from the top level according to the demand content; the AP is responsible for the on and off of the autopilot; the FD is responsible for the on and off of the flight guidance; the mode conversion is responsible for the three-axis attitude control of the aircraft, which is abstracted into three independent mode sets of lateral mode, longitudinal mode and multi-axis mode according to the hierarchical relationship; The pattern set is defined as<key,M,SM,m_parent> , which respectively represent the name of the pattern set, the patterns contained in the pattern set, the transition events between different patterns in the pattern set, and the parent pattern of the pattern set; the pattern is defined as<key,isStart,isEnd> , which respectively indicate the name of the mode, whether it is the initial mode, and whether it is the final mode.

4. The modeling method for a formalized demand model with hierarchical characteristics according to claim 1, characterized in that: In step 3, when the demand subject is feedback to the premise, if it focuses on maintenance, it is identified as a conditional demand, and if it focuses on change, it is identified as an event-type demand; when a pattern conversion rule appears in the demand, it is identified as a pattern conversion demand.

5. The modeling method for a formalized demand model with hierarchical characteristics according to claim 1, characterized in that: In step 4, the domain concept library includes terms, data types, input variables, intermediate variables, output variables, constants and pattern sets; The input variables, intermediate variables and output variables are the entity elements in the requirements that are input from the outside, used alone inside and output to the outside respectively; The data type is set as follows: for the extracted variables, find the location where the corresponding entity information appears in the requirements, sort out the value range and set the corresponding data type according to the possible actions or semaphore values; The value range is divided into an integer value range, a floating point value range, an enumeration value range and a Boolean value range; The pattern set is constructed according to a directed graph, each pattern is a node of the directed graph, and each model conversion relationship specified in the requirements is an edge between corresponding nodes in the directed graph.

6. The modeling method for a formalized demand model with hierarchical characteristics according to claim 1, characterized in that: In step 5, the set requirement template format includes a general condition / event template and a display condition / event template. The display condition / event template is used to standardize the condition / event type requirements that determine the display format of certain data or images of system components, while other condition / event type requirements use the general condition / event template for standardization. The specification requirement is defined as<originalID,mode,content> , originalID records which original requirement the standard requirement comes from, mode indicates that the requirement content defines the response of the system under which working mode, and content is the main content of the standard requirement.

7. The modeling method for a formalized demand model with hierarchical characteristics according to claim 5, characterized in that: In step 6, the dependency relationship includes a first-class mapping from intermediate variables to input variables and a second-class mapping from intermediate variables to intermediate variables.

8. The modeling method for a formalized demand model with hierarchical characteristics according to claim 7, characterized in that: In step 7, the HVRM model includes V, MODULE, F and MAPPING; V represents a variable dictionary, indicating the variables owned by the automatic flight control system; MODULE represents a module, indicating the hierarchical relationship of the automatic flight control system; F includes a condition table, an event table and a mode conversion table; MAPPING includes a first-class mapping and a second-class mapping.

9. A computer-readable storage medium storing a computer program, characterized in that: The computer program enables the computer to execute the modeling method for the formalized demand model with hierarchical characteristics as described in any one of claims 1 to 8.

10. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the modeling method for a formalized requirement model with hierarchical characteristics as described in any one of claims 1 to 8 is implemented.

Images