An MBSE intelligent modeling method based on RSBP methodology

Abstract

This invention discloses an MBSE intelligent modeling method based on the RSBP methodology, belonging to the field of system modeling technology. The method includes: acquiring a user-input natural language description and parsing the modeling intent to extract key modeling elements; filling the key modeling elements into a requirement layer structured template to generate requirement layer model data and displaying it; after confirmation, using the requirement layer model data as context, filling a structure layer template to generate structure layer model data; after confirmation, using existing model data as context, filling a behavior layer template to generate behavior layer model data; after confirmation, using all existing model data as context, filling a parameter layer template to generate parameter layer model data; converting the four layers of model data into SysML standard model data according to preset mapping rules, generating the corresponding SysML model diagram. Through layered guidance, context inheritance, and automatic template filling, the method achieves the gradual construction and standardized output from natural language to a formal model.

Description

Technical Field

[0001] This invention relates to the field of system modeling technology, specifically to an MBSE intelligent modeling method based on the RSBP methodology. Background Technology

[0002] Model-based systems engineering (MBSE) uses a standardized system modeling language (SysML) to formally express system requirements, structure, behavior, and parameters, supporting the design and verification of complex systems. In conventional MBSE modeling practices, system engineers need to manually interpret the raw requirements described in natural language, create requirement diagrams, module definition diagrams, activity diagrams, and parameter diagrams in modeling tools, and manually maintain the traceability relationships between elements in different views. This process relies on the modeler's proficiency in the SysML language specification, and when requirements change, simultaneous modifications are required across multiple model views, which is time-consuming and prone to omissions or inconsistencies. Especially for systems with complex dependencies between requirements, structure, behavior, and parameters, relying solely on manual establishment and updating of cross-view relationships can easily lead to information gaps, resulting in broken requirement traceability chains and hindering effective requirement verification and change impact analysis in later stages. Furthermore, the lack of a smooth transition mechanism from natural language descriptions to structured model data often leads to misunderstandings of requirements being directly carried into the model, with early errors only discovered at a later stage, resulting in significant rework costs.

[0003] Regarding the efficiency and consistency of converting informal requirements into formal SysML models, existing technologies mostly focus on model extraction from a single perspective or automated mapping of local steps, failing to establish a closed-loop mechanism across the entire modeling chain that starts with requirements, unfolds layer by layer, and confirms each step. How to enable modeling tools to guide users step-by-step in a structured manner to describe requirements, structure, behavior, and parameters, naturally inheriting confirmed information and automatically populating templates at each step, while simultaneously converting the final structured data into SysML standard model diagrams in batches according to unified rules, is a problem that urgently needs to be solved. Summary of the Invention

[0004] This paper presents an MBSE intelligent modeling method based on RSBP methodology to reduce the conversion threshold from natural language requirements to SysML models, avoid inconsistencies in cross-view information, and achieve controllable progress of the modeling process and automatic generation of model data.

[0005] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides an MBSE intelligent modeling method based on the RSBP methodology, which obtains the natural language description input by the user for the target system, parses the modeling intent and extracts key modeling elements; fills the key modeling elements into the requirement layer structured template, generates requirement layer model data and displays it in the requirement layer view; after receiving confirmation from the user of the requirement layer model data, fills the structure layer structured template with the requirement layer model data as context, generates structure layer model data and displays it in the structure layer view; after receiving confirmation from the user of the structure layer model data, fills the structure layer structured template with the requirement layer model data and ... structured template, generates structure layer model data and displays it in the structure layer view; after receiving confirmation from the user of the structure layer model data, fills the structure layer structured template with the requirement layer model data and the structure layer structured template. The structural layer model data serves as context to populate the behavioral layer structured template, generating behavioral layer model data which is then displayed in the behavioral layer view. After receiving user confirmation of the behavioral layer model data, the requirement layer model data, structural layer model data, and behavioral layer model data are used together as context to populate the parameter layer structured template, generating parameter layer model data which is then displayed in the parameter layer view. The requirement layer model data, structural layer model data, behavioral layer model data, and parameter layer model data are then converted into SysML standard model data according to preset mapping rules, and corresponding requirement diagrams, module definition diagrams, activity diagrams, and parameter diagrams are generated and stored in the modeling tool. Through this layered, progressive, and context-inherited modeling process, even non-professional modelers can quickly construct semantically consistent and traceable system models starting from natural language, significantly lowering the MBSE modeling threshold.

[0006] As a preferred embodiment of the present invention, when acquiring natural language descriptions, guide labels for four modeling levels—demand layer, structure layer, behavior layer, and parameter layer—are displayed on the user interface. The system receives the natural language description input by the user in the input area corresponding to any guide label, determines the current modeling level based on the guide label corresponding to the natural language description, and extracts the element types and attribute values ​​matching the current modeling level from the description as key modeling elements. This allows users to initiate modeling at any level and effectively improves the accuracy of key element extraction.

[0007] Preferably, the requirement layer structured template includes requirement identifier, requirement name, requirement description, requirement priority, and requirement verification method fields, which, after being filled, form a requirement layer structured data package. The structure layer structured template includes module identifier, module name, module type, parent module identifier, and interface definition fields. When filling the structure layer template, the requirement identifier and requirement name are extracted from the requirement layer model data as context indexes, and the module identifier, module name, module type, parent module identifier, and interface definition values ​​matching the structure layer are extracted from key modeling elements and filled accordingly, forming a structure layer structured data package. The behavior layer structured template includes activity identifier, activity name, module identifier, input interface, output interface, and behavior description fields. When filling the behavior layer template, the requirement identifier is extracted from the requirement layer model data, and the module identifier and module name are extracted from the structure layer model data, which together serve as context indexes. The activity identifier, activity name, module identifier, input interface, output interface, and behavior description text are extracted from key modeling elements and filled in. The parameter-layer structured template includes constraint identifier fields, constraint name fields, associated requirement identifier fields, associated module identifier fields, associated activity identifier fields, and parametric equation fields. When populating the parameter-layer template, requirement identifiers and requirement verification methods are extracted from the requirement-layer model data, module identifiers are extracted from the structure-layer model data, and activity identifiers are extracted from the behavior-layer model data. These are used together as context indexes. Corresponding constraint identifier values, constraint name values, associated requirement identifier values, associated module identifier values, associated activity identifier values, and parametric equation text are extracted from key modeling elements and filled in. Through a layered context indexing mechanism, the precise correspondence between requirements, structures, behaviors, and parameters is ensured, and automatic cross-layer data connection is achieved.

[0008] When transforming SysML model data, the process involves iterating through each requirement record in the requirement layer model data, assigning a globally unique SysML identifier to each record, mapping requirement names to the standard name attribute of SysML requirement elements, requirement descriptions to text attributes, requirement priorities to priority attributes, and requirement verification methods to verification method attributes. Derivational and tracing relationships are established based on requirement identifier references to generate a requirement diagram. Similarly, the process involves iterating through each module record in the structure layer model data, mapping each module record to a SysML module definition element to generate a module definition diagram. Likewise, the process involves iterating through each activity record in the behavior layer model data, mapping each activity record to a SysML activity element to generate an activity diagram. Finally, the process involves iterating through each constraint record in the parameter layer model data, mapping each constraint record to a SysML parameter constraint element to generate a parameter diagram. All these model diagrams are stored together within the same MBSE project, ensuring information synchronization across multiple views of the system model (requirements, structure, behavior, and parameters), facilitating subsequent analysis and change impact assessment.

