A model version automatic conversion method and system for Modelica language

Abstract

The application relates to a model version automatic conversion method and system for a Modelica language, and the method comprises the following steps: in response to receiving a conversion request for a user model dependency, the conversion request comprising version information of model libraries relied on by the user model before and after conversion; loading at least one version conversion script according to the version information of the model libraries relied on by the user model before and after conversion, the at least one version conversion script being used for recording version conversion information when a current version model library relied on by the user model is upgraded to a target version model library; parsing the at least one version conversion script to obtain at least one corresponding version difference mapping table; and converting the dependency of the user model according to the at least one version difference mapping table, so that the converted user model is compatible with the target version model library. The application can automatically convert the dependency of the user model, adapt to a new version model library, and reduce the complexity of manual operation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system modeling and simulation, in particular to a model version automatic conversion method and system for Modelica language. BACKGROUND

[0002] Modelica language is a declarative multi-domain unified modeling language, which is widely used in modeling and simulation of complex physical systems, in other words, the model library based on Modelica semantics can be used by modeling personnel to build user models (i.e. system models), and a dependency relationship will be formed between the user model and the model library.

[0003] However, during the maintenance and upgrading of the model library based on Modelica semantics, some change information will be introduced, and these change information may not be compatible with the old version of the model library, thereby affecting the normal use of the user model. This situation is particularly prominent in the version upgrade of large-scale model libraries, for example, when the Modelica standard library is upgraded from version 3.2.3 to version 4.0, due to the large adjustment of modules and interfaces, many user models dependent on the old version of the model library cannot be directly adapted to the new version of the model library. Similar problems are also very common in the upgrade of other engineering model libraries. SUMMARY

[0004] Based on the above description, the present application provides a model version automatic conversion method and system for Modelica language to solve the problem that the user model is difficult to directly adapt to the new version of the model library during the version upgrade of the model library.

[0005] According to a first aspect of the present application, a model version automatic conversion method for Modelica language is provided, comprising:

[0006] In response to receiving a conversion request for the dependency relationship of the user model, the conversion request includes version information of the model library dependent by the user model before and after conversion;

[0007] According to the version information of the model library dependent by the user model before and after conversion, at least one version conversion script is loaded, and the at least one version conversion script is used to record the version conversion information when the current version of the model library dependent by the user model is upgraded to the target version of the model library;

[0008] The at least one version conversion script is parsed to obtain at least one corresponding version difference mapping table;

[0009] According to the at least one version difference mapping table, the dependency relationship of the user model is converted, so that the converted user model is compatible with the target version of the model library.

[0010] In one or more embodiments, before the response receives the conversion request for the dependency relationship of the user model, further comprising:

[0011] According to the preset conversion rule, a plurality of version conversion scripts are established, and each version conversion script is used to record the change information of the library element when each version model library is upgraded to the next version model library;

[0012] The preset conversion rule includes a type conversion rule, a conditional conversion rule, an element conversion rule, and a variant conversion rule.

[0013] In one or more embodiments, the loading of at least one version conversion script according to the version information of the model library on which the user model depends before and after the conversion comprises:

[0014] If the version of the model library on which the user model depends before the conversion and the version of the model library on which the user model depends after the conversion differ by one version, one corresponding version conversion script is loaded; or

[0015] If the version of the model library on which the user model depends before the conversion and the version of the model library on which the user model depends after the conversion differ by several versions, several corresponding version conversion scripts are loaded.

[0016] In one or more embodiments, the parsing of the at least one version conversion script to obtain at least one corresponding version difference mapping table comprises:

[0017] The conversion rule of each version conversion script is parsed, all version conversion information recorded in the version conversion script is extracted and sorted, and one corresponding version difference mapping table is generated.

[0018] In one or more embodiments, according to the at least one version difference mapping table, the dependency relationship of the user model to the current version model library is converted, so that the converted user model is compatible with the target version model library, comprising:

[0019] According to the at least one version difference mapping table, the dependency relationship of the user model to the current version model library is searched and analyzed to determine the changed dependency item in the user model.

[0020] According to the at least one version difference mapping table and the changed dependency item in the user model, the dependency relationship of the user model is converted.

[0021] In one or more embodiments, according to the at least one version difference mapping table, the dependency relationship of the user model to the current version model library is searched and analyzed to determine the changed dependency item in the user model, comprising:

[0022] traversing all dependencies in the user model, locating the dependencies to be changed in the statements and syntax elements of the user model according to the change information of each library element in the at least one version difference mapping table;

[0023] wherein the statements include import statements, inheritance statements, equation and algorithm statements, and component declarations; and the syntax elements include expressions, annotations, and variants.

