Complex equipment design verification method based on model and prototype

Abstract

A complex equipment design verification method based on a model and a prototype adopts an improved modeling language and a model standard to realize basic innovation, supports digital definition of the prototype and the model through the language and the standard, and realizes deep integration of a functional model, a geometric prototype, an I-class performance prototype, an II-class performance prototype and a virtual-real test data model. All levels of total-factor digital prototypes such as a single machine, a subsystem, a whole system and the like are constructed and further integrated into a system-level performance prototype unit, total-factor digital equipment with generalization ability is constructed under the support of a cross-domain collaborative mechanism, a lightweight, operable and zero-dependency performance prototype unit is generated, and the performance prototype unit is published and delivered to the upstream. And fine design verification of the system is carried out to complete digital domain rapid iteration of complex equipment, so that the equipment development level is improved, and the development period is shortened.

Description

Technical Field

[0001] The present invention relates to a complex equipment design verification method based on models and prototypes, and belongs to the field of complex system design and verification. Background Art

[0002] Facing the "early, fast, comprehensive, and accurate" requirements of early discovery and solution of design problems, rapid iteration of new model schemes, comprehensive verification of operating conditions, and accurate achievement of technical and tactical indicators in the development of complex equipment systems, the model-based complex equipment design verification method can no longer fully meet the needs, and there is an urgent need to form a method for the design and verification of complex equipment systems driven by a hybrid of all-factor digital prototypes and digital models.

[0003] The technology for constructing digital prototypes has evolved from multi-domain and multi-physics field modeling to mechanism-data fusion modeling, and is developing towards integrated geometric / functional / performance and intelligent modeling. The integration of geometric elements, functional elements, and performance elements has become the development trend of future digital prototype construction technology. Following the MBSE model data standard roadmap, a series of modeling languages have emerged, such as the system design modeling standard SysML, the domain modeling languages AML language and CyPhyML language. However, there is no modeling language standard, method process, or application mode for all-factor digital prototypes. In the traditional aerospace technology design field, there is no model-related definition design technology that can achieve information interaction design and interface adaptation for different equipment framework branches in complex equipment systems, and currently, there is a lack of technical means to overcome these problems. Summary of the Invention

[0004] The technical problem solved by the present invention is: aiming at the lack of means for model design of complex equipment systems in the traditional aerospace technology design field in the current existing technologies, a complex equipment design verification method based on models and prototypes is proposed.

[0005] The present invention solves the above technical problems through the following technical solutions:

[0006] A complex equipment design verification method based on models and prototypes, comprising:

[0007] Defining all-factor digital prototypes, performing parameterization processing and parameter linkage on various types of all-factor digital prototypes;

[0008] Constructing various types of all-factor digital prototypes according to the defined content of all-factor digital prototypes and performing parameter association;

[0009] Performing encapsulation processing on the all-factor digital prototypes after parameter association, and performing cross-domain integration on the encapsulated all-factor digital prototypes;

[0010] Performing cross-domain simulation on the all-factor digital prototypes after cross-domain integration;

[0011] Test the all - element digital prototype that has successfully run the simulation, and release the all - element digital prototype that passes the test.

[0012] The all - element digital prototype includes a prototype part and a model part. The prototype part includes a structural prototype, a type - I performance prototype, and a type - II performance prototype; the model part includes a functional model and a virtual - real test model.

[0013] The structural prototype is used to describe the parameter information of the geometric structure of the equipment system. The type - I performance prototype is used to describe the interface information of the equipment system under each physical domain or information domain. The type - II performance prototype is used to perform finite - element simulation on the mesh model after the structural prototype is divided.

[0014] The functional model is used to describe the framework composition, interface design, and connection relationship of the equipment system. The virtual - real test model collects the test data of the equipment system and outputs learning data according to the preset data mapping relationship.

[0015] The parametric processing method of the all - element digital prototype is as follows:

[0016] Integrate and set a global variable pool in the type - I prototype. The preset parameter variables in the global variable pool include independent variables, dependent variables, and fixed variables.

[0017] The functional model reads the independent variables including the instance framework structure parameters from the global variable pool and realizes parameterization according to the settings of the independent variables.

[0018] The virtual - real test model reads the independent variables including adjustable input variables from the global variable pool and sets the adjustable input variables as the test data of the equipment system to realize parameterization.

[0019] The structural prototype realizes parametric expression by reading the fixed variables including CAD files or Step - format files or IGES - format files from the global variable pool.

[0020] The type - I performance prototype realizes parametric expression by reading the dependent variables including algorithm models or parameter input values of each physical domain from the global variable pool.

[0021] The type - II performance prototype realizes parametric expression by receiving a CAE file through external manual driving.

[0022] The parameter linkage method of the all - element digital prototype is as follows:

[0023] The instance framework structure parameters output by the functional model are input to the type - I performance prototype; the parameter information of the geometric structure of the equipment system output by the structural prototype is input to the type - I performance prototype. At the same time, mesh generation and load addition processing are performed according to the assembly model of the equipment system and input to the type - II performance prototype.

[0024] The Class II performance prototype performs simulation processing based on the received information and outputs the spatial response characteristics of each physical domain to the Class I performance prototype.

[0025] The Class I performance prototype receives all information, performs physical information fusion, and then records and outputs a description file.

[0026] The functional model is developed based on the SysML language, and the development content includes the requirement items, functional flows, system architectures, interface designs, and connection relationships of the equipment system.

[0027] The structural prototype is developed through CAD files, Step format files, or IGES format files, and data type conversion between the structural prototype and the Class I performance prototype is achieved according to the requirement items of the equipment system.

[0028] The Class I performance prototype constructs models of each physical domain through the Modelica language and develops the information domain model through the Julia language. Information interaction and conversion between various models are realized through memory sharing.

[0029] The Class II performance prototype is developed through various commercial CAE software, and mesh generation is performed using the output information of the structural prototype as the input.

[0030] The virtual-real test model takes the test data of the equipment system as the input and generates a virtual-real test model in the prototype adapter through machine learning and data fitting.

[0031] The parameter association of the all-factor digital prototype includes automatic association and manual association. Automatic association is automatically realized according to the conversion relationships or parameter linkage methods of various prototypes or models. The implementation method of manual association is as follows:

[0032] Proactively associate the parameters describing the same attribute of the equipment system according to the description files output by various prototypes or models.

[0033] The encapsulation processing of the all-factor digital prototype is implemented using the unified modeling language. The interfaces of various prototypes or models are uniformly encapsulated. Before the encapsulation starts, a general-purpose language is selected and the instruction naming rules are defined, and the instruction set is determined according to the instruction naming rules for encapsulation.