[0009] As a further improvement of the present invention, after generating the parameter layer model data, a model verification step is also included: obtaining the parametric equations corresponding to each constraint record in the parameter layer model data and performing numerical simulation calculations to obtain the simulation result values ​​of each constraint record; obtaining the requirement verification method and requirement index threshold corresponding to the associated requirement identifiers of each constraint record from the requirement layer model data, and comparing the simulation result values ​​with the requirement index thresholds to determine whether each requirement is met; for requirement identifiers determined to be unmet, locating the module identifier associated with the requirement identifier from the structural layer model data, and locating the activity identifier associated with the requirement identifier from the behavioral layer model data, and generating a list of elements to be modified. Preferably, the list of elements to be modified is displayed on the user interface, and the input area of ​​the modeling level corresponding to each element in the list of elements to be modified is activated; receiving the modification description input by the user, and regenerating the updated structural layer model data, updated behavioral layer model data, or updated parameter layer model data according to the modification description; replacing the corresponding original model data with the updated model data, and re-executing the numerical simulation calculation and requirement satisfaction determination until all requirements are determined to be satisfied. This establishes a closed-loop iteration of "modeling-simulation-verification-modification," ensuring that the final multi-level system model is not only structurally correct but also meets all quantitative requirements through simulation verification, significantly improving the quality and efficiency of MBSE-based system design.

[0010] The technical effects and advantages provided by the present invention in the above technical solution are as follows: By dividing the system to be modeled into modeling layers—requirement, structure, behavior, and parameters—the modeling intent is parsed and key modeling elements are extracted after obtaining the user's natural language input. The extracted results are then populated into the requirement layer structured template to generate requirement layer model data. This method maps free text into structured records with fixed fields, eliminating the ambiguity of natural language expression and solidifying requirement information in a unified format with fields such as identifiers, names, descriptions, priorities, and validation methods, providing a clear contextual basis for subsequent modeling layers. After the requirement layer is confirmed, the requirement layer model data is used as context to populate the structure layer structured template to generate structure layer model data. The structure layer template contains fields such as module identifier, module name, module type, parent module identifier, and interface definition. During population, values ​​matching the structure layer are extracted from key modeling elements based on the context index. This mechanism of passing corresponding information down to the lower layers using confirmed upper-layer data as context creates a natural association between structure layer model elements and requirement identifiers and names, eliminating the need for manual traceability links and avoiding the problem of missing or mismatched traceability relationships between requirements and system modules. After the structure layer is confirmed, the behavioral layer model data is generated by populating the structured template using the requirement layer and structure layer model data together as context. The behavioral layer template includes fields such as activity identifier, activity name, module identifier, input / output interface, and behavior description. During population, the requirement identifier, module identifier, and module name are extracted as context indexes, ensuring that each activity element clearly belongs to a specific module and is driven by specific requirements. After the behavioral layer is confirmed, the parameter layer model data is generated by populating the structured template using the complete model data from the requirement layer, structure layer, and behavioral layer as context. The parameter layer template includes fields such as constraint identifier, constraint name, associated requirement identifier, associated module identifier, associated activity identifier, and parametric equation. During population, the corresponding associated identifiers are automatically matched based on the upper-level indexes, ensuring that the multidimensional relationships between parameter constraints and requirements, modules, and activities remain intact. This layered population and confirmation mechanism ensures that the model data maintains semantic consistency between upper and lower layers throughout the construction process, avoiding information silos and missing relationships caused by independently modeling requirements, structure, behavior, and parameters.

[0011] The generated requirement, structure, behavior, and parameter layer model data are converted into SysML standard model data according to preset mapping rules. Each layer's records are traversed, mapping each requirement record to a SysML requirement element and generating a requirement diagram; each module record to a SysML module definition element and generating a module definition diagram; each activity record to a SysML activity element and generating an activity diagram; and each constraint record to a SysML parameter constraint element and generating a parameter diagram. All four types of model diagrams are then stored together within the same MBSE project. This mapping process batch-converts internal structured data into formal model elements conforming to SysML specifications. Simultaneously, by assigning globally unique identifiers to requirement identification fields and establishing derivational traceability relationships, the reference relationships between elements are automatically maintained. Compared to manually creating model elements one by one in modeling tools and manually drawing views, this method significantly reduces the operational steps required to transform textual requirements into a simulateable analysis model. Furthermore, due to the unified mapping rules, each generated result has the same structural standard, eliminating the impact of varying modeling styles on model consistency. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0013] Figure 1 This is a flowchart of the MBSE intelligent modeling method based on the RSBP methodology; Figure 2 This is a flowchart of the conversion and associated storage of multi-level model data to SysML model; Figure 3 This is a flowchart of model data verification and iterative modification. Figure 4 It is a multi-layer feature extraction accuracy curve based on text length; Figure 5 This is a diagram showing the distribution of field lengths in the requirements layer model. Figure 6 It is a curve showing the relationship between the parsing time of the parametric equations in the parameter layer model and the number of parameters; Figure 7 It is a curve showing the change in the number of elements to be modified based on the iterative process of demand satisfaction. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0015] See Figure 1 This invention provides an MBSE intelligent modeling method based on the RSBP methodology. This method acquires natural language descriptions input by the user, sequentially generates model data for the requirement layer, structure layer, behavior layer, and parameter layer, and converts the model data of each layer into SysML standard model data to generate corresponding SysML model diagrams in the modeling tool. After acquiring the natural language description input by the user for the target system, the modeling intent is parsed from the natural language description, and key modeling elements are extracted. These key modeling elements are then filled into the requirement layer structured template to generate requirement layer model data, which is displayed in the requirement layer view. After the user confirms the requirement layer model data, the structure layer structured template is filled using the requirement layer model data as context, generating structure layer model data, which is also displayed in the structure layer view. After the user confirms the structure layer model data, the behavior layer structured template is filled using both the requirement layer model data and the structure layer model data as context, generating behavior layer model data, which is also displayed in the behavior layer view. After the user confirms the behavior layer model data, the parameter layer structured template is populated using the requirement layer model data, structure layer model data, and behavior layer model data as context. This generates the parameter layer model data, which is then displayed in the parameter layer view. After generating the model data for each layer, the requirement layer model data, structure layer model data, behavior layer model data, and parameter layer model data are converted into SysML standard model data according to preset mapping rules, and the corresponding SysML model diagram is generated in the modeling tool.

[0016] Example 1:

[0017] In implementation, the user interface features four modeling level guide labels: a requirements level guide label, a structure level guide label, a behavior level guide label, and a parameter level guide label. Each of these labels corresponds to an independent input area. The input area for the requirements level guide label receives natural language descriptions from the user regarding the requirements level; the input area for the structure level guide label receives natural language descriptions from the user regarding the structure level; the input area for the behavior level guide label receives natural language descriptions from the user regarding the behavior level; and the input area for the parameter level guide label receives natural language descriptions from the user regarding the parameter level. These four modeling level guide labels are presented side-by-side or in a paginated format on the user interface. Users can activate any one of these guide labels and enter text in its corresponding input area.

[0018] In practical implementation, when a user enters a natural language description in the input area corresponding to the requirement layer guide label, the system receives the natural language description from the input area corresponding to the requirement layer guide label and determines the current modeling level as the requirement layer based on the requirement layer guide label. Similarly, when a user enters a natural language description in the input area corresponding to the structure layer guide label, the system receives the natural language description from the input area corresponding to the structure layer guide label and determines the current modeling level as the structure layer. Likewise, when a user enters a natural language description in the input area corresponding to the behavior layer guide label, the system receives the natural language description from the input area corresponding to the behavior layer guide label and determines the current modeling level as the behavior layer. Finally, when a user enters a natural language description in the input area corresponding to the parameter layer guide label, the system receives the natural language description from the input area corresponding to the parameter layer guide label and determines the current modeling level as the parameter layer.

[0019] In practice, after determining the current modeling level, the element types and attribute values ​​matching the current modeling level are extracted from the received natural language description. For the requirement layer, a predefined set of requirement layer element types includes requirement identifier element types, requirement name element types, requirement description element types, requirement priority element types, and requirement verification method element types. Words or numbers corresponding to the requirement identifier element type are identified from the natural language description, and the identification results are used as requirement identifier element attribute values; words or phrases corresponding to the requirement name element type are identified from the natural language description, and the identification results are used as requirement name element attribute values; sentences or paragraphs corresponding to the requirement description element type are identified from the natural language description, and the identification results are used as requirement description element attribute values; level words or numbers corresponding to the requirement priority element type are identified from the natural language description, and the identification results are used as requirement priority element attribute values; method descriptions or keywords corresponding to the requirement verification method element type are identified from the natural language description, and the identification results are used as requirement verification method element attribute values. All extracted element types and their corresponding attribute values ​​together constitute the key modeling elements.

