An index verification method supporting model attribute quantitative evaluation

Abstract

The application discloses a kind of index verification methods of supporting model attribute quantification evaluation in the field of system engineering technology, comprising the following steps: using model-based system engineering method, construct the system engineering model of problem solving;According to the requirement and constraint of model, the verification script of the constraint condition not changing with time in system model is contained by using KARMA language index verification part syntax definition;Index verification compiler compiles KARMA language index verification text, calls solver based on satisfiability module theory;The method is developed based on GOPPRR modeling theory, can support the establishment of multi-architecture model, not limited to the model of a certain field, the expression of model relationship, constraint condition and verification object is realized by using the mode of combining satisfiability module theory and GOPPRR modeling theory, the unified modeling language is extended by using satisfiability module theory, supports the interaction of modeling data and solving data, and reduces the learning cost of engineering personnel.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system engineering, and in particular to an index verification method supporting model attribute quantitative evaluation. BACKGROUND

[0002] With the continuous development of complex systems, the systems show the characteristics of increasing complexity, increasing scale and increasing uncertainty. These characteristics bring a series of challenges to the development of complex systems, such as developing low fault tolerance but high reliability, developing large amount of calculation but low efficiency, designing large uncertainty, requiring collaborative development, modular development, etc. Model-based system engineering (MBSE) supports formalization, modeling, design, analysis and verification in the whole life cycle of system development through models, and provides a solution to the development challenges of complex systems.

[0003] A method for verifying, optimizing and evaluating a top-level system design scheme based on MBSE is disclosed in Chinese patent application publication No. CN110321580A. The method takes an aircraft as a representative to design and analyze the top-level system. The method is based on the theory of model-based system engineering, and uses SysML modeling language to construct requirement model, function model and structure model in a graphical manner. The patent verifies whether there is a conflict between requirements in the requirement model according to the relationship between requirements, verifies whether the functions in the function model can meet the requirements according to the use case diagram, and verifies whether the system structure in the structure model can support the implementation of system functions according to the block definition diagram and activity diagram. Finally, the conversion of the top-level system activity diagram or state diagram to the Petri net model is realized according to the mapping rules of modeling elements, and it is verified whether there is a resource conflict or lock in the Petri net model, so as to evaluate whether the design scheme meets the top-level requirements.

[0004] Through the analysis of the above method, it is found that the existing problems to be solved in the current technology are:

[0005] (1) Single modeling language supported by part of the tools is not conducive to complexity management: the conversion of the MBSE model to the Petri net model in the above patent method is for SysML modeling language. SysML is an object-oriented software modeling language, which is excellent in expression ability and coverage. However, for field staff, other modeling languages such as domain-specific modeling language are more widely used in field problems. With the improvement of product complexity, a single domain-specific modeling language is difficult to complete the unified description of complex systems. It is difficult to construct conversion rules for any modeling language to be used. Therefore, it is necessary to explore a language that can support the verification and evaluation of multiple architectures, and improve the universality of the verification method.

[0006] (2) verification methods are artificial verification, and lack quantitative evaluation means: all verification methods of the above method are artificial judgment by model, and the relationship of the model cannot be quantitatively evaluated, and the efficiency is low. The reason for this problem is that the modeling language commonly used for MBSE description model at present (such as UML, SysML) is a semi-formal language, which cannot verify the system. Their syntax structure is completely formalized, but the semantic part uses natural language, and the natural language is non-formalized, which is not accurate enough for the description of the model, so the properties of the model cannot be formally expressed. Formal description is the key to guarantee the feasibility, accuracy and reliability of verification, and the semi-formal modeling language cannot quantitatively analyze the properties of the model. Since the system index is often embodied as the properties of the model and the relationship between them, the unquantifiable property relationship leads to the inability to verify or optimize the system index.

[0007] (3) The integration of the method is complex in technology and language, the learning cost is high, it is not conducive to use, and the communication between modeling and solving data is difficult: the above method integrates SysML modeling language and Petri net method, which is abstract for engineering personnel and not easy to learn and use. At the same time, it is difficult to learn SysML modeling language and Petri net solving method. And the data between Petri net and SysML model cannot be interacted, and there is difficulty in reusing data.

[0008] Therefore, it is urgent to design an index verification method supporting quantitative evaluation of model properties. SUMMARY

[0009] The purpose of the present application is to provide an index verification method supporting quantitative evaluation of model properties to solve the problems in the background art.

[0010] To achieve the above purpose, the present application provides the following technical scheme: an index verification method supporting quantitative evaluation of model properties, comprising the following steps:

[0011] S1: using a model-based system engineering method to build a system engineering model for solving problems;

[0012] S2: according to the requirements and constraints of the model, using KARMA language index verification part syntax definition to contain the verification script of the constraint conditions in the system model which do not change with time;

[0013] S3: the index verification compiler compiles the KARMA language index verification text, and calls the solver based on satisfiability module theory.

[0014] Further, in the above index verification method supporting quantitative evaluation of model properties, the specific method of S1 is:

[0015] When the evaluation of constraints needs to be used to verify the advancement, improve the design efficiency or reduce the uncertainty of the scheme in the problem, the index verification method can be used; first, the unified multi-architecture modeling language KARMA language is used for the problem, combined with the specification of the domain modeling language, in the MetaGraph tool, according to the modeling process of "requirement architecture-function architecture-logic architecture-physical architecture" commonly used in the model-based system engineering method, the system architecture model of the domain is constructed; the multi-architecture unified modeling tool MetaGraph supports the unified multi-architecture modeling language KARMA to express the model-based system engineering model, realizes the model library development and modeling of different general modeling languages and frameworks; the KARMA language can support the GOPPRR modeling method to describe the multi-architecture model from different perspectives, and complete the description of the whole development process of the complex system; the GOPPRR modeling method is high in abstraction level and is not limited to a certain field, and can support model description of multiple architectures; the GOPPRR modeling method constructs the meta-model in the domain through six basic meta-models, which are used as the domain modeling language and the corresponding model library; the instantiation of the meta-model constructs the model in the domain, and the system in the real world is analyzed from multiple perspectives through the combination of the model; the model-based system engineering method can use the "requirement architecture-function architecture-logic architecture-physical architecture" modeling process for modeling; the requirement architecture obtains the corresponding requirements according to the stakeholders of the system, the function architecture describes the capabilities and services provided by the system and the tasks to be performed by the system, the logic component is an abstract representation of the physical component, the logic architecture executes the functions of the system without imposing constraints on the technical implementation, and the physical architecture defines the relationship and parameters of the physical devices and their interfaces, and its purpose is to describe a specific and implementable solution.

[0016] Further, in the index verification method supporting model attribute quantitative evaluation described above, the specific method of S2 is:

[0017] a: define the index verification module and the verification solver used by using the KARMA index verification syntax;

[0018] b: define the required variables in the constraint and perform assignment;

[0019] c: construct the constraint based on the model information and add the constraint to the solver;

[0020] d: add soft constraints and optimization objectives in the optimization solver;

[0021] e: evaluate the constraint and obtain the solution that satisfies the constraint.

[0022] Further, in the index verification method supporting model attribute quantitative evaluation described above, the specific steps of a are:

[0023] The key words "SMTAnalysis" and "end" in the syntax are used to declare the indicator verification module; the beginning is "SMTAnalysis Name" and the end is "endName", and the code body is inserted in between;

[0024] The bold italicized characters are fixed-format keywords, followed by a string indicating the module name, and the module ends with the "end" keyword, indicating the end of the module; the code body for indicator verification is written in the module;

[0025] According to the type of the problem to be solved, the code body first declares the type of solver required for the indicator verification: a general solver or an optimization solver; the general solver is only used to check the constraints, i.e., whether the added constraints are conflict-free, and returns the result as "satisfy" the added constraints, returns a Boolean type constraint, and a set of solutions that satisfy the constraints, the optimization solver can also add "max" and "min" objective functions and constraint expressions with weights, and the result is a set of solutions that best meet the objective function; the syntax for calling the general solver is declared by the keyword "Solve", and the specific definition method starts with "Solve solverName" and ends with "end solverName", and the rest of the main body code is added in between;

[0026] The keyword "Solve" is followed by a string, which is the name of the general solver; the end of the solver is followed by the keyword "end", and the same string is followed; the solver declaration can write model information, constraint definition, and solving operation code; if an optimization solver is called, the optimization solver is declared by the keyword "Optimize", and the specific definition method starts with "OptimizeoptName" and ends with "end optName", and the rest of the main body code is added in between;

[0027] The keyword "Optimize" is followed by a string, which is the name of the optimization solver; the end of the solver is followed by the keyword "end", and the same string is followed; the solver declaration can write model information, constraint definition, solving operation, and optimization operation code; among them, the optimization solver is used as the applied solver.

[0028] Further, in the above-mentioned indicator verification method supporting quantitative evaluation of model attributes, the specific steps of b are:

[0029] In order to verify whether the model meets the expected requirements, it is necessary to build constraints on model information and indicators and judge the satisfaction of the constraints. First, it is necessary to define the variables in the constraints. The code for defining the constraint variables is located in the solver. The constraint variables support assignment, which can come from custom values ​​or from the model. The data type of the variable supports integer, real number array, matrix, and Boolean types, which are defined by their respective keywords. The specific data type declaration method is: "DataType的序数变量。 English: variableName; "variableName;" that is, the data type is followed by a variable name; the keyword "Int" declares integer data, followed by a string representing the integer variable name; the keyword "Real" declares real number data, followed by a string representing the real number variable name; the keyword "Boolean" declares Boolean data, followed by a string representing the Boolean variable name; the keyword "Array" declares the array type, followed by a string representing the name of the array variable. To declare an array type, you also need to declare the array index type and value type; in the above code example, the keyword "array" and the data type name "int" in parentheses indicate that the index type and value type are integers; the keyword "Matrix" declares matrix data, followed by a string representing the name of the matrix variable. In the above code example, the keyword "IntegerMatrix" indicates that the data in the defined matrix is ​​integer data and the matrix is ​​an integer matrix, and the keyword "initial" is used to initialize the matrix variable. Two integers are written in parentheses after "initial" to define the rows and columns of the matrix respectively.

[0030] If you need to assign a value to a variable, there are generally two situations; one method is to directly assign a custom value to the variable, and its syntax is "DataType variableName=value;"

[0031] DataType refers to a data type, variableName refers to the variable name, and value refers to the value. Another case is to extract information from the model and assign a value to the variable, thereby associating the model and verification information. The syntax is "DataType variableName = LanguageName.ModelName.ObjectName.Property[PropertyName]";