[0034] The cross-domain integration is achieved through GIT. After the all-factor digital prototype is defined, the all-factor digital prototype is constructed through the ontology model file uploaded by GIT. When constructing the all-factor digital prototype, various types of all-factor digital prototypes are called by invoking the ontology model file, and the commit records are saved. During the cross-domain integration process, version control or switching is performed by recording the version information of the selected model files.

[0035] The cross-domain simulation is implemented using the distributed collaborative simulation protocol DCP. During the operation of the cross-domain simulation, by setting the distributed nodes corresponding to each full-element digital prototype, all dynamic data of each full-element digital prototype at the current distributed node is read and transmitted through the data transfer interface. After the data interaction at the current distributed node is completed, the simulation time step is advanced to obtain all the dynamic data between the full-element digital prototypes at each simulation time step, thus completing the cross-domain simulation.

[0036] The test of the full-element digital prototype is the PMU test. The format of the description file output by the full-element digital prototype passing the test is detected, and all interface information of the full-element digital prototype passing the test is called for testing. The usability is judged according to the output interface test data.

[0037] If both the format detection and the call test are passed, the full-element digital prototype passes the PMU test and meets the release conditions.

[0038] The advantages of the present invention compared with the prior art are as follows:

[0039] (1) A complex equipment design and verification method based on models and prototypes provided by the present invention realizes basic innovation by adopting a new modeling language and model standards, constructs innovative designs through models and prototypes, updates the implementation modes of design verification and delivery applications, introduces prototypes into the MBSE loop, forms an overall definition, construction, encapsulation, and testing process based on models and prototypes, and supports the digital definition of prototypes and models with language and standards to achieve the deep integration of geometric models, type-I performance prototypes, type-II performance prototypes, and virtual and physical test data models. Under the support of the cross-domain collaboration mechanism, a full-element digital equipment with generalization ability is constructed, and lightweight, operable, and zero-dependency performance prototype units are generated through the PMU browser for release and upstream delivery. Early carry out system refinement design verification, support the generation and optimization of a large number of solutions to achieve the best solutions, support the verification of all-index parameter combinations to achieve the best products, support the virtual test of probing the limits of extreme working conditions to achieve full confirmation, and complete the digital delivery of model products, improving the equipment development level and shortening the development cycle.

[0040] (2) The present invention organically combines the functional architecture model, structural prototype, type-I performance prototype, type-II performance prototype, and virtual and physical test data model using full-element prototypes. Using this prototype, the functional framework, three-dimensional configuration, system-level simulation model, and professional simulation model of the system can be displayed simultaneously, realizing the replacement of the system in the digital domain. In addition, using the PMU to uniformly manage the full-element prototype model, the design can extract the model as needed, improving the model management and design efficiency.

[0041] (3) In the early design of the full-element performance prototype of the present invention, a class-II performance prototype model with detailed design and a high-precision virtual-real test model can be obtained, advancing the verification work in the detailed stage and the test stage, and realizing the left shift of verification.

[0042] (4) Since the parameters of the components of the full-element performance prototype of the present invention are interrelated, modifying the overall linkage improves the design efficiency. The full-element performance prototype is encapsulated using a unified domain language, and users only need to learn one language to perform rapid design, reducing the learning cost and improving the design efficiency. Since the functional model and class-I performance prototype have the ability of generalization, they can be derived into multiple solutions at the component level and parameter level, generating a large number of simulations, and then using an evaluation algorithm to find the best solution from the large number of solutions, realizing threshold expansion and optimization. The reduced-order model in the refined and detailed design stage can be used, thus realizing the left shift of the detailed design in the system engineering V model. Brief Description of the Drawings

[0043] Figure 1 Schematic diagram of the model and prototype conversion relationship provided by the present invention;

[0044] Figure 2 Schematic diagram of the parameter association between the model and the prototype provided by the present invention;

[0045] Figure 3 Schematic diagram of the construction of the full-element prototype provided by the present invention;

[0046] Figure 4 Schematic diagram of the CAL compilation and encapsulation provided by the present invention;

[0047] Figure 5 Schematic diagram of the construction of the CAL instruction set provided by the present invention;

[0048] Figure 6 Schematic diagram of the distributed simulation protocol communication based on DCP provided by the present invention;

[0049] Figure 7 Schematic diagram of the device status maintenance based on DCP provided by the present invention;

[0050] Figure 8 Schematic diagram of the data model parsing based on DCP provided by the present invention;

[0051] Figure 9 Schematic diagram of the classification of the protocol data unit PDU provided by the present invention;

[0052] Figure 10 Schematic diagram of the detailed definition of the protocol data unit PDU provided by the present invention;

[0053] Figure 11 Schematic diagram of the co-simulation synchronization control provided by the present invention;

[0054] Figure 12 This is the schematic diagram of the file structure provided by the present invention. Detailed implementation manners

[0055] A complex equipment design verification method based on models and prototypes realizes basic innovation by using an improved modeling language and model standards, supports the digital definition of prototypes and models with the language and standards to achieve the deep integration of geometric models, type-I performance prototypes, type-II performance prototypes, and virtual-real test data models, constructs a full-element digital equipment with generalization ability under the support of a cross-domain collaboration mechanism, generates lightweight, operable, and zero-dependency performance prototype units through a PMU browser for release and upstream delivery, and conducts system refinement design verification to complete the digital delivery of model products, improve the equipment development level, and shorten the development cycle.

[0056] The complex equipment design verification method based on models and prototypes comprises the following steps:

[0057] Define full-element digital prototypes, and perform parameterization processing and parameter linkage on various types of full-element digital prototypes;

[0058] Construct full-element digital prototypes and perform parameter association according to the defined content of the full-element digital prototypes;

[0059] Perform encapsulation processing on the full-element digital prototypes, and conduct cross-domain integration of the encapsulated full-element digital prototypes;

[0060] Conduct cross-domain simulation on all the full-element digital prototypes after cross-domain integration, and perform simulation monitoring during the cross-domain simulation operation;

[0061] Test the full-element digital prototypes with successful simulation operation, and use the full-element digital prototypes passing the test for equipment system control.

[0062] The steps of further design are as follows:

[0063] The full-element digital prototypes include a prototype part and a model part. The prototype part includes a structure prototype, a type-I performance prototype, and a type-II performance prototype; the model part includes a function model and a virtual-real test model;

[0064] The structure prototype is used to describe the parameter information of the geometric structure of the equipment system. The type-I performance prototype is used to describe the interface information of the equipment system in each physical domain or information domain. The type-II performance prototype is used to perform finite element simulation on the mesh model after the structure prototype is divided;

[0065] The function model is used to describe the framework composition, interface design, and connection relationship of the equipment system; the virtual-real test model collects the test data of the equipment system and outputs learning data to realize the mapping relationship between input data and output data.

[0066] The parametric processing method for the full-element digital prototype is as follows:

[0067] The functional model is parameterized by setting the parameters of the instance framework structure, and the virtual-real test model is parameterized by setting adjustable input variables as the test data of the equipment system.