[0020] In practical implementation, for the structural layer, the predefined set of structural layer element types includes module identifier element types, module name element types, module type element types, parent module identifier element types, and interface definition element types. Words or numbers corresponding to the module identifier element type are identified from the natural language description, and the identification results are used as the attribute values ​​of the module identifier element; words corresponding to the module name element type are identified from the natural language description, and the identification results are used as the attribute values ​​of the module name element; category words corresponding to the module type element type are identified from the natural language description, and the identification results are used as the attribute values ​​of the module type element; reference identifiers corresponding to the parent module identifier element type are identified from the natural language description, and the identification results are used as the attribute values ​​of the parent module identifier element; interface names or interface specification descriptions corresponding to the interface definition element types are identified from the natural language description, and the identification results are used as the attribute values ​​of the interface definition element. All the obtained element types and their corresponding attribute values ​​together constitute the key modeling elements.

[0021] In practical implementation, for the behavior layer, a predefined set of behavior layer element types includes activity identifier element types, activity name element types, module identifier element types, input interface element types, output interface element types, and behavior description element types. Words or numbers corresponding to the activity identifier element type are identified from the natural language description, and the identification results are used as the activity identifier element attribute values; words corresponding to the activity name element type are identified from the natural language description, and the identification results are used as the activity name element attribute values; module reference identifiers corresponding to the module identifier element type are identified from the natural language description, and the identification results are used as the module identifier element attribute values; a list of interface names corresponding to the input interface element type is identified from the natural language description, and the identification results are used as the input interface element attribute values; a list of interface names corresponding to the output interface element type is identified from the natural language description, and the identification results are used as the output interface element attribute values; action or process description text corresponding to the behavior description element type is identified from the natural language description, and the identification results are used as the behavior description element attribute values. All the obtained element types and their corresponding element attribute values ​​constitute the key modeling elements.

[0022] In practical implementation, for the parameter layer, a predefined set of parameter layer element types includes constraint identifier element types, constraint name element types, associated requirement identifier element types, associated module identifier element types, associated activity identifier element types, and parametric equation element types. Words or numbers corresponding to constraint identifier element types are identified from the natural language description, and the identification results are used as constraint identifier element attribute values; words corresponding to constraint name element types are identified from the natural language description, and the identification results are used as constraint name element attribute values; requirement reference identifiers corresponding to associated requirement identifier element types are identified from the natural language description, and the identification results are used as associated requirement identifier element attribute values; module reference identifiers corresponding to associated module identifier element types are identified from the natural language description, and the identification results are used as associated module identifier element attribute values; activity reference identifiers corresponding to associated activity identifier element types are identified from the natural language description, and the identification results are used as associated activity identifier element attribute values; mathematical expressions or equation text corresponding to parametric equation element types are identified from the natural language description, and the identification results are used as parametric equation element attribute values. All the obtained element types and their corresponding element attribute values ​​constitute the key modeling elements.

[0023] In practice, the process of identifying attribute values ​​corresponding to each feature type from natural language descriptions is achieved using a predefined set of feature extraction rules. Each feature type is configured with one or more matching patterns, which can include keyword lists, regular expressions, or dependency syntax-based templates. After word segmentation and part-of-speech tagging of the natural language description, the segmented sequence is compared with the matching patterns. When a segmented sequence matches a certain matching pattern, the matched text fragment is used as the feature attribute value for the corresponding feature type. For numerical feature attribute values, regular expressions are used to capture and convert them to a specified format; for textual feature attribute values, the original natural language text fragment is retained. After extraction, all feature types and their attribute values ​​corresponding to the current modeling level are encapsulated into structured key modeling feature data for use in subsequent steps.

[0024] See Figure 4 In the figure, the horizontal axis represents the length of the natural language description text, ranging from 0 to 2000 characters, and the vertical axis represents the accuracy of feature extraction at the corresponding modeling level, expressed as a percentage (%). The legend distinguishes the feature extraction accuracy curves for the four modeling levels: demand layer, structure layer, behavior layer, and parameter layer, represented by solid dotted lines, dashed squares, dotted triangles, and dotted diamonds, respectively.

[0025] As can be seen from the curve trends in the graph, the accuracy of demand layer element extraction is the highest overall with relatively small fluctuations. When the text length exceeds 1000 characters, the accuracy approaches 95% or higher, indicating that the key modeling element extraction method for the demand layer in Embodiment 1 of this invention significantly improves extraction performance with increasing text length and maintains high stability. The accuracy of structure layer element extraction is second, with the curve showing an overall upward trend. Starting from approximately 40% when the text is short, it gradually stabilizes at around 85%, showing that the extraction of elements such as module identifiers and module names corresponding to the structure layer performs well in medium to long texts. The accuracy of behavior layer element extraction ranges from approximately 30% to 85%, indicating that the extraction effect of elements such as activity identifiers and input / output interfaces in the behavior layer improves with increasing text length, but with significant fluctuations. The accuracy of parameter layer element extraction is the lowest and most volatile, with the curve starting from approximately 20% and fluctuating upwards to approximately 75% with increasing text length. This shows that the extraction of complex mathematical expressions and related elements such as constraint identifiers and parametric equations involved in the parameter layer is more difficult, but the system's extraction capability improves with increasing text length.

[0026] Example 2:

[0027] In practice, the requirement layer structured template is stored as a predefined template file in the configuration database of the modeling system. The requirement layer structured template includes fields for requirement identifier, requirement name, requirement description, requirement priority, and requirement verification method. The data type of the requirement identifier field is a variable-length string, the requirement name field is a variable-length string, the requirement description field is long text, the requirement priority field is an enumerated value, and the requirement verification method field is a variable-length string. When the modeling system starts up or performs a requirement layer modeling operation for the first time, it loads the field definitions and their order from the configuration database.

[0028] In specific implementation, the attribute values ​​of the requirement identifier, requirement name, requirement description, requirement priority, and requirement verification method elements corresponding to the requirement layer are obtained from the key modeling elements generated in Example 1. The key modeling elements generated in Example 1 contain element types and attribute values ​​that have been categorized and labeled. The requirement identifier attribute value corresponds to the requirement identifier field, the requirement name attribute value corresponds to the requirement name field, the requirement description attribute value corresponds to the requirement description field, the requirement priority attribute value corresponds to the requirement priority field, and the requirement verification method attribute value corresponds to the requirement verification method field. The requirement identifier attribute value is used as the requirement identifier value, the requirement name attribute value is used as the requirement name value, the requirement description attribute value is used as the requirement description text, the requirement priority attribute value is used as the requirement priority value, and the requirement verification method attribute value is used as the requirement verification method value.

[0029] In practice, during the population operation, the modeling system creates a demand-layer structured data package. This package is a collection of key-value pairs, where the keys are field names from the demand-layer structured template, and the values ​​are the corresponding feature values. The demand identifier value is entered into the field named "Demand Identifier" within the demand-layer structured data package; the demand name value is entered into the field named "Demand Name" within the demand-layer structured data package; the demand description text is entered into the field named "Demand Description" within the demand-layer structured data package; the demand priority value is entered into the field named "Demand Priority" within the demand-layer structured data package; and the demand verification method value is entered into the field named "Demand Verification Method" within the demand-layer structured data package. After population, the demand-layer structured data package becomes the demand-layer model data, which the modeling system displays in the demand-layer view. The demand-layer view displays the values ​​of the demand identifier, demand name, demand description, demand priority, and demand verification method fields in a table or card format. Users can view and edit the demand-layer model data in the demand-layer view.