[0032] Among them, LanguageName indicates the name of the modeling language used, ModelName indicates the name of the model corresponding to the extracted attribute, ObjectName indicates the name of the model object or other model element corresponding to the extracted attribute, the keyword "Property" indicates the extracted attribute, and PropertyName in the brackets indicates the attribute name;

[0033] If the quality distribution of each component in the above case is required to be solved, first declare an index verification module, then define an optimization solver, then define the corresponding variables, and extract the quality attributes of the overall complex equipment, the quality attributes of components A, B, C, D, and E, and the target values of each component, such as maximum and minimum values, and assign corresponding values.

[0034] Further, in the index verification method supporting the quantitative evaluation of the model attributes, the specific steps of c are as follows:

[0035] After the declaration and assignment of variables are completed, the variables based on model information need to be quantified to form constraints related to the model and requirements; the construction of constraints follows the satisfiability module theory, and general constraints can be formally expressed as:

[0036] C Bool =⊙(Property,Size(otherType),R)

[0037] CBool is an expression of comprehensive model attributes, the number of model elements other than attributes, real numbers, and various operators; among them, Bool represents that the return type of the expression is a Boolean expression, and the expression of the constraint must be a Boolean return expression; the symbol is defined as a mathematical symbol set in the satisfiability module theory, including arithmetic operators, Boolean operators, array operators, and comparison operators; Size() represents the number of remaining model elements, otherType refers to model elements other than attributes, and R refers to real numbers; different data types support different operations, but the final return expression type is Boolean;

[0038] Arithmetic type data supports four arithmetic operations, maximum and minimum value operations, absolute value operations, power and exponential operations, and equality or inequality comparison operations; Boolean type data supports Boolean AND, OR, and NOT operations, equality or inequality operations, XOR, XNOR, and implication operations; array type data supports array write and read operations, and equality or inequality operations; matrix type data

[0039] supports matrix addition, subtraction, multiplication, inversion, rank, sum, and transpose operations, matrix value extraction, and equality and inequality operations;

[0040] After the creation of the constraint is completed, the constraint needs to be added to the solver to enable the constraint to be evaluated; the constraint is added by declaring a general solver with the keyword "add" or an optimization solver with the keyword "Add"; according to the case, the equality constraint between the components and the overall is added, the constraint that the overall quality is not greater than 360 kg is added, and the quality constraints between each component are added.

[0041] Furthermore, in the indicator verification method supporting quantitative evaluation of model attributes, the specific steps of d are as follows:

[0042] If an optimization solver is used, soft constraints and optimization objectives can also be added. Soft constraints are optional within the optimization solver and are not required for all optimization solvers. Soft constraints are defined using the "AddSoft" keyword. Within the parentheses enclosed by the keyword, a constraint expression that returns a Boolean value and an arithmetic value, typically an integer, must be added. Unlike ordinary constraints, soft constraints do not necessarily need to be satisfied. The integer defined by the soft constraint represents the weight of the constraint. Solving soft constraints requires calculating which soft constraints need to be satisfied first based on the weight.

[0043] Optimization objectives are commonly found in optimization solvers. Optimization objectives are declared using the keywords "Max" or "Min" to express a maximization expression or a minimization expression. The expression being optimized can only be an expression that returns an arithmetic type.

[0044] In the above case, we need to minimize the working time of worker 1 and the production balance delay time, and add the keyword "Min" to guide the minimization objective.

[0045] Furthermore, in the indicator verification method supporting quantitative evaluation of model attributes, the specific steps of the above e are:

[0046] After completing the definition of constraints or after completing the definition of constraints and optimization objectives, you need to operate the solver through the keyword "check" general solver or "Check" optimization solver, requiring the solver to solve whether there is any conflict in the constraints; the result may be "SAT constraint is satisfied", "UNSAT constraint is not satisfied" or "UNKNOWN result is unknown"; if the result is "SAT constraint is satisfied", you can obtain a solution that satisfies the constraints through the keyword "solution" general solver or "Solution" optimization solver; if a general solver is used, a set of random solutions that meet the constraints are obtained, and if an optimization solver is used, a set of solutions that are closest to the optimization objective and meet all constraints are obtained.

[0047] Furthermore, in the above-mentioned indicator verification method that supports quantitative evaluation of model attributes, the specific method of the above-mentioned S3 is: the indicator verification engine processes the input verification script, the built-in syntax analyzer performs lexical analysis and syntax analysis on the verification script, traverses the abstract syntax tree of the language, executes each statement separately, and obtains information about the model elements; according to the indicator verification script, calls the solver based on the satisfiability module theory, executes the language in the script, adds corresponding constraints, and solves the added constraints.

[0048] Compared with the prior art, the present application has the beneficial effects that:

[0049] 1、 The present application is developed on the basis of GOPPRR modeling theory, and can support the establishment of multi-architecture models without being limited to models in a certain field.

[0050] 2、 The present application realizes the expression of model relations, constraint conditions and verification objects in a manner combining satisfiability modulo theory and GOPPRR modeling theory; KARMA language describes meta-models, model instances and the relations therebetween according to the six underlying elements of GOPPRR in a meta-modeling method, supports the formal expression of the described model relations; satisfiability modulo theory supports defining model elements as first-order logic expressions, expands the description scenarios of the language, and supports the definition of most model relations, constraints and verification objects; therefore, the formal basis of the technical solution is quantized model elements, which provides a good foundation for index verification.