[0068] The structural prototype is parameterized through CAD files, Step format, or IGES format. The type I performance prototype is parameterized by the input values of the parameters in each physical domain through algorithm models or equations. The type II performance prototype is parameterized through CAE files.

[0069] The parameter linkage method for the full-element digital prototype is as follows:

[0070] The parameters of the instance framework structure output by the functional model are input into the type I performance prototype. The parameter information of the geometric structure of the equipment system output by the structural prototype is input into the type I performance prototype. At the same time, mesh generation and load addition processing are performed according to the equipment system assembly model and input into the type II performance prototype.

[0071] The type II performance prototype performs simulation processing based on the received information and outputs the spatial response characteristics of each physical domain and inputs them into the type I performance prototype.

[0072] The type I performance prototype performs physical information fusion after receiving all the information.

[0073] The functional model is developed based on the SysML language. The development content includes the requirement items, functional flow, system architecture, interface design, and connection relationships of the equipment system.

[0074] The structural prototype is developed through CAD files, Step format, or IGES format, and the type conversion between the structural prototype and the type I performance prototype is realized according to the requirement items of the equipment system.

[0075] The type I performance prototype develops and constructs models for each physical domain through the Modelica language and develops the information domain model through the Julia language. Information interaction and conversion are realized between various models through variable interaction and memory sharing.

[0076] The type II performance prototype is developed through various commercial CAE software and performs mesh generation with the output information of the structural prototype as the input.

[0077] The virtual-real test model takes the test data of the equipment system as the input and generates the virtual-real test model in the prototype adapter through machine learning and data fitting.

[0078] The parameter linkage of the full-element digital prototype includes automatic association and manual association. The automatic association is automatically realized according to the conversion relationship or parameter linkage method of various prototypes or models. The implementation method of manual association is as follows:

[0079] Actively associate the parameters describing the same attribute of the equipment system according to the conversion relationship or parameter linkage method of various prototypes or models;

[0080] After the parameter linkage is completed, a corresponding associated information XML file is generated.

[0081] The encapsulation process of the full-element digital prototype is implemented using the Unified Modeling Language. The interfaces of various prototypes or models are uniformly encapsulated. Before the encapsulation starts, a general-purpose language is selected and the instruction naming rules are defined. The instruction set is determined according to the instruction naming rules for encapsulation.

[0082] Cross-domain integration is achieved through GIT. After the full-element digital prototype is defined, the ontology model file is uploaded through GIT. When constructing the full-element digital prototype, commit, restore, and push operations are performed on the local model file, and the commit records are saved. During the cross-domain integration process, version control is performed by recording the version information of the selected model files.

[0083] Cross-domain simulation is implemented using the Distributed Co-Simulation Protocol DCP. During the simulation operation, data interaction between each full-element digital prototype is achieved by setting the corresponding distributed nodes of each full-element digital prototype. The data interaction is realized through the data transfer interface. After the data interaction is completed, the simulation time step is advanced to achieve dynamic information exchange between each full-element digital prototype at each simulation time step, and the information of all simulation operation processes is collected to complete the cross-domain simulation.

[0084] The following is a further description in conjunction with the accompanying drawings of the specification and the preferred embodiments:

[0085] In the current embodiment, a complex equipment design and verification method for prototypes and models is proposed to solve problems in the prior art such as the inability to carry out refined design verification in the early stage of equipment, the limitation of the solution design by the designer's experience, the inconsistent expression of prototype models, and the dependence of different models on different environments. The method is carried out according to the following process:

[0086] Define the full-element prototype: The full-element digital prototype is characterized by including a system framework function model, a three-dimensional geometric model (structural prototype), a complex system multi-domain system-level function and performance model (type I performance prototype), a multi-field finite element performance model (type II performance prototype), a virtual and physical test data model. Various models are organically combined into a whole, supporting the conversion and parameter linkage between models.

[0087] Develop a full-element prototype: Develop an architecture model using the SysML language, develop a structural prototype using commercial CAD tools or self-developed software that supports Step and IGES formats, develop a type-I performance prototype using Modelica and Julia languages, develop a type-II performance prototype using commercial CAE software, and develop a virtual-real test data model using machine learning, data fitting, etc.

[0088] Package the full-element prototype: Construct a domain language to package the operations of the full-element performance prototype, including the encapsulation of the functional model, structural prototype, type-I performance prototype, type-II performance prototype, and virtual-real test data model operations. The types of functions after encapsulation include the construction, integration, and simulation of the prototype.

[0089] Cross-domain integrate the full-element prototype: Adopt a file-based network collaboration method to integrate the prototype across regions and departments, and support collaborative construction and simulation.

[0090] Test and release the full-element prototype: Use the performance prototype interface encapsulation method to generate lightweight, runnable, and zero-dependency performance prototype units, and use these units for testing and release.

[0091] 2.1 Define the full-element digital prototype

[0092] It includes the functional architecture model of the system, the three-dimensional geometric model (structural prototype), the multi-domain system-level functional performance model of complex systems (type-I performance prototype), the multi-field finite element performance model (type-II performance prototype), and the virtual-real test data model. The following are the definitions of the prototype components:

[0093] It includes a functional model that describes the overall framework, main components, interfaces, and connection relationships of the system. The structural prototype, type-I performance prototype, and type-II performance prototype are refined based on the functional model;

[0094] The structural prototype, characterized by not only describing the geometric parameter information of the system (shape, size, position, rotation), but also describing features such as mass, center of mass, moment of inertia, surface area, and volume. It supports the conversion of the structural prototype into a type-I performance prototype;

[0095] Type-I performance prototype:

[0096] Multi-domain (mechanical, electrical, thermal, etc.) mechanism models based on algebraic differential equations; models of the information domain (sensing, data, communication, computing, and control, etc.) based on scientific computing; reduced-order multi-physical field (aerodynamic heat) models, test data models. The content of the Class I performance prototype is characterized by including the detailed component interfaces of the system, principle equations & algorithms. The types of systems and interfaces supported for expression include: mechanical, electrical, thermal, information, fluid, etc. Mechanical principles can be expressed by kinetic equations, electrical principles by Kirchhoff's law equations, thermal principles by heat conduction, heat convection, and heat radiation equations, information by algorithms such as channel capacity calculation, bit error rate calculation, and network throughput calculation in information theory, and fluid by continuity equations, energy equations, and momentum equations;

[0097] The Class I performance prototype is built using Modelica and Julia languages, supports generalization relationships itself, and can realize the replacement of system components. In addition, the prototype is built in a hierarchical and modular manner during construction and supports bottom-up assembly.

[0098] Class II performance prototype:

[0099] It includes a grid model divided based on the structural prototype and can perform multi-field finite element simulations.

[0100] Virtual and physical test models