[0024] In one or more embodiments, before the searching and analyzing the dependencies of the user model to the current version model library according to the at least one version difference mapping table, the method further comprises:

[0025] analyzing the inheritance relationship of the user model to determine the base class and the derived class having the inheritance relationship;

[0026] locating all derived classes affected by the change in the user model according to the change information of the base class in the at least one version difference mapping table;

[0027] extending the change information of all derived classes affected by the change in the at least one version difference mapping table according to the mechanism of dynamic extension base class conversion rule.

[0028] In one or more embodiments, before the responding to the conversion request of the dependencies of the user model, the method further comprises:

[0029] loading the current version model library relied on by the user model to access all components and dependencies in the current version model library;

[0030] identifying the version information of the model library relied on by the user model, and if the current version model library relied on by the user model is not the target version model library, generating and displaying conversion prompt information to the user interface.

[0031] In one or more embodiments, the method further comprises: generating a conversion log, the conversion log being used to record the operation information performed on the user model in the conversion process of the dependencies of the user model.

[0032] According to a second aspect of the present application, a model version automatic conversion system for Modelica language is provided, comprising:

[0033] a responding module, configured to respond to a conversion request of the dependencies of a user model, the conversion request including the version information of the model library relied on by the user model before and after the conversion;

[0034] The loading script module is configured to load at least one version conversion script according to version information of a model library relied on by the user model before and after conversion, the at least one version conversion script being configured to record version conversion information when a current version model library relied on by the user model is upgraded to a target version model library;

[0035] The parsing script module is configured to parse the at least one version conversion script to obtain at least one corresponding version difference mapping table;

[0036] The version conversion module is configured to convert the dependency relationship of the user model according to the at least one version difference mapping table, so that the converted user model is compatible with the target version model library.

[0037] According to a third aspect of the present application, a computer device is provided, comprising a memory and a processor, the memory storing a computer program, and the processor implementing the steps of the method according to any one of the preceding embodiments when executing the computer program.

[0038] According to a fourth aspect of the present application, a storage medium is provided, storing a computer program, and the computer program implementing the steps of the method according to any one of the preceding embodiments when executed by a processor.

[0039] Compared with the prior art, the technical scheme of the present application has the following beneficial technical effects:

[0040] In the model version automatic conversion method and system for the Modelica language, by responding to the conversion request of the dependency relationship of the user model, at least one version conversion script is loaded and parsed according to version information of a model library relied on by the user model before and after conversion, at least one corresponding version difference mapping table is obtained, and then the dependency relationship of the user model is converted according to the at least one version difference mapping table, so that the converted user model is compatible with the target version model library. In this way, by automatically loading and parsing the version conversion script, and automatically analyzing and modifying the user model according to the parsing result, the dependency relationship of the user model is automatically converted, it is ensured that the user model can adapt to the new version model library and maintain compatibility and consistency, the complexity of manual operation is reduced, and the maintenance efficiency and compatibility of the user model are improved. BRIEF DESCRIPTION OF DRAWINGS

[0041] Figure 1 A flowchart of a model version automatic conversion method for the Modelica language according to an embodiment of the present application is shown;

[0042] Figure 2 A structure diagram of a version conversion script in a specific embodiment of the present application is shown;

[0043] Figure 3This is a flowchart illustrating step S104 in one embodiment of this application;

[0044] Figure 4 This is a schematic diagram illustrating the user model search and analysis in a specific embodiment of this application;

[0045] Figure 5 This is a flowchart illustrating step S104 in another embodiment of this application;

[0046] Figure 6 A schematic diagram illustrating the principle of an automatic model version conversion method for the Modelica language provided in another embodiment of this application;

[0047] Figure 7 A schematic diagram of the automatic model version conversion device for the Modelica language provided in this application embodiment;

[0048] Figure 8 A schematic diagram of the computer device provided in the embodiments of this application. Detailed Implementation

[0049] To facilitate understanding of this application, a more complete description will be provided below with reference to the accompanying drawings, which illustrate embodiments of the present application. However, the present application can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of this application will be thorough and complete.

[0050] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0051] It is understood that, when used herein, the singular forms of “a,” “an,” and “the” may also include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms “comprising,” “including,” or “having,” etc., specify the presence of the stated feature, whole, step, operation, component, part, or combination thereof, but do not preclude the possibility of the presence or addition of one or more other features, wholes, steps, operations, components, parts, or combinations thereof.

[0052] See Figure 1 , Figure 1 The diagram illustrates a flowchart of an automatic model version conversion method for the Modelica language according to an embodiment of this application. The method includes the following steps:

[0053] S101, in response to receiving a conversion request for the dependency relationship of the user model, the conversion request including version information of a model library relied on by the user model before and after conversion;

[0054] S102, loading at least one version conversion script according to the version information of the model library relied on by the user model before and after conversion, the at least one version conversion script being used to record version conversion information when a current version model library relied on by the user model is upgraded to a target version model library;

[0055] S103, parsing the at least one version conversion script to obtain at least one corresponding version difference mapping table;

[0056] S104, converting the dependency relationship of the user model according to the at least one version difference mapping table, so that the converted user model is compatible with the target version model library.

[0057] It should be noted that in the embodiment, the model library can refer to a Modelica standard library, or a model library constructed based on the Modelica language and having a specific application scenario. The model library contains a large number of predefined models for engineering modeling in different fields. A user can construct a system model, i.e., a user model, based on multiple model libraries. In this way, the user model and the multiple model libraries form a dependency relationship. When the user model is loaded, the platform loads the corresponding model libraries, facilitating dynamic simulation analysis of the user model. When the version of any model library relied on by the user model is updated, if the user wants the user model to use the model library of the corresponding new version, the dependency relationship of the user model to the current version model library needs to be converted to make it compatible with the target version model library. The target version model library refers to the new version model library, which can be the latest version model library or the next new version model library. In addition, the model library manages different library elements, proportions, constants, variables, types, expressions, components, etc. through model packages. These library elements can be combined to obtain predefined models, and the model packages are used to organize and manage the predefined models, facilitating reference and reuse of the user model when in use.

[0058] Considering that directly embedding the change logic into the program in the model library version upgrade will cause hard coding problems, limiting the flexibility and expansibility of the system. The change content differs significantly between different categories of model libraries or different versions of the same model library, which may involve multiple adjustments of model attributes, component members, etc. In the embodiment, the change logic is decoupled from the program by using version conversion script driven mode, effectively avoiding the limitations of program hard coding, and realizing flexible adaptation to multiple categories and multiple versions of model libraries.

[0059] The version conversion script refers to a code script recording version conversion information when each version model library is upgraded to a next version model library. The version conversion information refers to change information of a library element. In the embodiment, the model library provider can customize or edit script content according to requirements to support model conversion requirements of a specific field or a specific version, thereby adapting to various application scenarios. In the embodiment, the version difference mapping table is obtained by extracting change information of a library element from the version conversion script.

[0060] In the embodiment, at least one version conversion script is loaded and parsed according to version information of a model library on which a user model depends before and after conversion, to obtain at least one corresponding version difference mapping table, in response to receiving a conversion request for a dependency relationship of the user model. Then, the dependency relationship of the user model is converted according to the at least one version difference mapping table, so that the converted user model is compatible with a target version model library. In this way, the dependency relationship of the user model can be automatically converted, ensuring that the user model can adapt to the new version model library and maintain compatibility and consistency, while effectively improving the precision and efficiency of version conversion and reducing the labor cost and maintenance difficulty of complex model library upgrade.

[0061] In some embodiments, before responding to receiving a conversion request for a dependency relationship of the user model, the method further includes:

[0062] According to a preset conversion rule, a plurality of version conversion scripts are established, each version conversion script being used to record change information of a library element when each version model library is upgraded to a next version model library. The preset conversion rule includes a type conversion rule, a condition conversion rule, an element conversion rule and a variant conversion rule.

[0063] It should be noted that in the embodiment, the change logic is decoupled from the program by using a script-driven manner, effectively avoiding the limitations of program hard coding, and realizing flexible adaptation of multiple categories and multiple versions of model libraries. By abstracting four types of general rules of type conversion, condition conversion, element conversion and variant conversion, the system only needs to define a unified conversion rule, and can flexibly write a version conversion script to adapt to model library upgrade requirements of different categories and versions.

[0064] In the embodiment, the main function of the version conversion script is to record the change information of the library elements in the model library version upgrade and define the core rule set of version conversion. By adopting the standardized format, the version conversion script ensures the accuracy and consistency of the subsequent user model version conversion process, covering type conversion rules, conditional conversion rules, element conversion rules and variant conversion rules to adapt to the different version difference requirements. In the embodiment, the subsequent can automatically modify the user model according to each conversion rule, that is, each conversion rule can be regarded as a conversion command. When building the version conversion script, the conversion script can be customized or edited according to the actual needs, so as to flexibly cope with the conversion requirements of specific fields or model library versions and ensure the flexibility and applicability of conversion. The version conversion information can be recorded in XML, JSON and other formats for subsequent parsing, but the storage format is not limited, which can be freely selected according to the conversion system and scene requirements. In addition, in the embodiment, the version conversion script adopts the naming rule of "model name + old version number + To + new version number", for example, Modelica3.2.3.0To4.0.0.0, to clearly identify the conversion between different versions. This naming method is intuitive and clear, which is convenient for management and retrieval of the version conversion script.