[0051] 3、 The present application extends the unified modeling language by using satisfiability modulo theory, supports the interaction of modeling data and solving data, and reduces the learning cost of engineers; the object of KARMA index verification language is the model described by the GOPPRR method, and the syntax and semantics thereof are deeply integrated with the syntax and semantics of the formal description of KARMA models; that is, the consistency of the language is ensured, multiple languages do not need to be learned, the learning cost is reduced, and the same language supports the interoperability between the modeling environment and the index verification engine in the development process. BRIEF DESCRIPTION OF DRAWINGS

[0052] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the following embodiment descriptions will be briefly introduced. Obviously, the drawings in the following descriptions are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0053] Figure 1 The method flowchart of the present application is shown in Figure 1.

[0054] Figure 2 The GOPPRR modeling method schematic diagram of the present application is shown in Figure 2.

[0055] Figure 3 The KARMA index verification part abstract syntax schematic diagram of the present application is shown in Figure 3.

[0056] Figure 4 The index verification flowchart of the present application is shown in Figure 4.

[0057] Figure 5 The result display diagram after index verification of the present application is shown in Figure 5. DETAILED DESCRIPTION

[0058] With reference to the drawings of the embodiments of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of the present application.

[0059] The present application provides a technical solution: an index verification method supporting model attribute quantitative evaluation, comprising the following steps:

[0060] S1: using a model-based system engineering method, a system engineering model for solving a problem is constructed;

[0061] When the problem needs to use constraint evaluation to verify the advancement, improve the design efficiency or reduce the uncertainty of the scheme, the index verification method can be used. First, for the problem, a unified multi-architecture modeling language KARMA language is used, combined with the specification of the domain modeling language, in the MetaGraph tool, according to the modeling process of "requirement architecture-function architecture-logic architecture-physical architecture" commonly used in the model-based system engineering method, the system architecture model of the domain is constructed. The multi-architecture unified modeling tool MetaGraph supports the unified multi-architecture modeling language KARMA to express the model-based system engineering model, realizes the model library development and modeling of different general modeling languages and frameworks; the KARMA language can support the GOPPRR modeling method to describe multi-architecture models from different perspectives, complete the description of the whole development process of the complex system; the GOPPRR modeling method has high abstraction level and is not limited to a certain field, which can support model description of multiple architectures; the GOPPRR modeling method constructs the meta-model under the domain through six basic meta-models, as the domain modeling language and the corresponding model library; the instantiation meta-model constructs the domain model, and analyzes the system in the real world from multiple perspectives through the combination of models; the model-based system engineering method can use the "requirement architecture-function architecture-logic architecture-physical architecture" modeling process for modeling; the requirement architecture obtains the corresponding requirements according to the stakeholders of the system, the function architecture describes the capabilities and services provided by the system and the tasks to be executed by the system, the logic component is an abstract representation of the physical component, the logic architecture executes the functions of the system without imposing constraints on the technical implementation, and the physical architecture defines the relationship and parameters of the physical devices and their interfaces, and its purpose is to describe the specific and implementable solution.

[0062] Suppose that in the design process of a complex equipment, a mass distribution problem is encountered. The complex assembly mass involves the design, manufacture, use and installation of the equipment, and requires to meet the characteristics of lightweight, high energy and good balance. It is assumed that the complex equipment has 5 components (A, B, C, D, E), and the weight requirement of the components is not more than 360 kg. According to the past design experience, the mass of component A should not be less than 50 kg and not more than 68 kg. Component B is a power component, and its mass and power are positively correlated. According to the calculation, the mass of component B should not be less than 80 kg. The masses of components C and D are the same, and each is not less than 20 kg. It is required that the difference between the sum of the masses of components E, C and D is the smallest to ensure balance. Finally, the component with the largest mass should not exceed 100 kg.

[0063] For this problem, we model according to the modeling sequence of "requirement - function - logic - physics". First, the requirement model is constructed, which includes the definition of stakeholders such as the designers of the complex equipment and the operators using the complex equipment, and the definition of the requirement diagram, including the top-level requirements such as lightweight, high energy, and the detailed requirements of the overall complex equipment such as total mass and total mass as small as possible. The information of the design problem such as the requirement name and the value of the constraint (360 kg) is stored in the requirement model. Then the function model is defined, which is an abstraction of the requirement. In this problem, the function modules of all components are structure functions. In the function model, the five components are expressed through the graphical modules, and the containment constraint relationship between the overall and the components is defined. There is no logical model of information transmission in this problem. Finally, the specific properties of the components are defined to construct the physical model. The specific properties here only involve the mass of the component representing the physical module, and the constraints of the requirement model are decomposed. The corresponding requirements are defined for each physical module to form the constraints. Among them, the mass of each component is an undefined variable, which needs to be determined through the index verification method.

[0064] S2: According to the requirements and constraints of the model, use KARMA language index verification part to define the verification script containing the constraint conditions in the system model that do not change with time;