[0101] Taking test input and output data as input, generating a data-based proxy model (dynamic link library) through algorithms such as machine learning and data fitting to achieve the mapping relationship of input and output data, and supporting the technology of using Modelica to call the dynamic link library to encapsulate this model into a Class I performance prototype.

[0102] According to the modeling objectives and requirements, digital prototype elements (functional models, structural prototypes, Class I performance prototypes, Class II performance prototypes, test data models) can be selected for construction and combined integration.

[0103] The models and prototypes achieve model parameterization in the following ways:

[0104] Functional model parameterization: The functional model is expressed in an object-oriented manner, supports relationships such as generalization, composition, aggregation, and dependency, and mainly includes types (including the composition, interfaces, and value attributes of types), instances (instantiation of types). Parameterization mainly parameterizes the value attributes (integer, floating-point, string, complex structure) of types and instances and supports setting the values of value attributes.

[0105] Parametrization of the structural prototype: The structural prototype is expressed using CAD files in commercial software format, STEP format, and IGES format. CAD files in commercial format are inherently parametric and support setting parameter values using scripts (e.g.). STEP and IGES also only use parametric expressions for the 3D model of the system and equally support parametric settings;

[0106] Parametrization of Class I prototypes: Class I models are similar to functional models and are expressed in an object-oriented manner. Additionally, the expression of mechanisms and algorithms is added, with the value attributes of the type as the input, and the mechanisms of the system are expressed by establishing equations, algorithms, etc.

[0107] Parametrization of Class II prototypes: Class II prototypes are expressed using CAE files in commercial software format and support parametric settings;

[0108] Parametrization of the virtual and physical test model: The virtual and physical test model is essentially generated from a series of input and output variable data. When generating the test model, the input variables can be set as adjustable parameters;

[0109] The models and prototypes are organically combined into a whole, and parameter linkage is achieved through the following methods:

[0110] The functional model can be used as the input of Class I prototypes, and through model mapping and conversion technologies, Class I performance prototypes are generated.

[0111] The structural prototype can be used as the input of Class I performance prototypes, and through multi-body conversion technologies, the mass characteristic parameters are transferred to Class I prototypes.

[0112] The structural prototype can also be used as the input of Class II, and based on the geometric model, mesh generation, addition of constraints and loads are carried out.

[0113] The refined simulation results of Class II prototypes can integrate the spatial response characteristics such as stress fields, temperature fields, flow fields, and electromagnetic fields into Class I performance prototypes through methods such as (mechanism, data) reduction order.

[0114] The virtual and physical test model can be encapsulated using the construction language of Class I performance prototypes to generate Class I performance prototypes.

[0115] The above prototypes use XML to describe the association relationships between the models and prototype parameters, such as Figure 1 shown; The parameter association form is as Figure 2 shown;

[0116] The associated relationships are described using XML as follows:

[0117] <System name=“System”>

[0118] <Parameter name=“Length”>

[0119] <FunctionModel name=“功能模型”ParameterName=“长” / >

[0120] <StructureMockup name=“结构样机”ParameterName=“长” / >

[0121] <I_PerformanceMockup name=“I类性能样机”ParameterName=“长” / >

[0122] <II_PerformanceMockup name=“II类性能样机”ParameterName=“长” / >

[0123] <name=“II类性能样机”ParameterName=“长” / >

[0124]

[0125]

[0126] The full-factor digital prototype is sorted according to the design process and divided into: functional model, structural prototype, Class I performance prototype, Class II performance prototype, virtual and real test data model. The elements between them are interrelated and linked.

[0127] The functional model is used to describe the framework composition, interface design and connection relationship of the equipment system; the structural prototype is used to describe the parameter information of the geometric structure of the equipment system; the Class I performance prototype is used to describe the interface information of the equipment system under each physical domain or information domain; the Class II performance prototype is used to perform finite element simulation on the mesh model after the structural prototype is divided; the virtual-reality test model collects the test data of the equipment system and outputs learning data to realize the mapping relationship between input data and output data.

[0128] Models and prototypes are all parameterized. Parameters are divided into independent variables, dependent variables, fixed quantities and enumeration types. Independent variables can be assigned values independently and do not depend on the values of other variables. Dependent variables cannot be assigned values independently, but are calculated based on the values of other independent variables (for example: b = a + 1, and b is a dependent variable). Fixed quantities are fixed values and cannot be modified. Enumeration types express special meanings through numerical values, such as 1 for a round hole and 2 for a square hole.

[0129] Use the global variable pool to realize the linkage of parameters. The variables in the global variable pool can be independent, dependent, or fixed. This type of variable is used as an independent variable of the model or prototype. After modifying its value, the parameters of the model or prototype are collectively linked.

[0130] The global variable pool is located in the Class I prototype, which drives other models and prototypes to work in conjunction with each other. Some global variables come from the architecture parameters of the functional model and the three-dimensional parameters of the structural model.

[0131] Functional model driven: driven by global variable pool

[0132] Structural prototype driver: For commercial CAD files, the driver is implemented by calling the API of commercial software. For common formats (Step, IGES), the feature modeling global variable pool driver is used.

[0133] Class II Prototype Drive: This type of model is finitely parameterized and requires human-in-the-loop synchronization.

[0134] Virtual-reality test model: This type of model has full parameterization capabilities and is driven by a unified variable pool.

[0135] 2.2 Development of full-factor prototype

[0136] (1) Construction of full-factor prototype

[0137] Functional model: Use SysML language for development to build system requirements, functional flows, system architecture, components, interfaces and connection relationships;

[0138] Structural prototype: Supports development using commercial software, and then converts to Step or IGES format models. Using the above models as input, it can automatically generate structural prototypes and Class I performance prototypes expressed by Modelica. The quality characteristic parameters of Class I performance prototypes are automatically generated based on the 3D model;

[0139] Class I performance prototype:

[0140] Use Modelica and other languages to develop and build physical domain models, and use Julia and other languages to develop information domain models. Through interactive technologies such as variable interaction and memory sharing, based on a unified graphical modeling environment, the construction of system-level information-physical fusion models is realized.

[0141] When building a prototype, the system is first abstracted, a generalized model is built, the abstract interfaces and components of the system are defined, and then an instantiated model is built.

[0142] When constructing the prototype, it is constructed in a hierarchical manner similar to "system-subsystem-equipment", assembling equipment into subsystems and subsystems into systems.

[0143] Class II performance prototype:

[0144] Support the use of commercial CAE software for development. Taking the structural prototype as the input, after mesh generation, generate the Class II prototype model.

[0145] Virtual and real test model:

[0146] Taking test data as the input, using technologies such as machine learning and data fitting, through the prototype adapter (DMA), generate the virtual and real test model (dll). Package it using the Modelica model, as Figure 3 shown;

[0147] (2) Prototype parameter association