[0065] Referring to Figure 2 , Figure 2 The structure diagram of a version conversion script in the specific embodiment of the application is shown, which contains four groups of version conversion information, and each group of version conversion information contains a conversion rule. In actual application, a group of version conversion information can contain multiple conversion rules.

[0066] Specifically, the type conversion rule: in the model library version upgrade process, the change of the type name of the predefined model in the model library version upgrade process can be recorded according to the type conversion rule. In the user model version conversion process, the type name of the predefined model in the old version model library (that is, the current version model library) can be replaced by the type name of the predefined model in the new version model library (that is, the target version model library) according to the type conversion rule, so as to ensure that the user model can correctly reference the corresponding type in the new version model library.

[0067] For example, as shown in Figure 2 , ConvertClass is used to represent the type conversion rule, that is, the conversion command is type conversion. The type name of the predefined model in the old version model library is recorded by className, and the type change name of the predefined model in the new version model library is recorded by newClassName.

[0068] Conditional Conversion Rules: During model library version upgrades, these rules record conversions under specific conditions. This is applicable when a class in the old model library has multiple corresponding items in the new model library. During user model version conversions, these rules determine the target to be converted based on specific conditions in the user model (such as parameter values). For example, it checks if a parameter is a corresponding value; if so, it performs type conversion on the user model's dependencies to match the corresponding type in the new model library. This can be used for one-to-many type conversions during model library upgrades.

[0069] For example, such as Figure 2 As shown, `ConvertClassIf` represents the conditional conversion rule, meaning the conversion command is a conditional conversion. `className` records the type name of the predefined model in the old version of the model library, `newClassName` records the changed type name of the predefined model in the new version of the model library, `paraName` represents the parameter name, and `paraValue` represents the parameter value. When the value of `paraName` in the sub-model to be converted in the user model equals `paraValue`, the type name of that sub-model in the user model is converted, thus achieving the conditional conversion.

[0070] Element Conversion Rules: During model library version upgrades, these element conversion rules can be used to record changes in component names. During user model version conversions, these rules can be used to detect and replace component names in the old model library, ensuring that all component names in user models conform to the naming standards of the new model library, thus avoiding model errors caused by name mismatches.

[0071] For example, such as Figure 2 As shown, ConvertElement indicates the use of element conversion rules, that is, the conversion command is element conversion, className indicates the type name of the conversion, oldElementName indicates the name of the library element in the old version of the model library, and newElementName indicates the name of the library element in the new version of the model library.

[0072] Variation Conversion Rules: During model library version upgrades, these rules can be used to record adjustments to certain variations. These rules can also be used to detect and replace variations in older model libraries, ensuring compatibility of corresponding variations in user models with the new version, such as changes in units or the addition of missing variations.

[0073] For example, such as Figure 2As shown, ConvertModifiers is used to indicate that the conversion rule is a variant conversion rule, i.e., the conversion command is a variant conversion, className indicates the type name of the component to be converted, oldModifItem indicates the component name in the old version model library, oldModifValue indicates the variant value in the old version model library, newModifItem indicates the component name in the new version model library, newModifValue indicates the variant value in the new version model library, and modifType indicates the variant conversion type, which can be AddModif, AlterModif, or the like.

[0074] When the variant conversion type is AddModif, the variant conversion needs to add or delete a variant item in the user model. That is, when newModifValue is empty, the variant is deleted, and when newModifValue is not empty, the variant is added.

[0075] When oldModifItem is not empty, the variant item in the user model can be replaced with the specified variant. For example, oldModifItem = "A", newModifItem = "B", and newModifValue = "A*100". If "Comp c(A=C);" appears in the user model, the variant conversion is "Comp c(B=C*100);". This conversion operation is suitable for unit conversion and the like.

[0076] When oldModifValue is not empty in the above example and there is no variant of A in the user model, for example, oldModifValue = 10, and the "Comp c;" component statement in the user model is replaced with "Comp c(B=10*100);"

[0077] When the variant conversion type is AlterModif, the variant conversion command takes effect only when the newModifItem variant exists in the user model, and in this case, the newModifItem item in the version conversion script is required to be not empty.

[0078] It can be understood that, Figure 2 The recording method of the version conversion script in the above embodiment is only an example, and as long as the version change information in the model library upgrade can be clearly and accurately indicated, the specific recording form is not limited in the embodiment.