[0065] The index verification is usually achieved by evaluating whether a plurality of index-related constraints can be satisfied. For example, to evaluate whether the current cost of a system meets an expected cost index, a constraint relationship between the expected cost and the cost of each component of the current system needs to be constructed; to evaluate whether a certain circuit system has the effectiveness of outputting a high level, a constraint relationship among the input, electronic components and output of the circuit needs to be constructed and compared with the expected output. The information of the index and the related constraints in the index verification comes from the model, so after the engineers complete the modeling, they first extract the relevant attributes of the model through the KARMA language index verification syntax, formally describe the model information, and according to the content to be verified and the model information, construct the corresponding constraints, and define the verification script containing the static constraint relationship (not changing with time).

[0066] The verification script is used to judge whether the existing system can meet the design index, mainly including the formalized part of the existing system, the index constraint to be verified and other parts, and is mainly applied to the inspection of static constraints. The static constraint refers to the constraint relationship that does not change with time, because the verification script is based on the formal verification method, which has low operation cost and wide solution range. The formalized part of the system is used to extract the model information and associate the verification and the model. The index constraint to be verified is the related constraint constructed according to the verification target, and the constraint is returned as a Boolean type. Generally, the constraint includes all operations of the Boolean expression, and the Boolean expression connected by the connection operator (full equal, not equal, greater than, less than, etc.) of other types (arithmetic, array, matrix, string) expression. The other part is mainly used to define the type of the solver and the variables or constants of the non-model elements that need to be used. At present, general solvers and optimization solvers are supported.

[0067] The KARMA language index verification script is constructed based on the KARMA language index verification syntax. The KARMA index verification syntax is based on the GOPPRR modeling theory, combined with the satisfiability module theory, and extends the original syntax and semantics of the KARMA language, so that the extended KARMA language can formally describe the model attributes and the constraints between the attributes, and automatically solve the constraint relationship, so as to achieve the purpose of inspecting the system index and reasonably configuring the design options according to the optimization target. The satisfiability module theory is a kind of logic theory, which contains a series of axioms, and can check whether a logical formula containing one or more mathematical theories is satisfiable. It combines Boolean satisfiability and the basic mathematical field of computer science, modularly combines different algorithms in the mathematical field, and has a corresponding solver. Therefore, using the satisfiability module theory as the basis of the extended modeling language syntax can ensure the reliability of the description of the logical relationship of the model and the uniformity of the logical constraint and the solving method. The abstract syntax of the KARMA language index verification is shown as Figure 3 The interpretation and specific syntax are shown in Table 1.

[0068] a: The syntax definition index verification module and the verification solver used are verified by using the KARMA index;

[0069] The specific steps are as follows: the keywords "SMTAnalysis" and "end" in the syntax are used to declare the index verification module; the beginning is "SMTAnalysis Name" and the end is "endName", and the code body is inserted in between;

[0070] Among them, the bold italic is the fixed format keyword, followed by the string indicating the module name, and the end of the module is ended with the "end" keyword, indicating the end of the module; the code body of the index verification is written in the module;

[0071] According to the type of the problem to be solved, the code body first declares the type of the solver required by the index verification: general solver or optimization solver; the general solver is only used to check the constraints, that is, whether the added constraints conflict, and returns the result of "satisfying" the added constraints, and a set of solutions that satisfy the constraints, the optimization solver can also add "max" and "min" objective functions and constraint expressions with weights, and the result is "satisfying" or "satisfiable", and the result is the solution set that best meets the objective function; the syntax for calling the general solver is declared by the keyword "Solve", and the specific definition method starts with "Solve solverName" and ends with "end solverName", and the rest of the main body code is added in between;

[0072] The keyword "Solve" is followed by a string, which is the name of the general solver; the end of the solver is ended with the keyword "end", and the same string is followed; the model information, constraint definition, and solving operation code can be written in the solver declaration; if the optimization solver is called, the optimization solver is declared by the keyword "Optimize", and the specific definition method starts with "OptimizeoptName" and ends with "end optName", and the rest of the main body code is added in between;

[0073] The keyword "Optimize" is followed by a string, which is the name of the optimization solver; the end of the solver is ended with the keyword "end", and the same string is followed; the model information, constraint definition, solving operation, and optimization operation code can be written in the solver declaration; among them, the optimization solver is used as the applied solver.

[0074] b: Define the variables required in the constraints according to the model and assign values;

[0075] The specific steps are: in order to verify whether the model meets the expected requirements, the constraints of the model information and indicators need to be constructed, and the satisfaction of the constraints is judged; first, the variables in the constraints need to be defined, and the codes for defining the constraint variables are located in the solver; the variables of the constraints support assignment, and the assignment can come from a custom value or from the model; the data type of the variable supports integer, real, array, matrix and Boolean, which are defined by respective keywords; the specific declaration method of the data type is: "DataType variableName;" that is, a data type followed by a variable name; the keyword "Int" declares an integer data, followed by a string indicating the integer variable name; the keyword "Real" declares a real data, followed by a string indicating the real variable name; the keyword "Boolean" declares a Boolean data, followed by a string indicating the Boolean variable name; the keyword "Array" declares an array type, followed by a string indicating the name of the array type variable; the array type also needs to declare the index type and the value type; in the above code example, the index type and the value type are integer by the keyword "array" and the data type name "int" in the parentheses; the keyword "Matrix" declares a matrix type data, followed by a string indicating the name of the matrix type variable; in the above code example, the keyword "IntegerMatrix" indicates that the data in the defined matrix is integer data, and the matrix is an integer matrix; the matrix variable is initialized by the keyword "initial", and two integers are written in the parentheses after "initial" to define the rows and columns of the matrix;