[0148] Automatic parameter association: Automatically associate the parameters between the converted models according to the model conversion relationship;

[0149] Manual parameter association: Select the parameters expressing the same attribute of the system in the functional model, structural model, Class I performance model, Class II performance model, and virtual and real test model for association;

[0150] Association information generation: Generate the XML of the association information according to the information of automatic association and manual association;

[0151] 2.3 Package the full-element prototype

[0152] Use the domain modeling language for unified packaging, and realize the unified operation of the structural prototype, Class I performance prototype, and Class II performance prototype through the unified language, while only learning one language to reduce the learning cost.

[0153] The packaging process of the full-element digital prototype is implemented using the unified modeling language. The interfaces of various prototypes or models are uniformly packaged. Before the packaging starts, select the general language and define the instruction naming rules, and determine the instruction set according to the instruction naming rules for packaging.

[0154] Instructions include: instruction name, parameter variables, return values, and configuration variables, where parameter variables and configuration variables are optional. The role of the configuration variable is to specify the specific behavior of this instruction, such as refresh, reset, and other parameters.

[0155] Unify the packaging of the external interfaces of each model and prototype tool through the script of CAL (Common Aerospace Language). By calling the interfaces of the tools, the operation of the models and prototypes can be realized. Tools usually provide interfaces such as com, plugins, and scripts. The CAL compiler compiles the instructions into C code for calling com and plugins or tool scripts according to the actual situation. As Figure 4 shown;

[0156] CAL encapsulates and integrates general modeling language tools at the call layer, including tools such as SysML, Modelica, Julia, and Python. Then, it encapsulates tools such as CAD and CAE, enabling CAL to have the ability to call underlying tools.

[0157] Then, define the language features of CAL, supporting functions, algorithms, control flow; advanced data structures, object orientation; declarative, procedural, and component-based modeling.

[0158] Finally, define the instruction set according to the CAL language features, including construction class instructions, integration class instructions, and running class instructions.

[0159] 2.3.1 Naming Rules for Domain Modeling Language Instructions

[0160] Select a general language and define encapsulated functions based on this language. The function naming rules are as follows: starting with the abbreviation of the domain language + platform identifier + behavior (verb-object structure);

[0161] The parameter naming rules for functions are as follows: represented by lowercase underscores:

[0162] Example: bool CAL_MW_CreateEngine(EngineType engine_type)

[0163] The implementation rules for the function body are as follows:

[0164] The behavior of the operation must consider the unified modification of the structural prototype, Class I performance prototype, and Class II performance prototype; the modification of the structural prototype should be placed in the pseudocode before the Class II prototype settings as follows:

[0165] / / This function body modifies the length of the propellant grain

[0166] / / Modify the propellant grain length parameter in the structural prototype

[0167] CAL_ZW_EditGrainLength(grain,10);

[0168] / / Output the neutral format file in the structural prototype

[0169] CAL_ZW_OutputStep(grain,"D:\CAD\grain.step");

[0170] / / Use the multi-body conversion toolbox to update the Class I performance prototype parameters with the neutral format file as the input

[0171] CAL_MW_UpdateIMockup(grain,"D:\CAD\grain.step");

[0172] / / Update the Class II performance prototype model and parameters with a neutral format file as input

[0173] String strIIMockupFilePath;

[0174] CAL_ABAQUS_UpdateIIMockup(grain, “D:\CAD\grain.step”,

[0175] strIIMockupFilePath);

[0176] / / Call the model order reduction tool to regenerate the reduced-order model

[0177] CAL_MW_GenerateRom(grain, strIIMockupFilePath);

[0178] 2.3.2 Domain Modeling Language Instruction Set

[0179] The instruction sets commonly used by users include construction class, integration class, and operation class instructions, mainly for constructing prototypes, integrating interface connections between systems, and simulating systems. Since the instructions are essentially calls to various tools, it is also necessary to implement the basic class instructions for calling each model and prototype tool. The following figure shows the composition of the instructions. The digital prototype development environment has the functions of constructing a functional model, Class I prototype, and virtual-real test model, and provides a script API. CAL calls the script API to operate on the models and prototypes; the structural prototype and Class II performance prototype are constructed using commercial CAD / CAE tools, and CAL calls the external interfaces (com, plugins, instructions, etc.) provided by the tools to operate on the models and prototypes. As Figure 5 shown;

[0180] 2.4 Cross-Domain Integrated All-Element Prototype

[0181] Due to the complex structure and strong cross-professional nature of the equipment system, it is usually completed by designers from different specialties collaborating. Each designer is usually in a different location, so it is necessary to achieve cross-domain integration and simulation of the all-element prototype through the network.

[0182] 2.4.1 Cross-Domain Integration

[0183] Cross-domain integration uses Git to achieve collaborative management of models in a file-based manner, mainly including uploading / downloading of models and version management;

[0184] Cross - domain integration supports two methods. One is the integration of prototypes, which supports prototypes in CAL and PMU formats. PMU is the format after the prototype is released. The other is the integration of the executable test data model DMS. The difference is that the integration of prototypes is based on continuous - time simulation, simulating the real - world simulation. While the simulation of DMS is a logical simulation, without the concept of time, only having the running process and the input - output connection relationship.

[0185] For prototype integration, prototypes can be submitted to the service via GIT to achieve unified integration on physical files. Or, without submitting files, the IP address of the prototype computer, the location of the prototype on the computer, and the prototype interface information can be submitted to achieve logical integration. These information are described using Json, mainly including the prototype name, adjustable parameters and types of the prototype, prototype interfaces and types, etc.

[0186] Prototype logical integration is for protecting intellectual property rights. When the model cannot be obtained, it can still be remotely called. By parsing the prototype Json file, the style and interfaces of the prototype are materialized and interface connections are made to achieve integration. Since prototypes are distributed on different computers, the simulation is a distributed joint simulation. Using the http protocol, the basic - type simulation of the prototype is called through the IP address and location of the prototype computer, and the simulation results are obtained. The content of the simulation results includes: model name, computer IP, output interface variable name and value.

[0187] The integration of DMS also supports unified integration and logical integration on physical files. The data files uploaded for logical integration are the same as those for prototype integration. Based on a logical process, after one DMS runs, the data is passed to the next DMS.

[0188] Specifically:

[0189] (1) Model upload and download

[0190] Under the model editing in the repository, the local model file is uploaded to the cloud repository, and the statistics of the number of uploaded files is supported. Users can choose any version of the repository for offline download.

[0191] A. Local commit

[0192] Commit the modified model in the current working space to the local repository. A commit log needs to be entered during the commit.

[0193] B. Revert

[0194] Revert the status of all selected files that have not been locally committed.

[0195] C. Push

[0196] Pull: Pull the latest commit content from the server. Download the latest version modified on the server to the current model, and handle conflicts between the server version and the current local version.