[0079] In some embodiments, at least one version conversion script is loaded according to the version information of the model library relied on by the user model before and after conversion, including:

[0080] If the version of the model library relied on by the user model before conversion and the version of the model library relied on by the user model after conversion are different by one version, a version conversion script corresponding to one version is loaded. Alternatively, if the version of the model library relied on by the user model before conversion and the version of the model library relied on by the user model after conversion are different by several versions, several version conversion scripts corresponding to the several versions are loaded.

[0081] Specifically, each version of the model library can independently have a dedicated version conversion script, thereby flexibly meeting the needs of different model version conversions. In addition, the embodiment supports multiple iterative conversions of the model library. For example, a user can first upgrade a user model relying on a 3.0.0 version model library to a user model relying on a 3.2.0 version model library, and then further upgrade the user model to a 4.0.0 version model library. The entire upgrade process can be completed by loading the corresponding version conversion scripts respectively, without the need for additional adjustments to the conversion logic, thereby improving the efficiency and applicability of version conversion.

[0082] In some embodiments, parsing at least one version conversion script obtains at least one corresponding version difference mapping table, including:

[0083] The conversion rules of each version conversion script are parsed, and all version conversion information recorded in the version conversion script is extracted and sorted to generate one version difference mapping table.

[0084] Specifically, the conversion rules in the version conversion script are read and parsed, and all version conversion information recorded in the version conversion script is extracted and sorted. Each version conversion script generates a version difference mapping table through parsing. These version difference mapping tables help the conversion system to identify the dependency relationship of the user model with the old version model library, and lay a foundation for subsequent automatic conversion operations, provide detailed data support for the subsequent version conversion process, that is, provide a basis for searching. For example, in the process of parsing the version conversion script, when a group of model type name changes is processed, a clear mapping table is generated by marking the correspondence between the old type name and the new type name, which is used for subsequent searching and analyzing the dependency relationship of the user model.

[0085] Referring to Figure 3 , Figure 3 FIG. 4 shows a flowchart of step S104 in the embodiment of the application.

[0086] In some embodiments, according to at least one version difference mapping table, the dependency relationship of the user model with the current version model library is converted, so that the converted user model is compatible with the target version model library, including:

[0087] S301, according to at least one version difference mapping table, find and analyze the dependency relationship of the user model to the current version model library to determine the to-be-changed dependency in the user model;

[0088] S302, according to at least one version difference mapping table and the to-be-changed dependency in the user model, convert the dependency relationship of the user model.

[0089] Specifically, according to the change information of the library elements provided in the version difference mapping table, the dependency relationship of the user model to the old version model library (i.e. the current version model library) is found and analyzed, and the to-be-changed part in the user model, i.e. the to-be-changed dependency, can be quickly and accurately found. According to the change information of the library elements provided in the version difference mapping table and the to-be-changed dependency in the user model, the attributes of the user model are adjusted, the dependencies are replaced, and the structure is modified to ensure that the user model conforms to the semantics of the new version model library (i.e. the target version model library), so that the user model forms a dependency relationship with the new version model library. It should be noted that during the conversion process, the original data of the user model is backed up for comparison and rollback operation to ensure the safety of the version conversion process.

[0090] Referring to Figure 4 , Figure 4 A schematic diagram of finding and analyzing a user model in the specific embodiment of the application is shown.

[0091] In some embodiments, according to at least one version difference mapping table, the dependency relationship of the user model to the current version model library is found and analyzed in step S301 to determine the to-be-changed dependency in the user model, including:

[0092] All dependencies in the user model are traversed, and the to-be-changed dependency is located in the statements and syntax elements of the user model based on the version conversion information in at least one version difference mapping table; wherein the statements include import statements, inheritance statements, equation and algorithm statements, and component declarations; and the syntax elements include expressions, annotations and variants.

[0093] It should be noted that the dependency relationship of the user model to the model library is complex and is embodied by base classes, components, import statements, expressions, etc. In this embodiment, all dependencies in the user model are traversed, and the to-be-changed dependency is located in the statements and syntax elements of the user model based on the change information of the library elements in one or more version difference mapping tables. Wherein the statements include import statements, inheritance statements, component declarations or equation and algorithm statements; and the syntax elements include expressions, annotations or variants.

[0094] In this embodiment, for import statements: the import statements in the user model are parsed, all imported packages and components are identified, multiple import statements are processed, and it is checked whether there is type conversion information that needs to be converted. For example, in the import statement "import Modelica.SIunits.*;", Modelica.SIunits is the type name reference information.

[0095] For inheritance statements: Locate change information in the user model's inheritance statement, including analyzing the base class name and finding change information for variants within the inheritance statement. For example, in the inheritance statement "extends ABC(x=1);", "ABC" is the base class name, and "(x=1)" is the variant information.