[0030] In practice, users confirm the requirements layer model data by clicking the confirmation button on the user interface. Upon receiving the confirmation, the modeling system locks the values ​​of each field in the requirements layer model data and marks the current requirements layer model data as confirmed. Subsequently, the modeling system extracts the value of the requirement identifier field from the confirmed requirements layer model data as the requirement identifier, and extracts the value of the requirement name field as the requirement name. The requirement identifier and requirement name are combined into a context index. The context index data structure consists of key-value pairs containing a requirement identifier key and a requirement name key, where the value of the requirement identifier key is the value of the requirement identifier field, and the value of the requirement name key is the value of the requirement name field.

[0031] In practice, the modeling system obtains a predefined structured template for the structural layer. This template, also stored as a predefined template file in the configuration database, includes fields for module identifier, module name, module type, parent module identifier, and interface definition. The module identifier and module name fields are both variable-length strings; the module type field is an enumerated value; the parent module identifier field is a nullable variable-length string; and the interface definition field is long text. The modeling system loads the field definitions and their order from the configuration database.

[0032] In practical implementation, attribute values ​​matching the structural layer are extracted from key modeling elements based on the context index. The key modeling elements, generated in Example 1, already include all extracted element types and attribute values ​​from the requirement layer, structural layer, behavior layer, and parameter layer. The modeling system uses the requirement identifier and requirement name from the context index as filtering conditions to locate elements belonging to the structural layer within the key modeling elements. Structural layer elements include module identifier element type, module name element type, module type element type, parent module identifier element type, and interface definition element type. The module identifier element attribute value is obtained from the key modeling elements as the module identifier value; the module name element attribute value is obtained as the module name value; the module type element attribute value is obtained as the module type value; the parent module identifier element attribute value is obtained as the parent module identifier value; and the interface definition element attribute value is obtained as the interface definition value.

[0033] In practice, when performing the structure layer population operation, the modeling system creates a structure layer structured data package. This package is a collection of key-value pairs, where the keys are field names from the structure layer structured template, and the values ​​are the corresponding feature values. The module identifier value is entered into the field named "Module Identifier" in the structure layer structured data package; the module name value is entered into the field named "Module Name" in the structure layer structured data package; the module type value is entered into the field named "Module Type" in the structure layer structured data package; the parent module identifier value is entered into the field named "Parent Module Identifier" in the structure layer structured data package; and the interface definition value is entered into the field named "Interface Definition" in the structure layer structured data package. After population, the structure layer structured data package becomes the structure layer model data, which the modeling system displays in the structure layer view. The structure layer view displays the values ​​of the module identifier field, module name field, module type field, parent module identifier field, and interface definition field in a hierarchical tree list or graphical format. Users can view the structure layer model data in the structure layer view.

[0034] See Figure 5 In the figure, the vertical axis represents probability density, and the horizontal axis represents field length (number of characters). The legend identifies four curves corresponding to the requirement identifier field, requirement name field, requirement description field, and requirement verification method field in the requirement layer model data, respectively. This figure reflects the field length distribution characteristics of each field in the requirement layer structured template in Example 2.

[0035] Specifically, the probability density curve for the requirement identifier field exhibits a concentrated and sharp peak, located at approximately 20 characters in length. This indicates that most requirement identifier fields have relatively short and concentrated data lengths, consistent with the unique identifier characteristic of the same requirement identifier. The probability density curve for the requirement name field peaks at approximately 40 characters in length, and its height is lower than that of the requirement identifier field. This suggests that the requirement name field is slightly longer and more concentrated in length than the requirement identifier field, meeting the requirement requirement name requirement of being concise and rich in key information. The peak of the requirement verification method field curve is located at approximately 30 characters in length, with a sharp peak, indicating that the requirement verification method field has a relatively fixed length, consistent with the characteristics of enumerated value data type processing. The overall probability density of the requirement description field curve is lower than that of other fields and exhibits a right-skewed long-tail distribution, indicating that there are significant length differences in the requirement description field, with some fields significantly exceeding 100 characters in length. This reflects that the requirement description field, as a long text field, can support rich and detailed requirement specifications, consistent with the definition of the requirement description field data type as long text in Example 2.

[0036] Example 3:

[0037] In practice, users confirm the structural layer model data through the user interface by clicking the confirm button in the structural layer view. Upon receiving the confirmation, the modeling system locks the values ​​of each field in the structural layer model data and marks the current structural layer model data as confirmed. Subsequently, the modeling system extracts the value of the requirement identifier field from the confirmed requirement layer model data as the requirement identifier, which is the string stored in the requirement identifier field of the requirement layer model data. Simultaneously, the modeling system extracts the value of the module identifier field from the confirmed structural layer model data as the module identifier, and extracts the value of the module name field as the module name. The module identifier and module name are the strings stored in the module identifier field of the structural layer model data. The extracted requirement identifier, module identifier, and module name are combined together as a context index. The context index data structure is a set of key-value pairs containing a requirement identifier key, a module identifier key, and a module name key. The value of the requirement identifier key is the value of the requirement identifier field in the requirement layer model data, the value of the module identifier key is the value of the module identifier field in the structure layer model data, and the value of the module name key is the value of the module name field in the structure layer model data.

[0038] In implementation, the modeling system obtains a predefined behavioral layer structured template. This template is stored in the configuration database as a predefined template file and includes fields for activity identifier, activity name, module identifier, input interface, output interface, and behavior description. The data types for the activity identifier, activity name, module identifier, input interface, output interface, and behavior description fields are all variable-length strings. The modeling system loads the field definitions and their order from the configuration database.

[0039] In practical implementation, attribute values ​​matching the behavior layer are extracted from key modeling elements based on the context index. Key modeling elements, generated in Example 1, contain all extracted element types and attribute values ​​from the requirement layer, structure layer, behavior layer, and parameter layer. The modeling system uses the requirement identifier, module identifier, and module name from the context index as filtering conditions to locate elements belonging to the behavior layer within the key modeling elements. Behavior layer elements include activity identifier element type, activity name element type, module identifier element type, input interface element type, output interface element type, and behavior description element type. The activity identifier element attribute value is obtained from the key modeling elements as the activity identifier value; the activity name element attribute value is obtained as the activity name value; the module identifier element attribute value is obtained as the module identifier value; the input interface element attribute value is obtained as the input interface value; the output interface element attribute value is obtained as the output interface value; and the behavior description element attribute value is obtained as the behavior description text.

[0040] In practice, when performing the behavior layer population operation, the modeling system creates a behavior layer structured data package. This package is a collection of key-value pairs, where the keys are field names from the behavior layer structured template, and the values ​​are the corresponding feature values. The activity identifier value is entered into the field named "Activity Identifier" within the behavior layer structured data package; the activity name value is entered into the field named "Activity Name" within the behavior layer structured data package; the module identifier value is entered into the field named "Module Identifier" within the behavior layer structured data package; the input interface value is entered into the field named "Input Interface" within the behavior layer structured data package; the output interface value is entered into the field named "Output Interface" within the behavior layer structured data package; and the behavior description text is entered into the field named "Behavior Description" within the behavior layer structured data package. After population, the behavior layer structured data package becomes the behavior layer model data, which the modeling system displays in the behavior layer view. The behavior layer view displays the values ​​of the activity identifier field, activity name field, module identifier field, input interface field, output interface field, and behavior description field in the form of a flowchart or a list of activity nodes. Users can view the behavior layer model data in the behavior layer view.