[0197] D. Commit Records

[0198] You can view all commit records, including those committed to the local repository and the remote repository. Display all commit records of the selected model, and you can also display the modified content of a single record in the commit records.

[0199] (2) Version Management

[0200] This function can record the historical version information of the model, including the model modification time, modifier, version description, etc. Support tracing historical versions and viewing version differences.

[0201] After the user enters the repository, they can choose to view the repository file view and model view of a certain version. They can also view all historical version information of the repository, screen the commit information by username. In addition, users can export all historical information. Users can select two different versions to compare the differences between the two versions. The comparison page shows the number of modified files and the specific information of the modified text files.

[0202] In the file view of the repository, the user can click on the file version to view the historical versions of a certain file and can export all historical information of the file. Users can select two different versions to compare the differences between the two versions. If the file is text, the differences between the texts will be shown, such as the addition and deletion of characters, etc.

[0203] A. Repository Version

[0204] After the user enters the repository, they can choose to view the repository file view and model view of a certain version. After the user enters the repository version page, they can view all repository version lists and display information such as the commit user and commit time of each version. Users can screen the historical version information by the name of the committer; users can also export the Excel file of the historical version.

[0205] B. Repository Version Comparison

[0206] After the user enters the repository version page, they can select two versions to compare the version information and enter the version comparison page. This page shows the difference statistics information of the files between the versions, including the number of modified, deleted, and newly added files. The specific situation of the file differences in the repository is listed according to the files, and each file shows the difference (modified / deleted / newly added). If it is a text file, the specific difference information in the text is shown.

[0207] C. File Version

[0208] After the user enters the warehouse, they can choose to view the version information of a certain file. After clicking on the file version to enter the file version page, they can view the file version list, and the page displays information such as the user who submitted each version and the submission time. The user can export the Excel file of the historical versions, or click to view the content of a certain version file.

[0209] D. Model Version Comparison

[0210] After the user enters the file version page, they can choose to compare the file version information between two versions. This page shows the detailed differences between the two versions of the file. If it is a text file, it shows the specific differences in the text. The modified text lines are marked with a light yellow background, the deleted characters are marked with a red background, and the newly added characters are marked with a green background.

[0211] 2.4.2 Cross-Domain Simulation

[0212] Cross-domain simulation uses the distributed joint simulation protocol DCP to meet the distributed simulation requirements of this project. On the one hand, it supports the communication and data exchange of distributed joint simulation by implementing the DCP protocol at the underlying layer to support simulation tools.

[0213] (1) Distributed Simulation Protocol Communication Based on DCP

[0214] The distributed joint simulation protocol (DCP) is a standard independent of platforms and communication media. It belongs to an application-level communication protocol used to integrate models or real-time systems into a simulation environment. DCP was developed under the framework of the ACOSAR (Advanced Co-Simulation-Open Systems-Architecture) project. DCP specifies a data model, a finite state machine, a set of protocol data units (PDUs), and a communication protocol. It aims to integrate real-time and / or non-real-time systems. Currently, it has received extensive attention and applications. As Figure 6 shown;

[0215] (2) Equipment Status Maintenance Based on DCP

[0216] The simulation drive engine is the core of the entire distributed simulation system. It uses state machine technology to support real-time / non-real-time simulation, and can precisely control the entire simulation operation process, as well as exception capture and exception handling during operation. The entire simulation drive process can be divided into:

[0217] · Step: Registration

[0218] · Step: Simulation Configuration

[0219] · Step: Initialization

[0220] ·Step: Run / Solve

[0221] ·Step: Stop

[0222] Step: Exception Handling

[0223] The overall process is as Figure 7 shown;

[0224] (3) DCP-based Data Model Parsing

[0225] DCP specifies a model description file (.dcpx), which adopts the XML file format and details all information of each computing unit. The model format file needs to be parsed to obtain the specific model information. It mainly includes the following aspects:

[0226] ·Operating mode: hard real-time, soft real-time, non-real-time;

[0227] ·Units: basic units and display units;

[0228] ·Types: basic types include Int8, Int16, Int32, Int64, Uint8, Uint16, Uint32, Uint64, Float32, Float64, String, Binary, etc.;

[0229] ·Specific notes of the vendor;

[0230] ·Time resolution;

[0231] ·Heartbeat monitoring: maximum periodic interval;

[0232] ·Transport protocols: including TCP, UDP, CAN, USB2, etc.;

[0233] ·Function flags: used to indicate the availability of specific functions;

[0234] ·Variables: Input, Output, Parameter, etc.;

[0235] Log Log Definition;

[0236] The process is as Figure 8 shown;

[0237] (4) DCP-based Data Model Parsing

[0238] Data communication is carried out between the distributed master control end and the slave control end through the Protocol Data Unit (PDU). Generally speaking, a DCP Slave must be able to send and receive such PDUs. PDUs are mainly divided into four categories according to their types: Request, Response, Notification, and Data. Among them, Request PDUs are further divided into three categories: Configuration, State Transfer, and Information.

[0239] As Figure 9 shown;

[0240] The DCP specification details the field format and content of PDUs, as specifically Figure 10 shown;

[0241] (5) Ultra-real-time, soft real-time, and hard real-time simulations

[0242] Ultra-real-time simulation means that the simulation time in the virtual world is faster than the real time.

[0243] Soft real-time simulation requires that the simulation time in the virtual world be consistent with the real time, but occasional timeout errors can be tolerated. The consequences of failures are not serious. For example, in a network, it only slightly reduces the system throughput.

[0244] Hard real-time simulation requires that the simulation time in the virtual world must be consistent with the real time. It has a rigid and unchangeable time limit and does not allow any errors beyond the time limit. Timeout errors can cause damage or even lead to system failure, or cause the system to fail to achieve its intended goals.

[0245] Ultra-real-time, soft real-time, and hard real-time simulations have requirements not only for model simulation algorithms and simulation control but also for the system's hardware devices and operating systems. Since this system cannot control the hardware devices, operating systems, and algorithms of external models, ultra-real-time, soft real-time, and hard real-time simulations can only be achieved through simulation control. As Figure 11 shown;

[0246] During the simulation running process, it is necessary to coordinate whether each simulation software and model at each simulation communication point of each distributed node needs data interaction. If data interaction is required, the data transfer interface is used for data interaction between simulation models. After the data interaction is completed, the process is advanced to continue the solution calculation of the next simulation time step and execute the calculation-related components. By continuously advancing the simulation time step in this way, dynamic information exchange between simulation models can be achieved at each simulation time step, and the scheduling execution of the time sequence process can be completed. Therefore, during the entire simulation process, it is necessary to continuously coordinate the operation and communication of each computing node through the main control program to ensure the smooth progress of the simulation and the accuracy of the results.

[0247] (6) Simulation Monitoring