[0096] For component declarations: Locate change information in the component definition, including the component type name, component variants, and information in its annotations. For example, in the component declaration "P1.Comp c(y=2);", "P1.Comp" is the component type name, and "(y=2)" is the component variant information.

[0097] For equations and algorithms: Examine the equations and algorithm statements in the user model and analyze the expression change information involved.

[0098] For expressions: Analyze the change information in the expression, including function call names, component reference names, enumerations, function parameters, etc. For example, in the expression "OldLibrary.FunctionName(x)", "OldLibrary.FunctionName" is the function name, and "x" is the component reference name.

[0099] For annotations: Locate changes in the names and expressions within annotations, including inverse functions and derivative function names. For example, the annotation "annotation(derivative=foo1);" contains derivative function information.

[0100] For variants: Analyze the change information in the variants, identify and convert cases such as type redeclaration, component redeclaration, and expressions.

[0101] In this way, by traversing all dependencies in the user model and based on the change information of library elements in at least one version difference mapping table, the elements in the user model that need to be modified or replaced can be identified. This allows for quick and accurate identification of dependencies to be converted within the user model, ensuring compatibility between the user model and the new version of the model library.

[0102] See Figure 5 , Figure 5 A flowchart of step S104 in another embodiment of this application is shown.

[0103] In some embodiments, before step S301, i.e. before finding and analyzing the dependency of the user model on the current version model library according to the at least one version difference mapping table, the method further comprises:

[0104] S501, analyzing the inheritance relationship in the user model to determine the base class and the derived class having the inheritance relationship in the user model;

[0105] S502, locating all the derived classes affected by the change in the user model according to the change information of the base class in the at least one version difference mapping table;

[0106] S503, expanding the change information of all the derived classes affected by the change in the at least one version difference mapping table according to the mechanism of the dynamic expansion of the base class conversion rule.

[0107] It should be noted that due to the complex inheritance relationship in the model library, it is extremely tedious to find and process each dependency in the user model one by one, and important changes are easily missed, especially when it comes to implicit dependency relationships involving derived classes. The traditional way is difficult to handle efficiently. However, due to the complex inheritance relationship, it is more required that the derived class accurately inherits the change information of the base class, which increases the difficulty of recording and maintaining the change information.

[0108] Specifically, by analyzing the inheritance relationship in the user model, it is ensured that the version conversion information in the version difference mapping table is also effective when type inheritance. In this embodiment, the user model will identify the base class and the derived class in the code level. By analyzing the inheritance relationship in the user model, the base class and the derived class having the inheritance relationship in the user model are determined. Further, according to the change information of the library element in the at least one version difference mapping table, all the derived classes affected by the change in the user model are located, and the base class conversion rule is dynamically expanded, in other words, according to the change information of the related base class in the version difference mapping table, the derived class is dynamically expanded.

[0109] In this embodiment, the decoupling of the version conversion script and the handling of the derivation relationship is achieved by using the dynamic extension mechanism of the base class conversion rule. The implicit dependencies in the complex inheritance relationship are handled according to the dynamic extension mechanism of the derivation structure. Specifically, before the dependency relationship of the user model is analyzed, the derivation relationship of the user model is preprocessed, all affected derived classes are automatically identified, and the base class conversion rule is dynamically extended. Through the inheritance relationship analysis, the modification logic of the base class can be accurately applied to the derived class, and the conversion rule of the derived class does not need to be explicitly defined in the version conversion script, which can significantly simplify the writing of the version conversion script. For example, if the version conversion script records the change of the base class BaseClass: x → y, when the derived class DerivedClass is derived from the base class BaseClass in the user model, the system will automatically extend the version difference mapping table generated by the analysis, and when the related dependencies of the user model are modified subsequently, the reference to x in the derived class DerivedClass is correctly updated to y.

[0110] In some embodiments, before responding to the conversion request of the dependency relationship of the user model, further comprising:

[0111] loading the current version model library on which the user model depends to access all components and dependencies in the current version model library; and identifying the version information of the model library on which the user model depends, if the current version model library on which the user model depends is not the target version model library, generating conversion prompt information and displaying it to the user interface.

[0112] Specifically, first, the current version model library on which the user model depends is loaded to ensure that all components and dependencies in the current version model library are accessible for subsequent dependency analysis and conversion operations. Then, the version of the model library on which the user model depends is identified. If the current version model library on which the user model depends is not the target version model library, conversion prompt information is generated to determine whether the user needs to perform version conversion, so as to select a suitable version conversion script for the subsequent steps, facilitate the automatic conversion of the model library version on which the user model depends at the user end, and reduce the complexity of manual conversion.