[0076] If the variable needs to be assigned a value, there are generally two cases; one method is to directly assign a custom value to the variable, and the syntax is "DataType variableName=value;"

[0077] DataType refers to a data type, variableName refers to a variable name, and value refers to an index value; the other case is to extract information from the model to assign a value to the variable, thereby associating the model and the verification information with each other, and the syntax is "DataType variableName=LanguageName.ModelName.ObjectName.Property[PropertyName]";

[0078] Wherein, LanguageName represents the name of the modeling language used, ModelName represents the model name corresponding to the extracted attribute, ObjectName represents the model object or other model element name corresponding to the extracted attribute, the keyword "Property" represents the extracted attribute, and PropertyName in the square brackets represents the attribute name;

[0079] If the mass distribution of each component in the above case is required to be solved, first, a index verification module is declared, then an optimization solver is defined, then corresponding variables are defined, and the mass attributes of the complex equipment as a whole, the mass attributes of components A, B, C, D, and E, and the target values of each component such as maximum and minimum values are extracted from the model and assigned with corresponding values.

[0080] c: build constraints based on model information and add the constraints to the solver;

[0081] The specific steps are: after the declaration and assignment of variables are completed, the variables based on model information need to be quantified to form constraints related to the model and requirements; the construction of constraints follows the satisfiability theory, and general constraints can be formally expressed as:

[0082] C Bool =⊙(Property,Size(otherType),R)

[0083] CBool is an expression of the integrated model attributes, the number of model elements other than attributes, real numbers, and various operators; wherein, Bool represents that the expression returns a Boolean expression, and the expression of the constraint must be a Boolean return expression; the symbol is defined as a mathematical symbol set in the satisfiability theory, including arithmetic operators, Boolean operators, array operators, and comparison operators; Size() represents the number of remaining model elements, otherType refers to model elements other than attributes, and R refers to real numbers; different data types support different operations, but the final returned expression type is Boolean;

[0084] Arithmetic type data supports four arithmetic operations, maximum and minimum value operations, absolute value operations, power and exponential operations, and equality or inequality comparison operations; Boolean type data supports Boolean AND, OR, and NOT operations, equality or inequality operations, XOR, XNOR, and implication operations; array type data supports array write and read operations, and equality or inequality operations; matrix type data supports matrix addition, subtraction, multiplication, inversion, rank, sum, and transpose operations, and matrix value extraction, equality, and inequality operations;

[0085] After the creation of constraints, the constraints need to be added to the solver to evaluate the constraints; the addition of constraints is declared by the keyword "add" for the general solver or "Add" for the optimization solver; according to the case, the equality constraint between the assembly and the whole is added, the constraint that the mass of the whole is not greater than 360 kg is added, and the mass constraint between each assembly is added.

[0086] d: Add soft constraints and optimization objectives in the optimization solver;

[0087] The specific steps are: if the optimization solver is used, soft constraints and optimization objectives can also be added; in the optimization solver, soft constraints are optional additions, not all optimization solvers need to add soft constraints; soft constraints are defined by the keyword "AddSoft"; the keyword leads to the addition of a constraint expression returning a Boolean type in the small parentheses, and a value of an arithmetic type, generally an integer; soft constraints are different from ordinary constraints, soft constraints do not necessarily have to be satisfied, and the integer defined by the soft constraint represents the weight of the constraint; the solution of the soft constraint needs to be calculated according to the size of the weight, which soft constraint needs to be satisfied first;

[0088] Optimization objectives commonly exist in optimization solvers; optimization objectives are declared by the keywords "Max" or "Min", which express the maximization expression or minimization expression; the expression to be optimized can only be an expression returning an arithmetic type;

[0089] In the above case, the working time of worker 1 and the production balance delay time need to be minimized, and the minimization objective is added by the keyword "Min".

[0090] e: Evaluate constraints and obtain solutions that satisfy constraints;

[0091] The specific steps are: after the definition of constraints or after the definition of constraints and optimization objectives, the solver needs to be operated by the keyword "check" for the general solver or "Check" for the optimization solver, which requires the solver to solve whether the constraints are conflict-free; the result can be "SAT constraints are satisfied", "UNSAT constraints are not satisfied" or "UNKNOWN result is unknown"; if the result is "SAT constraints are satisfied", the solution that satisfies the constraints can be obtained by the keyword "solution" for the general solver or "Solution" for the optimization solver; if the general solver is used, a set of random solutions that meet the constraints is obtained, and if the optimization solver is used, a set of solutions that are closest to the optimization objective and meet all constraints is obtained.

[0092] S3: Index verification compiler compiles the KARMA language index verification text and calls the solver based on the satisfiability module theory.

[0093] The index verification engine processes the input verification script, the built-in syntax analyzer performs lexical analysis and syntax analysis on the verification script, traverses the abstract syntax tree of the language, executes each statement respectively, and obtains the information of the model elements; according to the index verification script, the solver based on the satisfiability modulo theory is called, and the language in the script is executed, the corresponding constraints are added, and the added constraints are solved. Finally, the solving result is returned to the "result" page below the "text view" of the tool. If an error occurs, it will be displayed on the "error" page next to the "result" page, and the overall process is as shown in Figure 4 The solving result will be presented in the form of text and table, as shown in Figure 5