[0041] In practice, users confirm the behavior layer model data by clicking the confirmation button in the behavior layer view. Upon detecting the confirmation, the modeling system locks the values ​​of each field in the behavior layer model data and marks the current behavior layer model data as confirmed. Subsequently, the modeling system extracts the value of the requirement identifier field from the confirmed requirement layer model data as the requirement identifier, and extracts the value of the requirement verification method field as the requirement verification method. The requirement identifier is a string stored in the requirement identifier field of the requirement layer model data, and the requirement verification method is a string stored in the requirement verification method field of the requirement layer model data. Simultaneously, the modeling system extracts the value of the module identifier field from the confirmed structure layer model data as the module identifier, which is a string stored in the module identifier field of the structure layer model data. The modeling system also extracts the value of the activity identifier field from the confirmed behavior layer model data as the activity identifier, which is a string stored in the activity identifier field of the behavior layer model data. The extracted requirement identifier, requirement verification method, module identifier, and activity identifier are combined together as a context index. The context index data structure is a set of key-value pairs containing a requirement identifier key, a requirement verification method key, a module identifier key, and an activity identifier key. The value of the requirement identifier key is the value of the requirement identifier field in the requirement layer model data, the value of the requirement verification method key is the value of the requirement verification method field in the requirement layer model data, the value of the module identifier key is the value of the module identifier field in the structure layer model data, and the value of the activity identifier key is the value of the activity identifier field in the behavior layer model data.

[0042] In practice, the modeling system obtains a predefined parameter-layer structured template. This template is stored in the configuration database as a predefined template file and includes constraint identifier fields, constraint name fields, associated requirement identifier fields, associated module identifier fields, associated activity identifier fields, and parametric equation fields. The constraint identifier field, constraint name field, associated requirement identifier field, associated module identifier field, associated activity identifier field, and parametric equation field are all variable-length string data types. The parametric equation field is a long text data type. The modeling system loads the field definitions and their order from the configuration database.

[0043] In practical implementation, attribute values ​​matching the parameter layer are extracted from key modeling elements based on the context index. The modeling system uses requirement identifiers, requirement verification methods, module identifiers, and activity identifiers from the context index as filtering conditions to locate elements belonging to the parameter layer among the key modeling elements. Parameter layer elements include constraint identifier element types, constraint name element types, associated requirement identifier element types, associated module identifier element types, associated activity identifier element types, and parametric equation element types. The system retrieves constraint identifier element attribute values ​​as constraint identifier values, constraint name element attribute values ​​as constraint name values, associated requirement identifier element attribute values ​​as associated requirement identifier values, associated module identifier element attribute values ​​as associated module identifier values, associated activity identifier element attribute values ​​as associated activity identifier values, and parametric equation element attribute values ​​as parametric equation text from the key modeling elements.

[0044] In practice, when performing the parameter layer population operation, the modeling system creates a parameter layer structured data package. This package is a collection of key-value pairs, where the keys are field names from the parameter layer structured template, and the values ​​are the corresponding feature values. Constraint identifier values ​​are entered into the field named "Constraint Identifier" in the parameter layer structured data package; constraint name values ​​are entered into the field named "Constraint Name" in the parameter layer structured data package; association requirement identifier values ​​are entered into the field named "Association Requirement Identifier" in the parameter layer structured data package; association module identifier values ​​are entered into the field named "Association Module Identifier" in the parameter layer structured data package; association activity identifier values ​​are entered into the field named "Association Activity Identifier" in the parameter layer structured data package; and parametric equation text is entered into the field named "Parallel Equation" in the parameter layer structured data package. After population, the parameter layer structured data package becomes the parameter layer model data, and the modeling system displays the parameter layer model data in the parameter layer view. The parameter layer view displays the values ​​of the constraint identifier field, constraint name field, associated requirement identifier field, associated module identifier field, associated activity identifier field, and parametric equation field in the form of a constraint list or parameter relationship diagram. Users can view the parameter layer model data in the parameter layer view.

[0045] See Figure 6 In the graph, the horizontal axis represents the number of parameters m, ranging from 1 to 50; the vertical axis represents the parsing time in milliseconds (ms), ranging from 0 to approximately 320 ms. The legend distinguishes four different module types: Module Type_1 (solid blue line with dots), Module Type_2 (dashed orange line with squares), Module Type_3 (dotted green line with triangles), and Module Type_4 (dotted red line with diamonds).

[0046] As the number of parameters *m* increases, the parsing time for all four module types exhibits a non-linear upward trend. Specifically, module type _1 has the lowest parsing time, starting at approximately 0 ms and reaching about 75 ms at m=50, with a smooth curve and a relatively gentle increase. Module type _2 is next, also starting close to 0 ms, with a parsing time of approximately 140 ms at m=50, and its curve is steeper than that of module type _1. Module type _3 ranks third, with its parsing time rapidly increasing with *m*, reaching approximately 210 ms at m=50, and its curve showing an accelerating upward trend. Module type _4 has the highest parsing time, with its curve showing a significant non-linear accelerating growth, reaching approximately 310 ms at m=50, a growth rate far exceeding that of the other module types.

[0047] Example 4:

[0048] In specific implementation, please refer to Figure 2 The requirement layer model data, structure layer model data, behavior layer model data, and parameter layer model data have all been generated and stored in the temporary data area of ​​the modeling system in the form of structured data packets. The modeling system loads preset mapping rules, which are stored in the configuration database in the form of mapping configuration files. The preset mapping rules define the mapping entries from each field in the requirement layer model data to each attribute of the SysML requirement element, from each field in the structure layer model data to each attribute of the SysML module definition element, from each field in the behavior layer model data to each attribute of the SysML activity element, and from each field in the parameter layer model data to each attribute of the SysML parameter constraint element. The modeling system performs transformation operations on the requirement layer model data, structure layer model data, behavior layer model data, and parameter layer model data in sequence according to the preset mapping rules.

[0049] In practice, the modeling system iterates through each requirement record in the requirement layer model data. The requirement layer model data consists of several requirement records, each containing a requirement identifier field, a requirement name field, a requirement description field, a requirement priority field, and a requirement verification method field. The modeling system assigns a SysML globally unique identifier to the requirement identifier field of the currently iterated requirement record. The SysML globally unique identifier is generated by concatenating a fixed prefix string with a universally unique identifier. The fixed prefix string is set to "SYSML_REQ_", and the universally unique identifier is generated using the UUID version 4 algorithm, ensuring that the SysML globally unique identifier is not repeated throughout the entire MBSE project. The generated SysML globally unique identifier is then assigned to the identifier attribute of the SysML requirement element.

[0050] In practice, the modeling system maps the value of the "Requirement Name" field in the current requirement record to the standard name attribute of the SysML requirement element. The standard name attribute is one of the core attributes of a SysML requirement element, used to display the name of the requirement element in the requirement diagram. The system maps the value of the "Requirement Description" field in the current requirement record to the text attribute of the SysML requirement element; the text attribute stores detailed textual descriptions of the requirement. The system maps the value of the "Requirement Priority" field in the current requirement record to the priority attribute of the SysML requirement element; the priority attribute indicates the priority level of the requirement in the requirement diagram, and its value is one of three enumerated values: high, medium, and low. The mapping is performed based on the matching relationship between the value of the requirement priority field and the enumerated values. The system maps the value of the "Requirement Verification Method" field in the current requirement record to the verification method attribute of the SysML requirement element; the verification method attribute records the description of the requirement's verification method.

[0051] In implementation, the modeling system establishes derivational relationships between SysML requirement elements based on the requirement identifier references between requirement records. These requirement identifier references are determined by analyzing the requirement description field or other related fields in the requirement layer model data. The requirement description field may contain reference text to another requirement identifier. The modeling system uses string matching to search the requirement description field of each requirement record for the value of the SysML globally unique identifier or the original requirement identifier field of other requirement records. When a match is found, a derivational relationship is established between the corresponding SysML requirement element in the requirement record and the referenced SysML requirement element. This derivational relationship is implemented by adding a derivational connection line between SysML requirement elements. The type of the derivational connection line is set to "deriveReqt". The source end of the derivational connection line is the SysML requirement element containing the reference text, and the target end is the referenced SysML requirement element.

[0052] In practice, the modeling system generates a requirement diagram by arranging all SysML requirement elements according to their relationships. The arrangement operation is performed using a hierarchical automatic layout algorithm, whose input consists of all SysML requirement elements and the set of derivation relationship lines between them. The hierarchical automatic layout algorithm calculates the coordinate positions of the SysML requirement elements on the canvas using the following formula:

[0053] in, This represents the x-coordinate of the current SysML element on the canvas, in pixels. This represents the horizontal coordinate value of the left margin of the canvas, set to a fixed value of 80 pixels. This indicates the total number of levels in the requirement relationship hierarchy of the current SysML requirement element. The level numbering starts from the root node, with the root node having a level number of 1, and increments by each level. This represents the total width factor of all SysML requirement elements in the h-th layer. The calculation method is to multiply the total number of SysML requirement elements in the h-th layer by the predefined width value of a single SysML requirement element, where the predefined width value of a single SysML requirement element is 200 pixels. This represents the interlayer spacing coefficient of the h-th layer. The value range is from 1.2 to 1.8. When the number of SysML required elements in the h-th layer is greater than 5... The value is 1.8, when the number of SysML required elements in the h-th layer is greater than 2 and less than or equal to 5. The value is 1.5, when the number of SysML required elements in the h-th layer is less than or equal to 2. The value is 1.2. The vertical axis is calculated by multiplying the hierarchy depth of the SysML requirement elements by a fixed vertical spacing value of 120 pixels. After the arrangement is complete, the modeling system saves the coordinate data of all SysML requirement elements and their derived relationship lines on the canvas as a requirement diagram file, which is stored in the SysML standard format.

[0054] In practice, the modeling system traverses each module record in the structural layer model data. The structural layer model data consists of several module records, each containing a module identifier field, a module name field, a module type field, a parent module identifier field, and an interface definition field. The modeling system maps the current module record to a SysML module definition element. Each SysML module definition element contains a name attribute, a type attribute, and an interface attribute. The system maps the value of the module name field in the current module record to the name attribute of the SysML module definition element; the value of the module type field in the current module record to the type attribute of the SysML module definition element; the value of the interface definition field in the current module record is parsed and mapped to the interface attribute list of the SysML module definition element; and based on the matching relationship between the parent module identifier field in the current module record and the module identifier fields of other module records, it establishes a combination association between SysML module definition elements. Finally, all SysML module definition elements are arranged to generate a module definition graph.

[0055] In practice, the modeling system traverses each activity record in the behavior layer model data. The behavior layer model data consists of several activity records, each containing an activity identifier field, an activity name field, a module identifier field, an input interface field, an output interface field, and a behavior description field. The modeling system maps the current activity record to a SysML activity element. A SysML activity element contains a name attribute, a module attribute, an input pin attribute, an output pin attribute, and a behavior description attribute. Specifically, the system maps the value of the activity name field in the current activity record to the name attribute of the SysML activity element; the value of the module identifier field in the current activity record to the module attribute of the SysML activity element; the value of the input interface field in the current activity record is parsed and mapped to the input pin attribute list of the SysML activity element; the value of the output interface field in the current activity record is parsed and mapped to the output pin attribute list of the SysML activity element; and the value of the behavior description field in the current activity record is mapped to the behavior description attribute of the SysML activity element. Based on the matching relationship between the input and output interfaces of the activity records, control flow or object flow connections are established between SysML activity elements. The activity graph is generated by arranging all SysML activity elements.

[0056] In practice, the modeling system iterates through each constraint record in the parameter layer model data. The parameter layer model data consists of several constraint records, each containing a constraint identifier field, a constraint name field, an associated requirement identifier field, an associated module identifier field, an associated activity identifier field, and a parametric equation field. The modeling system maps the current constraint record to SysML parametric constraint elements. Each SysML parametric constraint element contains a name attribute, a constraint expression attribute, and an associated element list attribute. The system maps the value of the constraint name field in the current constraint record to the name attribute of the SysML parametric constraint element; it maps the value of the parametric equation field in the current constraint record to the constraint expression attribute of the SysML parametric constraint element; it adds the values ​​of the associated requirement identifier field, associated module identifier field, and associated activity identifier field in the current constraint record to the associated element list attribute of the SysML parametric constraint element, and establishes binding connections between the SysML parametric constraint element and the corresponding SysML requirement element, SysML module definition element, and SysML activity element. Finally, it generates a parameter graph after arranging all SysML parametric constraint elements.

[0057] Example 5:

[0058] In specific implementation, please refer to Figure 3After the parameter layer model data is generated, the modeling system enters the verification step. The modeling system reads constraint records one by one from the parameter layer model data. Each constraint record contains a constraint identifier field, a constraint name field, an associated requirement identifier field, an associated module identifier field, an associated activity identifier field, and a parametric equation field. For the current constraint record, the modeling system retrieves the parametric equation text from the parametric equation field. The parametric equation text is a mathematical expression stored as a string, containing variable symbols, operators, and constant values. The modeling system parses the parametric equation text into an executable numerical computation expression tree. The parsing process includes two stages: lexical analysis and syntax analysis. In the lexical analysis stage, the parametric equation text is split into operand units and operator units. Operand units contain variable symbols and constant values, while operator units contain arithmetic operators and relational operators. In the syntax analysis stage, the operand units and operator units are constructed into an expression tree according to operator precedence. The leaf nodes of the expression tree are operand units, and the internal nodes are operator units.

[0059] In practice, the modeling system obtains the current estimated value of each variable symbol in the parametric equations. The current estimated value of the variable symbol is read from a predefined set of initial parameter values ​​in the structural layer model data or behavioral layer model data. This set of initial parameter values ​​is stored as an additional attribute when the structural layer model data or behavioral layer model data is generated. For variables whose corresponding symbols do not exist in the initial parameter value set, the modeling system prompts the user to manually input the estimated value of the variable symbol through the parameter layer view. After obtaining the estimated values ​​of all variable symbols, the modeling system substitutes the estimated values ​​into the expression tree and performs numerical calculations from the leaf nodes upwards to obtain the simulation result value of the current constraint record. The numerical calculations follow the operational rules defined in the operator units of the expression tree. Arithmetic operators include addition, subtraction, multiplication, and division; relational operators include equal to, greater than, less than, greater than or equal to, and less than or equal to. The results of relational operators are converted into numerical representations: the result is 1 when the relation is true and 0 when the relation is false.

[0060] In practice, the modeling system retrieves the requirement verification method and requirement index threshold corresponding to the associated requirement identifier of the current constraint record from the requirement layer model data. Using the value of the associated requirement identifier field in the current constraint record as the lookup key, the system iterates through the requirement identifier fields of each requirement record in the requirement layer model data, locating the requirement record whose value matches the value of the associated requirement identifier field. From the located requirement record, the system reads the value of the requirement verification method field as the requirement verification method and retrieves the requirement index threshold. The requirement index threshold is stored in the extended attributes of the requirement record. These extended attributes are extracted from the auxiliary attributes of key modeling elements during the generation of the requirement layer model data. The data type of the requirement index threshold is numeric, including one or more of the following: target value, upper limit value, and lower limit value.

[0061] In practice, the modeling system compares the simulation result values ​​with the requirement index thresholds to determine whether the requirement corresponding to each requirement identifier is met. The comparison and determination logic employs different rules depending on the requirement verification method. When the requirement verification method is "equal to," if the simulation result value equals the target value, the requirement is considered met; otherwise, it is considered unmet. When the requirement verification method is "greater than," if the simulation result value is greater than the lower limit, the requirement is considered met; otherwise, it is considered unmet. When the requirement verification method is "less than," if the simulation result value is less than the upper limit, the requirement is considered met; otherwise, it is considered unmet. When the requirement verification method is "range," if the simulation result value is greater than or equal to the lower limit and less than or equal to the upper limit, the requirement is considered met; otherwise, it is considered unmet. The modeling system generates a determination result record for each constraint record. The determination result record includes the value of the constraint identifier field, the value of the associated requirement identifier field, the simulation result value, the requirement index threshold, and the satisfaction status indicator. The status flag is a Boolean type. A true value indicates that the requirement has been met, while a false value indicates that the requirement has not been met.