[0113] Referring to Figure 6 , Figure 6 Fig. 1 shows a schematic diagram of the principle of the model version automatic conversion method for the Modelica language provided by another embodiment of the present application.

[0114] In some embodiments, further comprising: generating a conversion log, the conversion log being used to record the operation information of each operation step performed on the user model in the conversion process of the dependency relationship of the user model.

[0115] Specifically, by recording all operation information in the version conversion process, detailed logs of success and failure are provided to help users quickly locate problems and debug. In this way, the traceability and convenience of the conversion process can be enhanced, and the entire conversion process is more transparent. For example, when the type name of a component in the user model is successfully replaced from the old version to the new version, the specific content of the operation is recorded in detail in the log; when some dependencies cannot be matched or replacement fails, the log generates error information and accurately locates the problem position (such as a specific library element or conversion rule). In addition, the information can be organized in chronological order to facilitate users to intuitively trace the operation process. Through the generated log file, users can not only quickly understand the overall progress of the conversion process, but also can carry out targeted troubleshooting and correction for failed items, thereby improving the debuggability and maintenance efficiency of the system.

[0116] In summary, through the automatic script analysis and data search functions, the conversion system of the embodiment effectively reduces the complexity of manual operation, realizes high-accuracy model conversion, significantly reduces the probability of error occurrence, and ensures the uniform style of model modification. In addition, the flexible version conversion script and data search function enable the system to adapt to different fields and diversified model conversion needs, providing users with extensive application adaptation capabilities. In addition, by outputting the conversion log, users can intuitively and in detail monitor each step in the conversion process, significantly improving the debuggability and ease of use of the system. Compared with traditional methods, the innovation of the present application lies in realizing the full automation of complex Modelica model conversion between different version model libraries, improving the maintenance efficiency and compatibility of user models, and being suitable for large-scale user model version conversion needs.

[0117] Based on the same inventive concept, an embodiment of the present application provides a Modelica language-oriented model version automatic conversion system. The Modelica language-oriented model version automatic conversion system corresponds one-to-one to the Modelica language-oriented model version automatic conversion method in the above-mentioned embodiment. As shown in the Figure 7 The Modelica language-oriented model version automatic conversion system 700 includes a response request module 710, a script loading module 720, a script analysis module 730, and a version conversion module 740. The functions of each functional unit are described in detail as follows:

[0118] The response request module 710 is configured to respond to the conversion request for the dependency relationship of the user model. The conversion request includes version information of the model library relied on by the user model before and after conversion.

[0119] The loading script module 720 is configured to load at least one version conversion script according to version information of the model library relied on by the user model before and after conversion, and the at least one version conversion script is used to record version conversion information when the current version model library relied on by the user model is upgraded to the target version model library.

[0120] The parsing script module 730 is configured to parse the at least one version conversion script to obtain at least one corresponding version difference mapping table.

[0121] The version conversion module 740 is configured to convert the dependency relationship of the user model according to the at least one version difference mapping table, so that the converted user model is compatible with the target version model library.

[0122] In an embodiment, a computer device is provided, which can be a server, and an internal structure diagram of the computer device can be as shown in FIG. 8. Figure 8 The computer device includes a processor, a memory, a network interface and a database connected through a system bus. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for running the operating system and the computer program in the non-volatile storage medium. The database of the computer device is configured to store various version model libraries, various version conversion scripts, version difference mapping tables and the like. The network interface of the computer device is configured to communicate with an external terminal through a network connection. The computer program is executed by the processor to implement the steps of the model version automatic conversion method for the Modelica language in the above embodiments.

[0123] In an embodiment, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program. The computer program is executed by the processor to implement the steps of the model version automatic conversion method for the Modelica language in the above embodiments.

[0124] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when the computer program is executed, the processes of the above-mentioned embodiments of the methods can be included. Any reference to memory, storage, database or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0125] It should be understood that although the flowchart in the accompanying drawings shows the order of the steps in the form of arrows, the execution of the steps does not necessarily follow the order indicated by the arrows. Unless specifically stated in this document, the execution of the steps can follow different orders. In addition, some steps in the flowchart can be composed of multiple sub-steps or multiple stages, which do not need to be completed at the same time, can be executed at different time points, and the order of execution is not necessarily sequential, and even can be executed alternately or in parallel with other steps or sub-steps or stages of other steps. The modules and their components shown in the structural diagram in the accompanying drawings are only schematic frameworks, and these modules can include multiple sub-modules, each of which undertakes different independent functions.