[0094] Table 1 KARMA index verification specific syntax

[0095]

[0096]

[0097] In the description of the present specification, the description referring to the terms "one embodiment", "example", "specific example" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are contained in at least one embodiment or example of the present application. In the present specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0098] The preferred embodiments of the application disclosed above are only used to help explain the application. The preferred embodiments do not describe all the details and do not limit the application to the specific embodiments described. Obviously, many modifications and changes can be made according to the content of the present specification. The present specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the application, so that those skilled in the art can well understand and utilize the application. The application is limited only by the claims and their entire scope and equivalents.​

Claims

1. An indicator verification method supporting quantitative evaluation of model attributes, characterized in that: The following steps are involved: S1: Adopt a model-based systems engineering approach to build a systems engineering model for problem solving. In the MetaGraph tool, build a domain system architecture model based on the "requirements architecture - functional architecture - logical architecture - physical architecture" modeling process commonly used in model-based systems engineering. MetaGraph, a multi-architecture unified modeling tool, supports the unified multi-architecture modeling language KARMA to express model-based systems engineering models, enabling the development and modeling of model libraries for different general modeling languages ​​and frameworks. S2: Based on the requirements and constraints of the model, use the KARMA language indicator to verify the syntax definition of the verification script containing the time-invariant constraints in the system model. The specific steps are as follows: a: Use KARMA indicator verification syntax to define the indicator verification module and the verification solver used; b: Define the required variables in the constraints according to the model and assign values; c: Construct constraints based on model information and add them to the solver; After declaring and assigning variables, it is necessary to perform quantitative operations on these variables based on model information to form constraints related to the model and requirements. The construction of constraints follows the satisfiability module theory. General constraints can be formally expressed as follows: C Bool =⊙(Property,Size(otherType),R) CBool ​​is an expression that integrates model attributes, the number of model elements other than attributes, real numbers, and various operators. Bool indicates that the expression return type is a Boolean expression, and the constraint expression must be an expression that returns Boolean. The symbol ⊙ is defined as a set of mathematical symbols in satisfiability module theory, including arithmetic operators, Boolean operators, array operators, and comparison operators. Size() indicates the calculation of the number of model elements of the remaining species. OtherType refers to model elements of types other than attributes, and R refers to real numbers. Different data types support different operations, but the final returned expression type is Boolean. After creating the constraints, you need to add them to the solver so that they can be evaluated. To add constraints, use the "add" keyword to declare the general solver or the "add" keyword to declare the optimized solver. Add equality constraints between components and the whole, add a constraint that the overall mass is no more than 360 kg, and add mass constraints between components. d: Add soft constraints and optimization objectives in the optimization solver; e: Evaluate the constraints and find a solution that satisfies the constraints; S3: The indicator verification compiler compiles the KARMA language indicator verification text and calls the solver based on satisfiability module theory; the specific steps are: The indicator verification engine processes the input verification script. The built-in syntax analyzer performs lexical analysis and syntactic analysis on the verification script, traverses the abstract syntax tree of the language, executes each statement separately, and obtains information about model elements. According to the indicator verification script, the solver based on the satisfiability module theory is called, and the language in the script is executed, the corresponding constraints are added, and the added constraints are solved.

2. The index verification method supporting quantitative evaluation of model attributes according to claim 1, characterized in that: The specific method of the above S1 is: When a problem requires constrained evaluation to validate forward progress, improve design efficiency, or reduce solution uncertainty, a metric verification approach can be employed. First, a unified multi-architecture modeling language, KARMA, is employed for this problem, incorporating the specifications of domain modeling languages. KARMA supports the description of multiple architecture models from different perspectives based on the GOPPRR modeling approach, enabling the full description of the development process of complex systems. The GOPPRR modeling approach has a high level of abstraction and is not limited to a specific domain, supporting the description of models for multiple architectures. The GOPPRR modeling approach constructs a domain metamodel using six basic meta-metamodels, serving as the domain modeling language and corresponding model library. Domain models are constructed within the instantiated metamodel, allowing for the analysis of real-world systems from multiple perspectives through the combination of models. A model-based systems engineering approach employs a "requirements architecture - functional architecture - logical architecture - physical architecture" modeling process. The requirements architecture captures the requirements of system stakeholders. The functional architecture describes the capabilities and services the system will provide, as well as the tasks it will perform. Logical components are abstract representations of physical components, executing system functions without imposing technical implementation constraints. The physical architecture defines the relationships and parameters between physical devices and their interfaces, aiming to describe specific, implementable solutions.