[0248] Monitor the content of the simulation task scenario and support viewing the simulation status when available. The main options include:

[0249] · Equipment status includes: equipment not connected, equipment connected, equipment disconnected, equipment connecting.

[0250] · Real-time displayed simulation data includes: variable curve display, 2D principle animation, and 3D simulation animation.

[0251] · Simulation log query includes: simulation time, status of each device at each stage of the simulation, events that occurred during the simulation, etc.

[0252] Abnormal situations include communication anomalies, solution anomalies, etc.

[0253] (7) Simulation Control Interaction

[0254] Simulation interaction control mainly refers to the interaction means supported by the simulation task scenario, mainly including:

[0255] · Simulation start: Provide a simulation start interface for users to operate and start the simulation when the simulation scenario configuration is ready.

[0256] · Simulation pause / resume: Provide an interface for pausing and resuming the simulation at any time. When an anomaly is encountered during the simulation, it can be checked and repaired before continuing the simulation.

[0257] · Simulation stop: Provide a simulation stop interface to stop the simulation when it cannot continue due to simulation / communication anomalies.

[0258] 2.5 Test and Release the Full-Feature Prototype

[0259] The release of the full-feature prototype follows the interface encapsulation method of the performance prototype and uses lightweight, runnable, and zero-dependency performance prototype units (PMUs) for release and testing. The performance prototype unit is the unified format expression of the full-feature digital prototype and is used for the integration, delivery, testing, and simulation of the performance prototype.

[0260] After the prototype is released, the format is PMU, and the release standard is the PMI standard. The performance prototype unit (PMU) is essentially a compressed package that contains an overall description file, a functional model file, a structural prototype file, a Class I performance prototype executable file, and a Class II performance prototype file. The file structure should at least contain:

[0261] Overall description file (ModelDescription.xml): Mainly describes the overall information of the model, including the name, types of models included, inputs, outputs, and internal parameters, as well as the association relationships between the parameters.

[0262] Functional model file (functionModel): Describes the SysML file using an XMI file in accordance with the UML 2.5 standard;

[0263] Structural prototype file (structureMockup): Uses mainstream commercial files or neutral 3D files;

[0264] Executable library files (pmu.dll, pmu.lib): Interface files provided for external system calls, including model initialization, simulation, termination, obtaining 2D and 3D views, obtaining the model file path, etc.;

[0265] Resource folder required for the executable library files (resource): Stores the resource files required for the executable library files, including text, image, and other files;

[0266] The overall description file is a very important file for the prototype. It describes the interfaces and parameters and is an important file for the physical realization of the prototype.

[0267] The executable library file is also a very important file for the prototype. It is the file for simulation execution, corresponding to the description file, and supports setting and retrieving interface values. It provides at least the following interfaces:

[0268] Instance operation interface

[0269] · Model instantiation interface, returns the model instantiation object

[0270] · Initialization of instance object interface

[0271] · Termination of instance interface

[0272] · Reset instance interface

[0273] · Release instance interface

[0274] Simulation interface

[0275] · Obtain variable values of integer, floating-point, boolean, and string types

[0276] · Set variable values of integer, floating-point, boolean, and string types

[0277] · Simulation execution of one-step function

[0278] · Skip function for current one-step execution.

[0279] The PMU browser is provided to view the geometric 3D configuration of the prototype, view the 2D view of the physical principle, and be able to call the executable library file to implement parameter adjustment and simulation, and display views such as variable curves, variable tables, 3D animations, and field animations.

[0280] The PMU test mainly includes:

[0281] · Whether the format content of the description file is correct and complies with the specification

[0282] · Whether the interfaces such as the instantiation operation and simulation of the library file can be normally called and return the correct values

[0283] · The consistency between the variables in the description file and the executable library file, and whether the input and output variables described in xml can be successfully called through the interfaces of the library file

[0284] Specifically:

[0285] (1) Composition of the Performance Mockup Unit (PMU)

[0286] The Performance Mockup Unit (PMU) is essentially a compressed package, containing the overall description file, functional model file, structural mockup file, Class I performance mockup executable file, and Class II performance mockup file. The file structure should at least contain the following content as shown Figure 12 as follows:

[0287] Overall description file (ModelDescription.xml): Mainly describes the overall information of the model, including the name, types of models included, inputs, outputs, and internal parameters, as well as the association relationships between the parameters.

[0288] Functional model file (functionModel): Describes the SysML file using an XMI file in the UML2.5 standard;

[0289] Structural mockup file (structureMockup): Uses mainstream commercial files or neutral 3D files;

[0290] Class I performance mockup (IPerformanceMockup): Uses Modelica and Julia model files;

[0291] Class II performance mockup file (IIPerformanceMockup): Uses commercial multi-field model files;

[0292] Executable library files (pmu.dll, pmu.lib): Interface files provided for external systems to call, including model initialization, simulation, stop, obtaining 2D and 3D views, obtaining the model file path, etc.;

[0293] Resource folder (resource) required for the executable library file: Stores the resource files required for the executable library file, including text, image, and other files;

[0294] (2) The model description file should at least contain the following information

[0295] Basic information: performance prototype specification version, model name, globally unique identifier, model description, author, model version, copyright, certificate information, generation tool information, generation date and time;

[0296] Variable information: variable name, variable memory type (integer, floating point, boolean, string), variable description, unit, variable parameter type (input, output, parameter);

[0297] Variable types: Input represents the input variables of the system, which can be connected to the output variables of other systems; Output represents the output variables of the system, which can be connected to the input variables of other systems; Parameter represents adjustable initialization variables;

[0298] It also includes parameter association information;

[0299] (3) The executable library file shall provide at least the following interfaces externally

[0300] Instance operation interface

[0301] · Model instantiation interface, which returns the model instantiation object

[0302] · Initialization instance object interface

[0303] · Termination instance interface

[0304] · Reset instance interface

[0305] · Release instance interface

[0306] Simulation interface

[0307] · Obtain the values of integer, floating point, boolean, and string type variables

[0308] · Set the values of integer, floating point, boolean, and string type variables

[0309] · Simulation execute one-step function

[0310] Current execute one-step skip function.