[0062] In practice, the modeling system collects all judgment result records where the state identifier is false and processes each record. The system reads the value of the associated requirement identifier field from the current judgment result record and uses this value as the lookup key to retrieve module records containing that associated requirement identifier field value in the structural layer model data. During parameter layer model data generation, the associated module identifier field of each constraint record stores the module identifier associated with the constraint record. The modeling system searches for module records in the structural layer model data whose module identifier field value matches the associated module identifier field value. After locating the target module record, it extracts the module identifier field value from the target module record. Simultaneously, the modeling system uses the associated requirement identifier field value as the lookup key to retrieve activity records containing that associated requirement identifier field value in the behavioral layer model data. During parameter layer model data generation, the associated activity identifier field of each constraint record stores the activity identifier associated with the constraint record. The modeling system searches for activity records in the behavioral layer model data whose activity identifier field value matches the associated activity identifier field value. After locating the target activity record, it extracts the activity identifier field value from the target activity record. The modeling system combines the extracted values ​​of the module identifier field and activity identifier field with the values ​​of the constraint identifier field and associated requirement identifier field from the judgment result record into a single entry for an element to be modified. All entries for modification are then aggregated to generate a list of elements to be modified.

[0063] In practical implementation, the calculation of simulation results involves the mapping relationship between the variable signs in the parametric equations and the parameter values ​​in the structural layer model data or behavioral layer model data. The parametric equations are expressed in the following general form:

[0064] in, This represents a multivariate functional relationship defined by the parametric equation field in the parameter layer model data. The specific operations of the multivariate functional relationship are determined by the operator sequence in the parametric equation field. Indicates the first associated parameter. The value is obtained from the interface definition field of the module record corresponding to the associated module identifier field of the constraint record in the structural layer model data. The unit is determined based on the physical dimensions defined in the interface definition field of the module record; Indicates the second correlation parameter. The value is obtained from the input interface field or output interface field of the activity record corresponding to the associated activity identifier field of the constraint record in the behavior layer model data. The unit is determined based on the physical dimensions defined in the input or output interface fields of the activity record; This represents the total number of associated parameters in the parametric equation. The value of is equal to the total number of variable symbols appearing in the parametric equation field of the constraint record; Represents relational operators, whose values ​​can be one of equal to, greater than, less than, greater than or equal to, or less than or equal to. The specific sign of the relational operator is determined by the verification method specified in the parametric equation field. This represents a threshold constant for the demand indicator. The value is read from the demand indicator threshold of the corresponding demand record in the demand layer model data. Units and The units of the function calculation results should be consistent.

[0065] In practice, after generating a list of elements to be modified, the modeling system displays this list on the user interface. The list is presented in tabular form, with each row corresponding to one element entry. The table columns include constraint identifiers, associated requirement identifiers, module identifiers, activity identifiers, and reasons for non-compliance. The constraint identifier column displays the values ​​of the constraint identifier fields in the element entry; the associated requirement identifier column displays the values ​​of the associated requirement identifier fields; the module identifier column displays the values ​​of the module identifier fields located in the structural layer model data; the activity identifier column displays the values ​​of the activity identifier fields located in the behavioral layer model data; and the reasons for non-compliance column displays details of the comparison between the simulation result values ​​and the requirement threshold values. Simultaneously, the modeling system activates the corresponding input areas on the user interface based on the values ​​of the module identifier and activity identifier columns in the element entry. When an element entry contains a value from the module identifier column and the module identifier value is not empty, the modeling system activates the input area corresponding to the structural layer guide label; when an element entry contains a value from the activity identifier column and the activity identifier value is not empty, the modeling system activates the input area corresponding to the behavioral layer guide label. The activation operation switches the corresponding input area from a disabled state to an editable state and pre-populates the field content of the current corresponding model data in the input area.

[0066] In practice, the user enters a modification description in the activated input area. The modification description is a change description of the module, activity, or constraint entered by the user in natural language text form. After receiving the modification description, the modeling system re-executes the key modeling element extraction operation matching the corresponding modeling level, extracting the updated element types and element attribute values ​​from the modification description. The extraction method is consistent with the element extraction method described in Example 1. For the structure layer, it extracts the attribute values ​​of module identifier element type, module name element type, module type element type, parent module identifier element type, and interface definition element type. For the behavior layer, it extracts the attribute values ​​of activity identifier element type, activity name element type, belonging module identifier element type, input interface element type, output interface element type, and behavior description element type. For the parameter layer, it extracts the attribute values ​​of constraint identifier element type, constraint name element type, associated requirement identifier element type, associated module identifier element type, associated activity identifier element type, and parametric equation element type. The modeling system regenerates the updated model data based on the extracted updated element types and element attribute values. When the description is modified in relation to structural layer elements, the updated structural layer model data is regenerated; when the description is modified in relation to behavioral layer elements, the updated behavioral layer model data is regenerated; when the description is modified in relation to parameter layer elements, the updated parameter layer model data is regenerated.

[0067] In practice, the modeling system replaces the corresponding original model data with the updated model data. If updated structural layer model data is generated, the updated structural layer model data overwrites the original structural layer model data stored in the temporary data area; if updated behavioral layer model data is generated, the updated behavioral layer model data overwrites the original behavioral layer model data stored in the temporary data area; if updated parameter layer model data is generated, the updated parameter layer model data overwrites the original parameter layer model data stored in the temporary data area. After the replacement is completed, the modeling system re-executes numerical simulation calculations and requirement satisfaction determinations using the replaced complete model data set. The numerical simulation calculations re-obtain the parametric equations of each constraint record from the parameter layer model data and substitute them into the updated parameter values ​​for calculation. The requirement satisfaction determination re-compares the simulation results with the requirement index thresholds. If, after re-determination, there are still requirement indicators with a false satisfaction status, a new list of elements to be modified is generated and displayed on the user interface, activating the corresponding input area to receive the user's modification description, and the above process is repeated. The modeling system iteratively executes simulation calculations, requirement fulfillment determination, generation of a list of elements to be modified, and model data updates until all requirement records have a true fulfillment status flag, meaning all requirements are deemed to be met, and the verification process ends.

[0068] See Figure 7The horizontal axis of the graph represents the number of iterations, ranging from 0 to 500, and the vertical axis represents the quantity, ranging from 0 to 200. The graph shows the changing trends of the "number of elements to be modified in the three categories" and the "number of unmet needs" with the number of iterations, indicated by different line types and colors: solid red lines represent the number of unmet needs, dashed blue lines represent the number of structural layer elements to be modified, dashed green lines represent the number of behavioral layer elements to be modified, and dotted orange lines represent the number of parameter layer elements to be modified.

[0069] At the initial iteration round 0, there were approximately 195 unmet requirements, approximately 150 structural layer elements requiring modification, approximately 120 behavioral layer elements requiring modification, and approximately 95 parameter layer elements requiring modification. These figures are all relatively high, reflecting a large number of unmet requirements and model-level elements needing modification in the initial system state. As the iteration rounds increase, all four curves show a significant downward trend, indicating that during the verification and iterative correction process based on the parameter layer model data described in Example 5, the number of unmet requirements and the number of structural, behavioral, and parameter layer elements requiring modification gradually decrease, while the model accuracy and requirement fulfillment gradually improve.

[0070] Between approximately 100 and 200 iterations, the curves slowed their decline, and the number decreased to below 20, indicating that after multiple iterations, the number of unmet needs and elements requiring modification significantly decreased. However, some incompletely met needs and corresponding model elements still required further optimization. After more than 300 iterations, all curves approached zero, indicating that with continuous iteration and correction, the model data and parametric equations gradually converged, the requirement satisfaction state was achieved, the number of elements requiring modification was minimal or nonexistent, and the verification process reached its termination condition.