[0126] The above only describes the preferred embodiments of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A model version automatic conversion method for a Modelica language, characterized by, The method comprises the following steps: in response to receiving a conversion request for the dependency relationship of the user model, the conversion request comprising version information of the model library relied on by the user model before and after conversion; loading at least one version conversion script according to the version information of the model library relied on by the user model before and after conversion, the at least one version conversion script being used to record version conversion information when the current version model library relied on by the user model is upgraded to the target version model library; parsing the at least one version conversion script to obtain at least one corresponding version difference mapping table; converting the dependency relationship of the user model according to the at least one version difference mapping table, so that the converted user model is compatible with the target version model library, comprising: analyzing the inheritance relationship of the user model to determine the base class and the derived class having the inheritance relationship; locating all derived classes affected by the change in the user model according to the change information of the base class in the at least one version difference mapping table; extending the change information of all derived classes affected by the change in the at least one version difference mapping table according to the mechanism of dynamic extension of the base class conversion rule; finding and analyzing the dependency relationship of the user model to the current version model library according to the at least one version difference mapping table to determine the dependency item to be changed in the user model; converting the dependency relationship of the user model according to the at least one version difference mapping table and the dependency item to be changed in the user model.

2. The Modelica language-oriented model version automatic conversion method according to claim 1, characterized by, Before the step of responding to receiving a conversion request for the dependency relationship of the user model, the method further comprises the following steps: establishing a plurality of version conversion scripts according to preset conversion rules, each version conversion script being used to record change information of library elements when each version model library is upgraded to the next version model library; wherein the preset conversion rules comprise type conversion rules, conditional conversion rules, element conversion rules and variant conversion rules.

3. The Modelica language-oriented model version automatic conversion method according to claim 1, characterized by, Loading at least one version conversion script according to the version information of the model library relied on by the user model before and after conversion comprises: if the version of the model library relied on by the user model before conversion and the version of the model library relied on by the user model after conversion differ by one version, then loading one corresponding version conversion script; or if the version of the model library relied on by the user model before conversion and the version of the model library relied on by the user model after conversion differ by several versions, then loading several corresponding version conversion scripts.

4. The Modelica language-oriented model version automatic conversion method according to claim 1, characterized by, Parsing the at least one version conversion script to obtain at least one corresponding version difference mapping table comprises: parsing the conversion rules of each version conversion script, extracting and organizing all version conversion information recorded in the version conversion script to generate one corresponding version difference mapping table.

5. The Modelica language-oriented model version automatic conversion method according to any one of claims 1 to 4, characterized in that, Finding and analyzing the dependency relationship of the user model to the current version model library according to the at least one version difference mapping table to determine the dependency item to be changed in the user model comprises: traversing all dependency items in the user model, and locating the dependency item to be changed in the statements and syntax elements of the user model according to the change information of each library element in the at least one version difference mapping table; The statements include import statements, inheritance statements, equation and algorithm statements, and component declarations; and the syntax elements include expressions, annotations, and variants.

6. The Modelica language-oriented model version automatic conversion method according to any one of claims 1-4, characterized in that, Before the response receives the conversion request for the dependency relationship of the user model, further comprising: Loading the current version model library on which the user model depends to access all components and dependencies in the current version model library; Identifying the version information of the model library on which the user model depends, and if the current version model library on which the user model depends is not the target version model library, generating conversion prompt information and displaying it to the user interface.

7. The Modelica language-oriented model version automatic conversion method according to any one of claims 1-4, characterized in that, Further comprising: Generating a conversion log, which is used to record operation information performed on the user model during the conversion process of the dependency relationship of the user model.

8. A model version automatic conversion system for a Modelica language, characterized by, Comprising: A response module for responding to the conversion request for the dependency relationship of the user model, the conversion request including the version information of the model library on which the user model depends before and after conversion; A loading script module for loading at least one version conversion script according to the version information of the model library on which the user model depends before and after conversion, the at least one version conversion script being used to record version conversion information when the current version model library on which the user model depends is upgraded to the target version model library; A script analysis module for analyzing the at least one version conversion script to obtain at least one corresponding version difference mapping table; A version conversion module for converting the dependency relationship of the user model according to the at least one version difference mapping table, so that the converted user model is compatible with the target version model library, comprising: Analyzing the inheritance relationship of the user model to determine the base class and the derived class having the inheritance relationship; According to the change information of the base class in the at least one version difference mapping table, locating all derived classes affected by the change in the user model; According to the at least one version difference mapping table, finding and analyzing the dependency relationship of the user model on the current version model library to determine the dependency item to be changed in the user model; According to the at least one version difference mapping table and the dependency item to be changed in the user model, converting the dependency relationship of the user model. ​

Images