[0311] The complex equipment design verification method based on model and prototype proposed in this embodiment realizes fundamental innovation with a brand-new modeling language and model standard, realizes technological innovation with a brand-new model and prototype construction method, and realizes mode innovation in design verification and delivery applications. Introducing the prototype into the MBSE loop to form a model- and prototype-based systems engineering (M 2The BSE (Model and Mock-up Based System Engineering) methodology uses language and standards to support the digital definition of prototypes and models (including the CAL white box mechanism, PMU gray box mechanism, and DMA black box mechanism), realizes the deep integration of geometric models, Class I performance prototypes, Class II performance prototypes, and virtual and physical test data models, constructs a full-element digital equipment with generalization ability under the support of cross-domain collaboration mechanisms, generates lightweight, operable, and zero-dependency performance prototype units through the PMU browser for release and upstream delivery, conducts early system refinement design verification, supports the generation and optimization of a large number of solutions to achieve the best solutions, supports the verification of all-index parameter combinations to achieve the best products, supports virtual tests for exploring the limits of extreme operating conditions for full confirmation, and completes the digital delivery of model products, improving the equipment development level and shortening the development cycle.

[0312] Although the present invention has been disclosed above with preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications to the technical solutions of the present invention by using the methods and technical contents disclosed above without departing from the spirit and scope of the present invention. Therefore, any simple modifications, equivalent changes, and decorations made to the above embodiments based on the technical essence of the present invention without departing from the technical solutions of the present invention shall fall within the protection scope of the technical solutions of the present invention.

[0313] The content not described in detail in the specification of the present invention belongs to the well-known technology of those skilled in the art.

Claims

1. A design verification method for complex equipment based on models and prototypes, characterized in that Including: Define a full-element digital prototype, perform parametric processing and parameter linkage on the definition content of various types of full-element digital prototypes; Construct various types of full-element digital prototypes according to the definition content of the full-element digital prototypes and perform parameter association; Perform encapsulation processing on the full-element digital prototypes after parameter association, and perform cross-domain integration on each encapsulated full-element digital prototype; Perform cross-domain simulation on the full-element digital prototypes after cross-domain integration; Test the full-element digital prototypes with successful simulation runs and release the full-element digital prototypes that pass the tests.

2. A complex equipment design verification method based on models and prototypes according to claim 1, characterized in that: The full-element digital prototype includes a prototype part and a model part. The prototype part includes a structure prototype, a type-I performance prototype, and a type-II performance prototype; the model part includes a function model and a virtual-real test model; The structure prototype is used to describe the parameter information of the geometric structure of the equipment system. The type-I performance prototype is used to describe the interface information and one-dimensional performance of the equipment system in each physical domain or information domain. The type-II performance prototype is used to perform finite element simulation on the mesh model after the structure prototype is divided; The function model is used to describe the framework composition, interface design, and connection relationship of the equipment system; The virtual-real test model collects the test data of the equipment system and generates a data model through an external prototype adapter according to the preset data mapping to output learning data.

3. A complex equipment design verification method based on models and prototypes according to claim 2, characterized in that: The parametric processing method of the full-element digital prototype is as follows: Integrate and set up a global variable pool in the type-I prototype. The preset parameter variables in the global variable pool include independent variables, dependent variables, and fixed variables; The function model reads the independent variables including the instance framework structure parameters from the global variable pool and realizes parameterization according to the settings of the independent variables; The structure prototype realizes parametric expression by reading the fixed variables including CAD files or Step format files or IGES format files from the global variable pool; The type-I performance prototype realizes parametric expression by reading the dependent variables including algorithm models or parameter input values in each physical domain from the global variable pool; The type-II performance prototype realizes parametric expression by receiving a CAE file through external manual driving; The virtual-real test model reads the independent variables including adjustable input variables from the global variable pool and sets the adjustable input variables as the test data of the equipment system to realize parameterization.

4. A complex equipment design verification method based on models and prototypes according to claim 2, characterized in that: The parameter linkage method of the full-element digital prototype is as follows: The instance framework structure parameters output by the function model are input into the type-I performance prototype; the parameter information of the geometric structure of the equipment system output by the structure prototype is input into the type-I performance prototype. At the same time, mesh division and load addition processing are performed according to the corresponding model of the geometric structure of the equipment system and input into the type-II performance prototype; The type-II performance prototype performs simulation processing according to the received information and outputs the spatial response characteristics of each physical domain and inputs them into the type-I performance prototype; The type-I performance prototype receives all the information, performs physical information fusion, records it, and outputs a description file.

5. A method for complex equipment design verification based on models and prototypes according to claim 4, characterized in that: The functional model is developed based on the SysML language, and the development content includes requirement items, functional flows, system architectures, interface designs, and connection relationships of the equipment system; The structural prototype is developed through CAD files, Step format files, or IGES format files, and data type conversion between the structural prototype and the type-I performance prototype is realized according to the requirement items of the equipment system; The type-I performance prototype develops physical domain models through the Modelica language and information domain models through the Julia language, and information interaction and conversion are realized through memory sharing among various models; The type-II performance prototype is developed through various commercial CAE software, and mesh division is performed using the output information of the structural prototype as the input; The virtual-real test model takes the test data of the equipment system as the input, and a virtual-real test model is generated in the prototype adapter through machine learning and data fitting.

6. A method for complex equipment design verification based on models and prototypes according to claim 4, characterized in that: The parameter association of the full-element digital prototype includes automatic association and manual association. The automatic association is automatically realized according to the conversion relationship or parameter linkage method of various prototypes or models; the implementation method of the manual association is: actively associate the parameters describing the same attribute of the equipment system according to the description files output by various prototypes or models.

7. A method for complex equipment design verification based on models and prototypes according to claim 4, characterized in that: The encapsulation process of the full-element digital prototype is realized using the unified modeling language. The interfaces of various prototypes or models are uniformly encapsulated. Before the encapsulation starts, a general-purpose language is selected and the instruction naming rules and instruction types are defined, and the instruction set is determined according to the instruction naming rules for encapsulation.

8. A method for complex equipment design verification based on models and prototypes according to claim 7, characterized in that: The cross-domain integration is realized through GIT; after the full-element digital prototype is defined, the full-element digital prototype is constructed through the ontology model file uploaded by GIT; when constructing the full-element digital prototype, various types of full-element digital prototypes are called by calling the ontology model file, and the submission records are saved; during the cross-domain integration process, version control or switching is performed by recording the version information of the selected model files; among them, the format of the encapsulated model is unified through the external performance prototype unit.

9. A method for complex equipment design verification based on models and prototypes according to claim 7, characterized in that: The cross-domain simulation is realized using the distributed co-simulation protocol DCP. During the operation of the cross-domain simulation, by setting the distributed nodes corresponding to each full-element digital prototype, all the dynamic data of each full-element digital prototype at the current distributed node are read and transmitted through the data transfer interface; after the data interaction at the current distributed node is completed, the simulation time step is advanced to obtain all the dynamic data between each full-element digital prototype at each simulation time step, and the cross-domain simulation is completed.

10. A method for verifying the design of complex equipment based on models and prototypes according to claim 8, characterized in that: The test of the all-element digital prototype is a PMU test. The format of the description file output by the all-element digital prototype that passes the test is detected, and all interface information of the all-element digital prototype that passes the test is called for testing. The usability is judged according to the output interface test data. If both the format detection and the call test are passed, the all-element digital prototype passes the PMU test and meets the release conditions.

Images