[0071] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. An MBSE intelligent modeling method based on RSBP methodology, characterized in that, include: Obtain the natural language description input by the user for the target system, parse the modeling intent based on the natural language description, and extract key modeling elements; The key modeling elements are populated into the demand layer structured template to generate demand layer model data, which is then displayed in the demand layer view. In response to the user's confirmation operation on the requirement layer model data, the requirement layer model data is used as the context to populate the structure layer structured template, generate structure layer model data, and display the structure layer model data in the structure layer view. In response to the user's confirmation operation on the structural layer model data, the behavioral layer structured template is populated with the demand layer model data and the structural layer model data as context to generate behavioral layer model data, and the behavioral layer model data is displayed in the behavioral layer view. In response to the user's confirmation operation on the behavior layer model data, the parameter layer structured template is populated with the requirement layer model data, the structure layer model data and the behavior layer model data as context to generate parameter layer model data, and the parameter layer model data is displayed in the parameter layer view. The requirement layer model data, the structure layer model data, the behavior layer model data, and the parameter layer model data are converted into SysML standard model data according to a preset mapping rule, and the corresponding SysML model diagram is generated in the modeling tool.

2. The MBSE intelligent modeling method based on RSBP methodology according to claim 1, characterized in that, In the steps of obtaining a natural language description input by the user for the target system, parsing the modeling intent based on the natural language description, and extracting key modeling elements: Display guide labels on the user interface indicating the four modeling levels: requirements, structure, behavior, and parameters. Receive the natural language description entered by the user in the input area corresponding to any of the aforementioned guide labels; The current modeling level is determined based on the guiding label corresponding to the natural language description. The feature type and feature attribute value that match the current modeling level are extracted from the natural language description, and the extraction results are used as the key modeling elements.

3. The MBSE intelligent modeling method based on RSBP methodology according to claim 1, characterized in that, In the step of filling the key modeling elements into the demand layer structured template to generate demand layer model data: Obtain a predefined requirement layer structured template, which includes a requirement identifier field, a requirement name field, a requirement description field, a requirement priority field, and a requirement verification method field. Fill the requirement identifier value in the requirement identifier field, the requirement name value in the requirement name field, the requirement description text in the requirement description field, the requirement priority value in the requirement priority field, and the requirement verification method value in the requirement verification method field from the key modeling elements. After all fields are filled in, a structured data package for the requirement layer is formed, which serves as the requirement layer model data.

4. The MBSE intelligent modeling method based on RSBP methodology according to claim 1, characterized in that, In response to the user's confirmation of the requirement layer model data, the step of filling the structure layer structure template with the requirement layer model data as context to generate the structure layer model data is as follows: Extract the requirement identifier and requirement name from the requirement layer model data as a context index; Obtain a predefined structured template for the structured layer, which includes a module identifier field, a module name field, a module type field, a parent module identifier field, and an interface definition field; Based on the context index, extract the module identifier value, module name value, module type value, parent module identifier value, and interface definition value that match the structure layer from the key modeling elements, and fill them into the fields of the structure layer structured template accordingly; After all fields are filled in, a structured data packet is formed, which serves as the structured layer model data.

5. The MBSE intelligent modeling method based on RSBP methodology according to claim 1, characterized in that, In response to the user's confirmation of the structural layer model data, the step of generating behavioral layer model data by using the requirement layer model data and the structural layer model data as context to populate the behavioral layer structured template is as follows: The requirement identifier is extracted from the requirement layer model data, and the module identifier and module name are extracted from the structure layer model data, which together serve as the context index. Obtain a predefined behavior layer structured template, which includes an activity identifier field, an activity name field, a module identifier field, an input interface field, an output interface field, and a behavior description field; Based on the context index, extract the activity identifier value, activity name value, module identifier value, input interface value, output interface value, and behavior description text that match the behavior layer from the key modeling elements, and fill them into the fields of the behavior layer structured template accordingly; After all fields are filled in, a structured data packet for the behavior layer is formed, which serves as the behavior layer model data.

6. The MBSE intelligent modeling method based on RSBP methodology according to claim 1, characterized in that, In response to the user's confirmation of the behavior layer model data, the step of generating parameter layer model data by filling the parameter layer structure template with the requirement layer model data, the structure layer model data, and the behavior layer model data as context: Requirement identifiers and requirement verification methods are extracted from the requirement layer model data, module identifiers are extracted from the structure layer model data, and activity identifiers are extracted from the behavior layer model data, which together serve as context indexes; Obtain a predefined parameter layer structured template, which includes constraint identifier field, constraint name field, associated requirement identifier field, associated module identifier field, associated activity identifier field, and parametric equation field; Based on the context index, extract the constraint identifier value, constraint name value, associated requirement identifier value, associated module identifier value, associated activity identifier value, and parametric equation text that match the parameter layer from the key modeling elements, and fill them into the corresponding fields of the parameter layer structured template; After all fields are filled in, a parameter layer structured data packet is formed, which serves as the parameter layer model data.

7. The MBSE intelligent modeling method based on RSBP methodology according to claim 1, characterized in that, In the step of converting the demand layer model data, the structure layer model data, the behavior layer model data, and the parameter layer model data into SysML standard model data according to a preset mapping rule, and generating the corresponding SysML model diagram in the modeling tool: Traverse each requirement record in the requirement layer model data, map each requirement record to a SysML requirement element, and generate a requirement graph; Traverse each module record in the structure layer model data, map each module record to a SysML module definition element, and generate a module definition graph; Traverse each activity record in the behavior layer model data, map each activity record to a SysML activity element, and generate an activity graph; Traverse each constraint record in the parameter layer model data, map each constraint record to a SysML parameter constraint element, and generate a parameter graph; The requirement diagram, the module definition diagram, the activity diagram, and the parameter diagram are stored together under the same MBSE project.

8. The MBSE intelligent modeling method based on RSBP methodology according to claim 7, characterized in that, In the step of traversing each requirement record in the requirement layer model data, mapping each requirement record to a SysML requirement element, and generating a requirement diagram: Assign a SysML globally unique identifier to the requirement identifier field in each requirement record; Map the Requirement Name field in the Requirement Record to the Standard Name attribute of the SysML Requirement element, map the Requirement Description field to the Text attribute of the SysML Requirement element, map the Requirement Priority field to the Priority attribute of the SysML Requirement element, and map the Requirement Validation Method field to the Validation Method attribute of the SysML Requirement element. Based on the requirement identifier reference relationship between each requirement record, establish the derivation traceability association between SysML requirement elements; The requirement diagram is generated by arranging all SysML requirement elements according to their relationships.

9. The MBSE intelligent modeling method based on RSBP methodology according to claim 1, characterized in that, The method also includes a verification step after generating the parameter layer model data: Obtain the parametric equations corresponding to each constraint record in the parameter layer model data, perform numerical simulation calculations on the parametric equations, and obtain the simulation result values ​​of each constraint record; Obtain the requirement verification method and requirement indicator threshold corresponding to the associated requirement identifier of each constraint record from the requirement layer model data; The simulation result value is compared with the demand index threshold to determine whether the demand corresponding to each demand identifier has been met. For a requirement identifier that is determined to be unmet, the module identifier associated with the requirement identifier is located from the structural layer model data, and the activity identifier associated with the requirement identifier is located from the behavioral layer model data, generating a list of elements to be modified.

10. The MBSE intelligent modeling method based on RSBP methodology according to claim 9, characterized in that, After generating a list of elements to be modified for each unmet requirement identifier, the following steps are performed: Locating the module identifier associated with the requirement identifier from the structural layer model data, locating the activity identifier associated with the requirement identifier from the behavioral layer model data. The list of elements to be modified is displayed on the user interface, and the input area corresponding to the modeling level of each element in the list of elements to be modified is activated. Receive the modification description entered by the user in the input area, and regenerate the updated structure layer model data, the updated behavior layer model data, or the updated parameter layer model data according to the modification description; After replacing the corresponding original model data with the updated structural layer model data, the updated behavioral layer model data, or the updated parameter layer model data, the numerical simulation calculation and requirement satisfaction determination are re-executed until all requirements are determined to be satisfied.

Images