3. The index verification method supporting quantitative evaluation of model attributes according to claim 2, characterized in that: The specific steps of the above a are: The indicator verification module is declared using the "SMTAnalysis" and "end" keywords in the syntax; it starts with "SMTAnalysis Name" and ends with "endName", with the code body in between; Among them, the keywords in bold italics are fixed format, and the string following them indicates the module name. The module ends with the keyword "end", indicating the end of the module. The main body of the indicator verification code is written in the module. Depending on the type of problem being solved, the main body of the code first declares the type of solver required for the indicator verification: general solver or optimization solver. General solvers are only used to verify constraints, that is, whether the added constraints are conflict-free and return a "satisfied" result. Adding constraints that return Boolean types and a set of solutions that satisfy the constraints. Optimization solvers can also add "maximization" and "minimization" objective functions and weighted constraint expressions. The results are satisfied or satisfiable, and the result is the solution set that best meets the objective function. The syntax for calling a general solver is declared using the keyword "Solve". Its specific definition method begins with "Solve solverName" and ends with "end solverName", with the rest of the main code in between. The keyword "Solve" is followed by a string, which is the name of the general solver; the end of the solver is terminated with the keyword "end", followed by the same string; code such as model information, constraint definitions, and solving operations can be written within the solver declaration; if an optimization solver is called, the optimization solver is declared through the keyword "Optimize", and its specific definition method starts with "Optimize optName" and ends with "end optName", with the remaining main code added in between; The keyword "Optimize" is followed by a string, which is the name of the optimization solver; the end of the solver is terminated with the keyword "end", followed by the same string; code such as model information, constraint definitions, solving operations, and optimization operations can be written within the solver declaration; among them, the optimization solver is used as the solver for the application.

4. The index verification method supporting quantitative evaluation of model attributes according to claim 1, characterized in that: The specific steps of b above are: To verify whether the model meets the expected requirements, it is necessary to construct the constraints of the model information and metrics and judge the satisfaction of the constraints; first, it is necessary to define the variables in the constraints, and the code for defining the constraint variables is all located within the solver; the variables of the constraints support assignment, and the assignment can come from custom values or from the model; the data types of the variables support integer, real, array, matrix, and boolean, and are defined through their respective keywords. The specific declaration method for the data types is: "DataType variableName;". That is, the data type is followed by a variable name; the keyword "Int" declares an integer data type, followed by a string representing the name of the integer variable; the keyword "Real" declares a real data type, followed by a string representing the name of the real variable; the keyword "Boolean" declares a boolean data type, followed by a string representing the name of the boolean variable; the keyword "Array" declares an array type, followed by a string representing the name of the array variable. When declaring the array type, the index type and value type of the array also need to be declared; in the example of the above code, the index type and value type are indicated as integer through the keyword "array" and the data type name "int" within the parentheses; the keyword "Matrix" declares a matrix data type, followed by a string representing the name of the matrix variable. In the example of the above code, it is indicated that the data within the defined matrix is integer data and the matrix is an integer matrix through the keyword "IntegerMatrix", and the matrix variable is initialized through the keyword "initial". After "initial", two integers are written within the parentheses to define the rows and columns of the matrix respectively; If a variable needs to be assigned a value, there are generally two cases; one method is to directly assign a custom value to the variable, and its syntax is "DataType variableName = value;". DataType refers to a data type, variableName refers to the variable name, and value refers to the value. Another case is to extract information from the model and assign a value to the variable, thereby associating the model and verification information with each other. The syntax is "DataType variableName = LanguageName.ModelName.ObjectName.Property[PropertyName]"; Among them, LanguageName indicates the name of the modeling language used, ModelName indicates the name of the model corresponding to the extracted attribute, ObjectName indicates the name of the model object or other model element corresponding to the extracted attribute, the keyword "Property" indicates the extracted attribute, and PropertyName in the brackets indicates the attribute name; To solve the mass distribution of each component, first declare an indicator verification module, then define an optimization solver, and then define the corresponding variables. Extract the overall mass properties of the complex equipment, the mass properties of components A, B, C, D, and E, and the target values ​​of each component, such as maximum and minimum values, from the model and assign corresponding values.

5. The index verification method supporting quantitative evaluation of model attributes according to claim 1, characterized in that: The specific steps of the above d are: If you use an optimization solver, you can also add soft constraints and optimization objectives. In the optimization solver, soft constraints are optional and not all optimization solvers require them. Soft constraints are defined using the keyword "AddSoft". The parentheses introduced by the keyword need to add a constraint expression that returns a Boolean type and an arithmetic type value, usually an integer; Soft constraints are different from ordinary constraints. Soft constraints do not have to be satisfied. The integer defined by the soft constraint expresses the weight of the constraint. Solving soft constraints requires calculating which soft constraints need to be satisfied first based on the weights. Optimization objectives are commonly found in optimization solvers. Optimization objectives are declared using the "Max" or "Min" keywords, expressing a maximization expression or a minimization expression. The expression being optimized can only be an expression that returns an arithmetic type. It is necessary to minimize the working time of worker 1 and the production balance delay time. Add the keyword "Min" to guide the minimization objective.

6. The index verification method supporting quantitative evaluation of model attributes according to claim 1, characterized in that: The specific steps of the above e are: After defining the constraints or the constraints and optimization objectives, you need to operate the solver using the keyword "check" for the general solver or "Check" for the optimization solver, asking the solver to determine whether there are conflicts in the constraints. The result may be "SAT constraints satisfied", "UNSAT constraints not satisfied", or "UNKNOWN result unknown". If the result is "SAT constraints satisfied", you can use the keyword "solution" for the general solver or "Solution" for the optimization solver to obtain a solution that satisfies the constraints. If a general solver is used, a set of random solutions that meet the constraints is obtained. If an optimization solver is used, a set of solutions that are closest to the optimization objective and meet all constraints is obtained.

Images