A domain-specific mbse process definition method

Abstract

The application discloses a domain-oriented MBSE process definition method, comprising the following steps: S1, performing object analysis, identifying system structure, interaction boundary and responsibility division; S2, performing research and development process analysis, constructing a multi-level MBSE process structure; S3, performing matching analysis of objects and processes, forming a process structure tree expanded according to levels; S4, performing research and development role definition, dividing modeling roles and clearly defining task boundaries and tool adaptation; S5, performing matching analysis of roles and processes, establishing role allocation relationships and task responsibilities; S6, performing model transfer analysis, defining model input and output, transfer path and delivery responsibility; S7, performing domain-level MBSE process definition, constructing a reusable standard process template; S8, performing project-level process tailoring, generating a customized MBSE process scheme adapted to project requirements. The application constructs a ternary matching mechanism, and realizes MBSE process role modeling and model closed-loop collaborative management.

Description

Technical Field

[0001] This invention relates to the fields of systems engineering and modeling technology, and in particular to a domain-specific MBSE process definition method. Background Technology

[0002] In recent years, with the increasing complexity of engineering projects, enterprises have significantly increased their demand for integrated management of system modeling and R&D processes. Model-Based Systems Engineering (MBSE) has become one of the mainstream directions in modern systems engineering. MBSE emphasizes driving each stage of work, such as requirements analysis, system design, verification, and integration, through models rather than documents, which can theoretically significantly improve development efficiency, process transparency, and model reusability. However, although the MBSE method has gained widespread attention and pilot applications in many industrial sectors, its widespread adoption at the enterprise level still faces many bottlenecks.

[0003] Currently, mainstream MBSE methodologies primarily focus on the general design of model languages, tool platforms, and standard processes, such as SysML-based system modeling and V-model-driven development processes. While these methods offer significant advantages in terms of standardization and theoretical completeness, they often lack effective integration with the actual R&D objects, organizational structures, and job responsibilities of enterprises in practical applications. This is particularly evident in industries such as aerospace, rail transportation, and energy equipment, which involve multi-level object collaboration and long-cycle development. Enterprises implementing MBSE commonly encounter problems such as vague process definitions, unclear modeling responsibilities, fragmented model deliverables, and chaotic delivery paths, resulting in the model's value not being fully realized throughout the system's lifecycle.

[0004] In existing technologies, the MBSE process is often provided as a relatively static process framework for reference, lacking the identification and adaptation to the hierarchical structure of specific research objects, and lacking a mechanism for systematically matching modeling activities with specific technical processes and role capabilities. Due to the lack of mapping capability to internal job responsibilities, existing processes struggle to clearly define "who does the modeling, what model to build, and at which stage," often resulting in a disconnect between model generation and use, and blind spots in responsibility allocation. Furthermore, existing methods often neglect the model's transfer logic and state transitions, making it difficult to efficiently share and reuse model data across multiple roles and stages, severely restricting modeling efficiency and engineering closure capabilities.

[0005] To address the aforementioned issues, this invention proposes a domain-specific MBSE process definition method, constructing a three-element fusion mechanism encompassing the research object, R&D process, and role matching. Through the multiple steps described in claims 1 to 8, this method achieves object-oriented process structure construction, role-capability-based task allocation, and comprehensive review and verification of the model transfer chain, ultimately forming a tailorable and reusable domain-level and project-level MBSE process definition model. Compared to existing technologies, this method solves key problems such as the mismatch between general MBSE processes and enterprise R&D tasks, ambiguity in role and task configuration, and the lack of model transfer between processes, significantly improving the adaptability, executability, and integration of MBSE processes. It is particularly valuable in supporting the construction of standardized enterprise processes and the accumulation of cross-project experience, effectively promoting the in-depth application of MBSE in complex local engineering practices.

[0006] Therefore, how to provide a domain-specific MBSE process definition method is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] One objective of this invention is to propose a domain-specific MBSE process definition method. This invention constructs a ternary matching mechanism of research object, research process and role, clarifies the modeling task and division of responsibilities, constructs a model transfer chain to realize the modeling closed loop, supports domain-level process standardization and project-level process tailoring, solves the problems of process mismatch, role ambiguity and unclear model transfer in existing MBSE methods, and improves the adaptability and executability of MBSE engineering.

[0008] According to an embodiment of the present invention, a domain-specific MBSE process definition method includes the following steps:

[0009] S1. Perform research and development object analysis, collect research and development background information of the target system, identify the hierarchical composition structure of the system, determine the interface relationship between each component and the internal and external interaction boundary, and divide the responsibility of the research and development object at each level based on the internal and external cooperation relationship of the enterprise.

[0010] S2. Perform R&D process analysis, identify the R&D stages and their technical tasks that match the research and development object, construct the input-output relationships and execution logic between each stage, and form a multi-level MBSE technical process structure that unfolds from the top-level process downwards.

[0011] S3. Perform matching analysis between the execution object and the process. Based on the hierarchical structure of the research and development object, map each level of object to the corresponding technical process stage to form an MBSE process structure tree that unfolds according to the object hierarchy.

[0012] S4. Define the R&D roles, based on the job responsibilities and capability structure of the enterprise's R&D organization, divide the modeling participation roles, and define the task boundaries, modeling capabilities and tool compatibility attributes of each role.

[0013] S5. Perform role and process matching analysis, match the defined roles with each technical process activity, establish a role and process matching matrix based on task objectives and modeling workload, and clarify the role and responsibilities of each activity.

[0014] S6. Perform model transfer analysis. For each role-process combination, identify the input model, output model, and reference model involved in the modeling activity, analyze the transfer direction, transfer boundary, and delivery responsibility of the model, and construct the model transfer chain.

[0015] S7. Execute MBSE domain-level process definition, integrate object structure, process activities and role matching results, establish a domain-level MBSE process model with industry-wide common characteristics, and form a standard process template that can be promoted and reused within the enterprise;

[0016] S8. Perform project-level process tailoring. Based on the specific project's research and development tasks, organizational resources, and technical requirements, select suitable subsets from the domain-level process model, merge processes, adjust roles, and reduce activities, and output a project-level MBSE process definition model and task allocation scheme.

[0017] Optionally, S2 specifically includes:

[0018] S21. Determine the R&D phases covered by the MBSE process, and divide them into phases such as requirements analysis, system design, modeling and simulation, verification and delivery management according to the system engineering life cycle, to form a top-level technical process structure;

[0019] S22. Within each R&D phase, identify the key technical activities to be performed, including modeling activities, simulation activities, data interaction activities, and verification activities, and divide them into process units with execution boundaries;

[0020] S23. Define the input and output model types for each process unit, and clarify the data sources on which the modeling process depends and the model results it produces;

[0021] S24. Analyze the input-output relationships between each process unit, form the dependency paths between processes, and construct the execution order and information flow logic between each technical process;

[0022] S25. Identify the boundaries of the interface relationships between processes, determine whether there are refactoring, feedback or iterative interactions between different processes, and identify the execution constraints between each process.

[0023] S26. Expand the top-level technical process in a hierarchical manner to form a complete process structure tree containing sub-processes and their internal activity nodes, and define the operation boundaries for each level of sub-process.

[0024] S27. Decompose the modeling tasks in each R&D process and extract the generation, modification and usage tasks of the model artifacts as the basis for subsequent role allocation and modeling responsibility identification.

[0025] S28. Perform consistency verification on the execution logic of all technical processes to ensure that the data flow, task chain, and model usage path between processes comply with the MBSE systematic modeling principles, and serve as the input basis for the next step of object matching and role configuration.

[0026] Optionally, S3 specifically includes:

[0027] S31. Establish the structural hierarchy of the research and development object, and divide it into system layer, subsystem layer, component layer and functional unit layer according to the system composition to form a hierarchical object structure list;

[0028] S32. Construct a set of R&D process stages, which are divided into technical processes such as requirements analysis, system design, simulation modeling, and integration verification according to different stages of the system life cycle;

[0029] S33. Correspond each level of the research object to each stage of the research and development process, and match the corresponding process activities according to the modeling requirements and participation depth of the level to which the object belongs.

[0030] S34. Within each level, complete the matching operation between all objects and applicable processes within that level, and clarify the modeling tasks and technical activities that each research and development object participates in during the research and development process.

[0031] S35. During the matching of objects and procedures, the matching scope is limited to the corresponding level to ensure the consistency of procedure matching between objects at the same level and avoid cross-level mismatch.

[0032] S36. Organize the objects and processes that have completed the matching relationship to form a structured list of matching results, and clarify the work content undertaken by the objects in each stage of the R&D process;

[0033] S37. Based on the structured matching results, arrange the participation paths of all objects in each process to form an MBSE process execution sequence unfolded from the perspective of the objects.

[0034] S38. Output the matching results as the input basis for subsequent role allocation and model transfer analysis, providing an object-level execution basis for subsequent modeling responsibility division and model flow path.

[0035] Optionally, S4 specifically includes:

[0036] S41. Identify existing R&D positions and responsibilities within the company, and streamline the organizational structure and job positions related to the MBSE process;

[0037] S42. Based on job responsibilities and work content, R&D positions are divided into several modeling role types, including but not limited to requirement modeling role, structural modeling role, behavioral modeling role, verification and analysis role, system integration role, and process coordination role.

[0038] S43. Define the scope of tasks undertaken by each type of modeling role, including the process stages that can be participated in, the modeling tasks that can be performed, the data types that can be processed, and the tool platforms that can be used.

[0039] S44. Analyze the capability correspondence between each role and the R&D process, and clarify the applicability and execution boundaries of each role in each R&D stage;

[0040] S45. Aggregate and classify roles with similar task capabilities to construct functional role groups to support organizational structure optimization and role replacement analysis.

[0041] S46. Clearly define the input information, output results, model operation methods, and process responsibility boundaries for each role, and establish a list of role capability definitions;

[0042] S47. Set a task template for each role type, describing its typical activity sequence, task nodes, and the types of modeling artifacts involved in the MBSE process.

[0043] S48. Output all roles and their task capabilities as the basis for matching roles with process activities, and provide a basis for personnel allocation for the subsequent construction of the MBSE modeling collaboration mechanism.

[0044] Optionally, S5 specifically includes:

[0045] S51. Based on the defined R&D roles and various technical process activities, organize the matching conditions between the role's task capabilities and the process activity requirements;

[0046] S52. For the modeling task in each technical process stage, identify the required operational capabilities, tool compatibility and data processing requirements.

[0047] S53. Select the role types that meet the requirements of this modeling task from the defined role set as candidate roles that can participate in the process activities;

[0048] S54. Based on the actual responsibilities of each role, decompose the input model, processing content and output results of each process activity, and clarify the division of labor among the participating roles in the activity.

[0049] S55. For situations involving multiple roles in the same process activity, clarify the collaboration order, information flow path and responsibility boundaries between the roles to form a complete role allocation structure;

[0050] S56. Organize all roles and their associated process activities in a unified manner, and establish a one-to-one or many-to-many correspondence between roles and process activities.

[0051] S57. Perform a consistency check on the matching results of all roles and process activities to confirm that each process activity is assigned at least one qualified execution role to ensure the executability of the MBSE process at the personnel level.

[0052] S58. Output a matching list of roles and process activities, which serves as the basic configuration data for subsequent modeling responsibility division, task assignment, and model transfer path analysis.

[0053] Optionally, S6 specifically includes:

[0054] S61. For each process activity that has been assigned to a specific role, identify the input model, output model, and intermediate model involved in the activity, and form a list of model elements.

[0055] S62. Analyze the generation, modification, review and use of the model among various roles, and identify the transmission path and timing of the model between active nodes;

[0056] S63. Determine the interface format, data structure standard and version control method required when the model is transferred between different roles, and define the input and output conditions for model handover;

[0057] S64. Set transfer permissions for each type of model element, and clarify which roles have read, write, read-only or approval permissions to prevent permission overstepping and version confusion during model use.

[0058] S65. Analyze the lifecycle trajectory of the same model across multiple process activities, and identify its initial generation point, key modification point, and final archiving point in the process chain;

[0059] S66. Label the state changes during the model transfer process and record the change path of the model state from "initial" to "under construction" and then to "final version" caused by each transfer;

[0060] S67. Establish a complete model transfer structure diagram, labeling the generator, receiver, user, and approver of each model, forming a closed loop for model transfer between personnel and process dimensions;

[0061] S68. Output the model transfer path as the basis for model flow control during MBSE process execution, and provide modeling data dependency basis for subsequent process definition and tailoring.

[0062] Optionally, S7 specifically includes:

[0063] S71. Summarize the hierarchical structure of research and development objects, the division of research and development process stages, and the results of role and capability mapping to establish a basic dataset of ternary matching relationships;

[0064] S72. Based on the matching results of objects and processes, construct a full-process modeling path from the perspective of the research and development object, and clarify the process activities involved in each object at each stage;

[0065] S73. Based on the matching relationship between roles and processes, determine the execution roles in each process activity and establish a three-dimensional responsibility chain of role-process-model;

[0066] S74. By integrating the temporal logic and model transfer path of modeling activities at each stage, analyze the dependencies between stages of the modeling process and clarify the serial and parallel structure and constraints of the modeling tasks.

[0067] S75. Define the structural framework of the domain-level MBSE process, including the top-level development phase, the composition of activities within the phase, the dependencies between activities, and the division of roles and tasks.

[0068] S76. Group and classify all process activities to form a set of process modules applicable to common industry scenarios, and set the input and output conditions and applicable scope of each module;

[0069] S77. Combine the various process modules according to business logic, modeling order, and role participation relationships to construct a standard MBSE process template suitable for a specific domain;

[0070] S78. Output the constructed domain-level MBSE process definition model as the basic support structure for enterprise standardization, cross-project reuse, and project-level process tailoring.

[0071] Optionally, S8 specifically includes:

[0072] S81. Based on the specific project's research and development objectives, project cycle, organizational structure, and delivery requirements, extract the project's characteristic parameters to form a tailored input configuration list;

[0073] S82. Analyze the established domain-level MBSE process templates to identify content that does not match the current project's research and development objectives, process requirements, and role capabilities;

[0074] S83. Based on project requirements, the domain-level process is modularized, including deleting irrelevant process stages, merging adjacent activities, adjusting the order of modeling activities, replacing process roles, and modifying model delivery paths;

[0075] S84. Reconfigure the retained process activities, optimize the role allocation results based on the project's organizational resources and personnel capabilities, and ensure that each task has a clear responsible party;

[0076] S85. Define the task boundaries and model artifact delivery standards in the project-level MBSE process, and clarify the input information, execution conditions and output requirements for each activity;

[0077] S86. Adjust the model delivery path to ensure that the generation, use, approval and archiving of the model in the trimmed activity structure have logical integrity and a closed loop of responsibility.

[0078] S87. Generate a project-specific MBSE process execution checklist, including process structure, role assignment, modeling task arrangement, model delivery nodes, and process time plan;

[0079] S88. Output the instantiation results of the project-level MBSE process as a guide for the modeling process during the project implementation phase, and use it to support subsequent engineering activities such as process management, task execution and data tracking.

[0080] The beneficial effects of this invention are:

[0081] First, this invention systematically integrates the actual R&D tasks of an enterprise with the MBSE process by constructing a three-element matching mechanism of R&D object, R&D process, and R&D role. This achieves the identification and analysis of the hierarchical structure of the R&D object, the structured modeling of process stages, and the capability mapping and task allocation of personnel roles. It solves the problems of disconnect between the modeling process and the engineering object, and the ambiguity of role responsibilities, that exist in traditional MBSE methods. Through a one-to-one mapping of object structure and technical process, the modeling tasks that different levels of objects should undertake at each stage are clarified, giving the MBSE process a clear logical driving path and execution sequence, providing a structured foundation for full-process modeling.

[0082] Secondly, this invention focuses on the collaborative relationship between "roles, processes, and models," introducing a method for defining roles and matching processes based on modeling task types, tool adaptability, and capability boundaries, thus constructing a complete modeling responsibility chain. Compared to the unclear role positioning and frequent task overlap in existing MBSE practices, this invention ensures that each modeling activity has a clearly defined executor and deliverable through precise matching of roles and process activities, fundamentally improving the transparency and controllability of modeling responsibility. Simultaneously, this method provides model permission division, version control, and status marking mechanisms, effectively supporting the stable flow of model artifacts across multiple roles and stages.

[0083] Furthermore, this invention constructs a complete closed-loop path for the model lifecycle through model transfer chain analysis, providing a refined definition of the entire process from model generation, modification, use to archiving, significantly improving the reusability and traceability of model artifacts at various stages of systems engineering. The transfer relationships and interaction boundaries between active nodes are clearly modeled, forming a traceable and verifiable model state chain, avoiding the problems of "models being built but not used," "multiple builds being duplicated," or chaotic transfer paths found in traditional methods. Through the clear definition of model inputs and outputs, this invention also ensures the consistency of model interfaces and the effectiveness of cross-stage use.

[0084] Furthermore, this invention supports the construction of domain-level MBSE process models based on enterprise standard processes, and rapidly generates project-level personalized process structures through a tailoring mechanism, achieving an efficient transformation from industry standardization to project engineering. When facing specific projects with different task objectives, organizational structures, or resource conditions, this invention can achieve rapid adaptation and reconfiguration of process structures through module combination, role adjustment, and activity restructuring, greatly improving the flexibility and implementation capability of the MBSE method in complex engineering environments, and meeting the dual demands of enterprises for the parallel development of standardization and customization.

[0085] Ultimately, through object-driven approaches, role collaboration, and model-closed-loop control throughout the entire process, this invention effectively solves the problems of model-process disconnect, ambiguous task boundaries, and unclear data flow in traditional MBSE implementation, driving a fundamental shift in MBSE from "tool use" to "organizational process integration." Overall, this invention not only enhances the engineering adaptability and role matching of MBSE process definitions but also improves the executability, scalability, and process controllability of model-driven processes in real-world projects, demonstrating significant engineering promotion value and cross-industry applicability potential. Attached Figure Description

[0086] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0087] Figure 1 This is an overall flowchart of a domain-specific MBSE process definition method proposed in this invention;

[0088] Figure 2 This is a structural diagram of a model-based general framework for research and development processes (PRDVVA) proposed in this invention;

[0089] Figure 3 This invention presents a flowchart of a project-level MBSE process trimming and reconfiguration operation. Detailed Implementation

[0090] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0091] refer to Figure 1-3 A domain-specific MBSE process definition method includes the following steps:

[0092] S1. Perform research and development object analysis, collect research and development background information of the target system, identify the hierarchical composition structure of the system, determine the interface relationship and internal and external interaction boundary between each component, and divide the responsibility of the research and development object at each level based on the internal and external cooperation relationship of the enterprise.

[0093] S2. Perform R&D process analysis, identify the R&D stages and their technical tasks that match the research and development object, construct the input-output relationships and execution logic between each stage, and form a multi-level MBSE technical process structure that unfolds from the top-level process downwards.

[0094] S3. Perform matching analysis between the execution object and the process. Based on the hierarchical structure of the research object, map each level of object to the corresponding technical process stage to form an MBSE process structure tree that unfolds according to the object hierarchy.

[0095] S4. Define the R&D roles, based on the job responsibilities and capability structure of the enterprise's R&D organization, divide the modeling participation roles, and define the task boundaries, modeling capabilities and tool compatibility attributes of each role.

[0096] S5. Perform role and process matching analysis, match the defined roles with each technical process activity, establish a role and process matching matrix based on task objectives and modeling workload, and clarify the role and responsibilities of each activity.

[0097] S6. Perform model transfer analysis. For each role-process combination, identify the input model, output model, and reference model involved in the modeling activity, analyze the transfer direction, transfer boundary, and delivery responsibility of the model, and construct the model transfer chain.

[0098] S7. Execute MBSE domain-level process definition, integrate object structure, process activities and role matching results, establish a domain-level MBSE process model with industry-wide common characteristics, and form a standard process template that can be promoted and reused within the enterprise;

[0099] S8. Perform project-level process tailoring. Based on the specific project's research and development tasks, organizational resources, and technical requirements, select suitable subsets from the domain-level process model, merge processes, adjust roles, and reduce activities, and output a project-level MBSE process definition model and task allocation scheme.

[0100] This invention constructs a collaborative modeling mechanism for the three elements of "research object - R&D process - R&D role", systematically defines the domain-specific MBSE process structure, establishes the logical foundation and task configuration rules for full-process modeling, and solves core problems such as the mismatch between traditional MBSE processes and actual enterprise R&D, unclear modeling responsibilities, and incomplete model transfer chains. It significantly improves the adaptability, executability and reusability of MBSE in complex engineering.

[0101] In this embodiment, S2 specifically includes:

[0102] S21. Determine the R&D phases covered by the MBSE process, and divide them into phases such as requirements analysis, system design, modeling and simulation, verification and delivery management according to the system engineering life cycle, to form a top-level technical process structure;

[0103] S22. Within each R&D phase, identify the key technical activities to be performed, including modeling activities, simulation activities, data interaction activities, and verification activities, and divide them into process units with execution boundaries;

[0104] S23. Define the input and output model types for each process unit, and clarify the data sources on which the modeling process depends and the model results it produces;

[0105] S24. Analyze the input-output relationships between each process unit, form the dependency paths between processes, and construct the execution order and information flow logic between each technical process;

[0106] S25. Identify the boundaries of the interface relationships between processes, determine whether there are refactoring, feedback or iterative interactions between different processes, and identify the execution constraints between each process.

[0107] S26. Expand the top-level technical process in a hierarchical manner to form a complete process structure tree containing sub-processes and their internal activity nodes, and define the operation boundaries for each level of sub-process.

[0108] S27. Decompose the modeling tasks in each R&D process and extract the generation, modification and usage tasks of the model artifacts as the basis for subsequent role allocation and modeling responsibility identification.

[0109] S28. Perform consistency verification on the execution logic of all technical processes to ensure that the data flow, task chain, and model usage path between processes comply with the MBSE systematic modeling principles, and serve as the input basis for the next step of object matching and role configuration.

[0110] This invention systematically decomposes the R&D stages involved in the MBSE process, clarifies the structural components, activity units, input-output logic, and interaction relationships of the technical process, and establishes a complete multi-level process system. It effectively solves the problems of coarse process definition granularity, ambiguous activity boundaries, and unclear upstream and downstream data interfaces in existing MBSE methods, and provides a structural foundation for subsequent object matching and task allocation.

[0111] In this embodiment, S3 specifically includes:

[0112] S31. Establish the structural hierarchy of the research and development object, and divide it into system layer, subsystem layer, component layer and functional unit layer according to the system composition to form a hierarchical object structure list;

[0113] S32. Construct a set of R&D process stages, which are divided into technical processes such as requirements analysis, system design, simulation modeling, and integration verification according to different stages of the system life cycle;

[0114] S33. Correspond each level of the research object to each stage of the research and development process, and match the corresponding process activities according to the modeling requirements and participation depth of the level to which the object belongs.

[0115] S34. Within each level, complete the matching operation between all objects and applicable processes within that level, and clarify the modeling tasks and technical activities that each research and development object participates in during the research and development process.

[0116] S35. During the matching of objects and procedures, the matching scope is limited to the corresponding level to ensure the consistency of procedure matching between objects at the same level and avoid cross-level mismatch.

[0117] S36. Organize the objects and processes that have completed the matching relationship to form a structured list of matching results, and clarify the work content undertaken by the objects in each stage of the R&D process;

[0118] S37. Based on the structured matching results, arrange the participation paths of all objects in each process to form an MBSE process execution sequence unfolded from the perspective of the objects.

[0119] S38. Output the matching results as the input basis for subsequent role allocation and model transfer analysis, providing an object-level execution basis for subsequent modeling responsibility division and model flow path.

[0120] This invention proposes a process-oriented recursive matching driven by the research object hierarchy, constructing an object-led MBSE process structure tree that can accurately describe the modeling task distribution of objects at each level in each stage. This solves the problems of unclear modeling object distribution and task implementation at the object level in existing MBSE methods, and enhances the fit and traceability between modeling and engineering objects.

[0121] In this embodiment, S4 specifically includes:

[0122] S41. Identify existing R&D positions and responsibilities within the company, and streamline the organizational structure and job positions related to the MBSE process;

[0123] S42. Based on job responsibilities and work content, R&D positions are divided into several modeling role types, including but not limited to requirement modeling role, structural modeling role, behavioral modeling role, verification and analysis role, system integration role, and process coordination role.

[0124] S43. Define the scope of tasks undertaken by each type of modeling role, including the process stages that can be participated in, the modeling tasks that can be performed, the data types that can be processed, and the tool platforms that can be used.

[0125] S44. Analyze the capability correspondence between each role and the R&D process, and clarify the applicability and execution boundaries of each role in each R&D stage;

[0126] S45. Aggregate and classify roles with similar task capabilities to construct functional role groups to support organizational structure optimization and role replacement analysis.

[0127] S46. Clearly define the input information, output results, model operation methods, and process responsibility boundaries for each role, and establish a list of role capability definitions;

[0128] S47. Set a task template for each role type, describing its typical activity sequence, task nodes, and the types of modeling artifacts involved in the MBSE process.

[0129] S48. Output all roles and their task capabilities as the basis for matching roles with process activities, and provide a basis for personnel allocation for the subsequent construction of the MBSE modeling collaboration mechanism.

[0130] This invention analyzes the structure of enterprise R&D positions, systematically defines modeling role types, competency ranges, and tool compatibility, and constructs a functional role family. It effectively solves the problems of lack of standardized role settings, unclear division of responsibilities, and difficulty in matching personnel capabilities with modeling tasks in the existing MBSE implementation, and enhances the implementation capability and executability of the MBSE process under the organizational structure.

[0131] In this embodiment, S5 specifically includes:

[0132] S51. Based on the defined R&D roles and various technical process activities, organize the matching conditions between the role's task capabilities and the process activity requirements;

[0133] S52. For the modeling task in each technical process stage, identify the required operational capabilities, tool compatibility and data processing requirements.

[0134] S53. Select the role types that meet the requirements of this modeling task from the defined role set as candidate roles that can participate in the process activities;

[0135] S54. Based on the actual responsibilities of each role, decompose the input model, processing content and output results of each process activity, and clarify the division of labor among the participating roles in the activity.

[0136] S55. For situations involving multiple roles in the same process activity, clarify the collaboration order, information flow path and responsibility boundaries between the roles to form a complete role allocation structure;

[0137] S56. Organize all roles and their associated process activities in a unified manner, and establish a one-to-one or many-to-many correspondence between roles and process activities.

[0138] S57. Perform a consistency check on the matching results of all roles and process activities to confirm that each process activity is assigned at least one qualified execution role to ensure the executability of the MBSE process at the personnel level.

[0139] S58. Output a matching list of roles and process activities, which serves as the basic configuration data for subsequent modeling responsibility division, task assignment, and model transfer path analysis.

[0140] This invention establishes a many-to-many matching relationship between roles and process activities, clarifies the executor, task boundaries, and collaboration mechanism of each modeling task, and constructs a role allocation matrix refined to the activity level. This solves the problems of "no one to undertake modeling tasks" or "unclear overlapping responsibilities" in the traditional MBSE process, and improves the transparency of process execution and the efficiency of modeling collaboration.

[0141] In this embodiment, S6 specifically includes:

[0142] S61. For each process activity that has been assigned to a specific role, identify the input model, output model, and intermediate model involved in the activity, and form a list of model elements.

[0143] S62. Analyze the generation, modification, review and use of the model among various roles, and identify the transmission path and timing of the model between active nodes;

[0144] S63. Determine the interface format, data structure standard and version control method required when the model is transferred between different roles, and define the input and output conditions for model handover;

[0145] S64. Set transfer permissions for each type of model element, and clarify which roles have read, write, read-only or approval permissions to prevent permission overstepping and version confusion during model use.

[0146] S65. Analyze the lifecycle trajectory of the same model across multiple process activities, and identify its initial generation point, key modification point, and final archiving point in the process chain;

[0147] S66. Label the state changes during the model transfer process and record the change path of the model state from "initial" to "under construction" and then to "final version" caused by each transfer;

[0148] S67. Establish a complete model transfer structure diagram, labeling the generator, receiver, user, and approver of each model, forming a closed loop for model transfer between personnel and process dimensions;

[0149] S68. Output the model transfer path as the basis for model flow control during MBSE process execution, and provide modeling data dependency basis for subsequent process definition and tailoring.

[0150] This invention proposes a model transfer chain modeling method, which systematically identifies the state changes, flow paths and delivery responsibilities of the model at each process node, defines the permission mechanism and life cycle state labels, effectively solves the problems of chaotic model transfer between roles, version inconsistency and ambiguity of responsibility, and realizes the full closed-loop management of the model in the process dimension and organizational dimension.

[0151] In this embodiment, S7 specifically includes:

[0152] S71. Summarize the hierarchical structure of research and development objects, the division of research and development process stages, and the results of role and capability mapping to establish a basic dataset of ternary matching relationships;

[0153] S72. Based on the matching results of objects and processes, construct a full-process modeling path from the perspective of the research and development object, and clarify the process activities involved in each object at each stage;

[0154] S73. Based on the matching relationship between roles and processes, determine the execution roles in each process activity and establish a three-dimensional responsibility chain of role-process-model;

[0155] S74. By integrating the temporal logic and model transfer path of modeling activities at each stage, analyze the dependencies between stages of the modeling process and clarify the serial and parallel structure and constraints of the modeling tasks.

[0156] S75. Define the structural framework of the domain-level MBSE process, including the top-level R&D phase, the composition of activities within the phase, the dependencies between activities, and the division of roles and tasks.

[0157] S76. Group and classify all process activities to form a set of process modules applicable to common industry scenarios, and set the input and output conditions and applicable scope of each module;

[0158] S77. Combine the various process modules according to business logic, modeling order, and role participation relationships to construct a standard MBSE process template suitable for a specific domain;

[0159] S78. Output the constructed domain-level MBSE process definition model as the basic support structure for enterprise standardization, cross-project reuse, and project-level process tailoring.

[0160] Based on the comprehensive object structure, process path, and role tasks, this invention constructs a standardized domain-level MBSE process template, which has the characteristics of modularity, structure, and configurability. It supports cross-project reuse and enterprise-level deployment, and solves the problems of lack of unified process standards, process fragmentation, and poor engineering consistency in the promotion of MBSE, thereby improving the standardization and replicability of the modeling method.

[0161] In this embodiment, S8 specifically includes:

[0162] S81. Based on the specific project's research and development objectives, project cycle, organizational structure, and delivery requirements, extract the project's characteristic parameters to form a tailored input configuration list;

[0163] S82. Analyze the established domain-level MBSE process templates to identify content that does not match the current project's research and development objectives, process requirements, and role capabilities;

[0164] S83. Based on project requirements, the domain-level process is modularized, including deleting irrelevant process stages, merging adjacent activities, adjusting the order of modeling activities, replacing process roles, and modifying model delivery paths;

[0165] S84. Reconfigure the retained process activities, optimize the role allocation results based on the project's organizational resources and personnel capabilities, and ensure that each task has a clear responsible party;

[0166] S85. Define the task boundaries and model artifact delivery standards in the project-level MBSE process, and clarify the input information, execution conditions and output requirements for each activity;

[0167] S86. Adjust the model delivery path to ensure that the generation, use, approval and archiving of the model in the trimmed activity structure have logical integrity and a closed loop of responsibility.

[0168] S87. Generate a project-specific MBSE process execution checklist, including process structure, role assignment, modeling task arrangement, model delivery nodes, and process time plan;

[0169] S88. Output the instantiation results of the project-level MBSE process as a guide for the modeling process during the project implementation phase, and use it to support subsequent engineering activities such as process management, task execution and data tracking.

[0170] This invention provides a project-characteristic-based MBSE process tailoring and reconfiguration mechanism, which can screen activities, adjust roles, and optimize model paths according to task objectives, organizational capabilities, and modeling scope. It solves the mismatch between general processes and project requirements, realizes rapid customization, flexible implementation, and on-demand execution of MBSE processes, and enhances the engineering adaptability and deployment efficiency of the method.

[0171] Example 1:

[0172] To verify the feasibility of this invention in practice, it was applied to an aero-engine company. The company was developing a medium-thrust turbofan engine designed for unmanned combat platforms, which possesses complex system integration characteristics and multi-stage technology verification requirements. During the project initiation phase, the company comprehensively applied the domain-specific MBSE process definition method proposed in this invention for the first time, using it to construct a model-driven R&D system that spans the entire process of research, development, manufacturing, testing, operation, and maintenance.

[0173] In the early stages of the project, the traditional V-model development process failed to fully integrate upstream information such as aircraft, systems, and mission payloads, leading to problems in engine requirements analysis including unclear boundaries, missing inputs, and disjointed processes. Fragmented model building and unclear responsibility interfaces impacted the efficiency of solution integration and the progress of multi-disciplinary collaborative design. To address this, the company adopted the method of this invention, initiating MBSE domain process definition and tailoring work in September 2023 to construct a modeling process system that conforms to its own development logic.

[0174] In the specific implementation, the team first conducted a contextual analysis of the engine object. In the R&D context, the team identified systems that directly interact with the engine, including: aviation equipment systems (such as fighter jets), platform interface systems (such as fuel supply and environmental control), and downstream subsystems (such as the engine casing and booster pump). This resulted in a requirement mapping model based on 23 external inputs, 15 system interface definitions, and 6 types of performance constraints. In the manufacturing context, the team analyzed 15 key process flows, 6 types of assembly platforms, and 4 types of manufacturing partners, identifying interface and process dependencies between the engine and its components. In the testing context, the team defined the interface interactions between 8 testing subsystems and the engine, including high-altitude test benches, wind tunnels, whole-engine hot-testing systems, and combustion efficiency assessment platforms, and established model interface diagrams. In the operation and maintenance context, the team analyzed the operational logic of interactions with the flight control system, platform health management system, support equipment, and spare parts planning system under aviation operating conditions, outputting 12 types of key data collection points and 10 operation / maintenance data interfaces.

[0175] Based on the aforementioned object context, the team conducted a technical process analysis. This analysis identified 27 activity nodes, including engine requirements modeling, functional modeling, system integration, trade-off analysis, test modeling, and simulation verification, as well as 13 external input items and 7 industry standard control items. A technical process mapping was performed around the MBSE top-level framework PRDVVA (Development Planning, Requirements Analysis, Design and Integration, Verification and Validation, System Analysis), resulting in a company-wide version of the top-level technical process flowchart. Further, through role-process adaptation, the involved R&D roles were divided into 8 groups: system modeler, control designer, heat transfer structure analyst, system integration coordinator, and test simulation engineer. A process modeling tool was used to match these roles one-to-one with the process nodes, defining a total of 38 modeling task nodes and assigning responsibilities.

[0176] During the model transfer and analysis phase, model state diagrams and lifecycle diagrams were established for 32 types of model artifacts, including engine overall performance models, component coupling models, cooling structure analysis models, and control logic models. The generation nodes, calling nodes, approvers, and deliverables for each model were clearly defined. This ensured that the model was free of redundancy, loss, and was traceable across the five stages of functional modeling, parametric simulation, experimental model generation, integrated modeling, and delivery archiving.

[0177] By applying the method of this invention, the company completed the construction of a domain-level MBSE process standard for the first time, and in March 2024, it completed the project-level process tailoring for this type of engine project based on this standard. Compared with similar development processes in the past, the application of the method of this invention has achieved the following practical results: the modeling preparation phase cycle was reduced from an average of 32 days to 15 days; the modeling task omission rate was reduced from 12% to 2%; the model delivery consistency was improved to over 96%; the cross-disciplinary model reconstruction requirements were reduced from an average of 9 times to 2 times; the experimental model reuse rate was increased from 43% to 71%; and the number of multi-role collaborative accidental conflict cases was reduced from 18 to 1. The entire project has achieved comprehensive improvements in process visualization, model closed-loop management, and task responsibility allocation.

[0178] Overall, this embodiment fully verifies the adaptability and engineering application value of the present invention in the context of complex systems engineering in aero-engine enterprises. It significantly improves the clarity of object identification, the rationality of process definition, the efficiency of role allocation, and the standardization of model management, laying the foundation for the large-scale promotion of the MBSE method in the development of highly complex systems such as aero-engines.

[0179] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A domain-specific MBSE process definition method, characterized in that, Includes the following steps: S1. Perform research and development object analysis, collect research and development background information of the target system, identify the hierarchical composition structure of the system, determine the interface relationship between each component and the internal and external interaction boundary, and divide the responsibility of the research and development object at each level based on the internal and external cooperation relationship of the enterprise. S2. Perform R&D process analysis, identify the R&D stages and their technical tasks that match the research and development object, construct the input-output relationships and execution logic between each stage, and form a multi-level MBSE technical process structure that unfolds from the top-level process downwards. S3. Perform matching analysis between the execution object and the process. Based on the hierarchical structure of the research and development object, map each level of object to the corresponding technical process stage to form an MBSE process structure tree that unfolds according to the object hierarchy. S4. Define the R&D roles, based on the job responsibilities and capability structure of the enterprise's R&D organization, divide the modeling participation roles, and define the task boundaries, modeling capabilities and tool compatibility attributes of each role. S5. Perform role and process matching analysis, match the defined roles with each technical process activity, establish a role and process matching matrix based on task objectives and modeling workload, and clarify the role and responsibilities of each activity. S6. Perform model transfer analysis. For each role-process combination, identify the input model, output model, and reference model involved in the modeling activity, analyze the transfer direction, transfer boundary, and delivery responsibility of the model, and construct the model transfer chain. S7. Execute MBSE domain-level process definition, integrate object structure, process activities and role matching results, establish a domain-level MBSE process model with industry-wide common characteristics, and form a standard process template that can be promoted and reused within the enterprise; S8. Perform project-level process tailoring. Based on the specific project's research and development tasks, organizational resources, and technical requirements, select suitable subsets from the domain-level process model, merge processes, adjust roles, and reduce activities, and output a project-level MBSE process definition model and task allocation scheme.

2. The domain-specific MBSE process definition method according to claim 1, characterized in that, S2 specifically includes: S21. Determine the R&D phases covered by the MBSE process, and divide them into phases such as requirements analysis, system design, modeling and simulation, verification and delivery management according to the system engineering life cycle, to form a top-level technical process structure; S22. Within each R&D phase, identify the key technical activities to be performed, including modeling activities, simulation activities, data interaction activities, and verification activities, and divide them into process units with execution boundaries; S23. Define the input and output model types for each process unit, and clarify the data sources on which the modeling process depends and the model results it produces; S24. Analyze the input-output relationships between each process unit, form the dependency paths between processes, and construct the execution sequence and information flow logic between each technical process; S25. Identify the boundaries of the interface relationships between processes, determine whether there are refactoring, feedback or iterative interactions between different processes, and identify the execution constraints between each process. S26. Expand the top-level technical process in a hierarchical manner to form a complete process structure tree containing sub-processes and their internal activity nodes, and define the operation boundaries for each level of sub-process. S27. Decompose the modeling tasks in each R&D process and extract the generation, modification and usage tasks of the model artifacts as the basis for subsequent role allocation and modeling responsibility identification. S28. Perform consistency verification on the execution logic of all technical processes to ensure that the data flow, task chain, and model usage path between processes comply with the MBSE systematic modeling principles, and serve as the input basis for the next step of object matching and role configuration.

3. The domain-specific MBSE process definition method according to claim 1, characterized in that, S3 specifically includes: S31. Establish the structural hierarchy of the research and development object, and divide it into system layer, subsystem layer, component layer and functional unit layer according to the system composition to form a hierarchical object structure list; S32. Construct a set of R&D process stages, which are divided into technical processes such as requirements analysis, system design, simulation modeling, and integration verification according to different stages of the system life cycle; S33. Correspond each level of the research object to each stage of the research and development process, and match the corresponding process activities according to the modeling requirements and participation depth of the level to which the object belongs. S34. Within each level, complete the matching operation between all objects and applicable processes within that level, and clarify the modeling tasks and technical activities that each research and development object participates in during the research and development process. S35. During the matching of objects and procedures, the matching scope is limited to the corresponding level to ensure the consistency of procedure matching between objects at the same level and avoid cross-level mismatch. S36. Organize the objects and processes that have completed the matching relationship to form a structured list of matching results, and clarify the work content undertaken by the objects in each stage of the R&D process; S37. Based on the structured matching results, arrange the participation paths of all objects in each process to form an MBSE process execution sequence unfolded from the perspective of the objects. S38. Output the matching results as the input basis for subsequent role allocation and model transfer analysis, providing an object-level execution basis for subsequent modeling responsibility division and model flow path.

4. The domain-specific MBSE process definition method according to claim 1, characterized in that, S4 specifically includes: S41. Identify existing R&D positions and responsibilities within the company, and streamline the organizational structure and job positions related to the MBSE process; S42. Based on job responsibilities and work content, R&D positions are divided into several modeling role types, including but not limited to requirement modeling role, structural modeling role, behavioral modeling role, verification and analysis role, system integration role, and process coordination role. S43. Define the scope of tasks undertaken by each type of modeling role, including the process stages that can be participated in, the modeling tasks that can be performed, the data types that can be processed, and the tool platforms that can be used. S44. Analyze the capability correspondence between each role and the R&D process, and clarify the applicability and execution boundaries of each role in each R&D stage; S45. Aggregate and classify roles with similar task capabilities to construct functional role groups to support organizational structure optimization and role replacement analysis. S46. Clearly define the input information, output results, model operation methods, and process responsibility boundaries for each role, and establish a list of role capability definitions; S47. Set a task template for each role type, describing its typical activity sequence, task nodes, and the types of modeling artifacts involved in the MBSE process. S48. Output all roles and their task capabilities as the basis for matching roles with process activities, and provide a basis for personnel allocation for the subsequent construction of the MBSE modeling collaboration mechanism.

5. The domain-specific MBSE process definition method according to claim 1, characterized in that, S5 specifically includes: S51. Based on the defined R&D roles and various technical process activities, organize the matching conditions between the role's task capabilities and the process activity requirements; S52. For the modeling task in each technical process stage, identify the required operational capabilities, tool compatibility and data processing requirements. S53. Select the role types that meet the requirements of this modeling task from the defined role set as candidate roles that can participate in the process activities; S54. Based on the actual responsibilities of each role, decompose the input model, processing content and output results of each process activity, and clarify the division of labor among the participating roles in the activity. S55. For situations involving multiple roles in the same process activity, clarify the collaboration order, information flow path and responsibility boundaries between the roles to form a complete role allocation structure; S56. Organize all roles and their associated process activities in a unified manner, and establish a one-to-one or many-to-many correspondence between roles and process activities. S57. Perform a consistency check on the matching results of all roles and process activities to confirm that each process activity is assigned at least one qualified execution role to ensure the executability of the MBSE process at the personnel level. S58. Output a matching list of roles and process activities, which serves as the basic configuration data for subsequent modeling responsibility division, task assignment, and model transfer path analysis.

6. The domain-specific MBSE process definition method according to claim 1, characterized in that, S6 specifically includes: S61. For each process activity that has been assigned to a specific role, identify the input model, output model, and intermediate model involved in the activity, and form a list of model elements. S62. Analyze the generation, modification, review and use of the model among various roles, and identify the transmission path and timing of the model between active nodes; S63. Determine the interface format, data structure standard and version control method required when the model is transferred between different roles, and define the input and output conditions for model handover; S64. Set transfer permissions for each type of model element, and clarify which roles have read, write, read-only or approval permissions to prevent permission overstepping and version confusion during model use. S65. Analyze the lifecycle trajectory of the same model across multiple process activities, and identify its initial generation point, key modification point, and final archiving point in the process chain; S66. Mark the state changes during the model transfer process and record the change path of the model state from "initial" to "under construction" and then to "final version" caused by each transfer; S67. Establish a complete model transfer structure diagram, labeling the generator, receiver, user, and approver of each model, forming a closed loop for model transfer between personnel and process dimensions; S68. Output the model transfer path as the basis for model flow control during MBSE process execution, and provide modeling data dependency basis for subsequent process definition and tailoring.

7. The domain-specific MBSE process definition method according to claim 1, characterized in that, Specifically, S7 includes: S71. Summarize the hierarchical structure of research and development objects, the division of research and development process stages, and the results of role and capability mapping to establish a basic dataset of ternary matching relationships; S72. Based on the matching results of objects and processes, construct a full-process modeling path from the perspective of the research and development object, and clarify the process activities involved in each object at each stage; S73. Based on the matching relationship between roles and processes, determine the execution roles in each process activity and establish a three-dimensional responsibility chain of role-process-model; S74. By integrating the temporal logic and model transfer path of modeling activities at each stage, analyze the dependencies between stages of the modeling process and clarify the serial and parallel structure and constraints of the modeling tasks. S75. Define the structural framework of the domain-level MBSE process, including the top-level R&D phase, the composition of activities within the phase, the dependencies between activities, and the division of roles and tasks. S76. Group and classify all process activities to form a set of process modules applicable to common industry scenarios, and set the input and output conditions and applicable scope of each module; S77. Combine the various process modules according to business logic, modeling order, and role participation relationships to construct a standard MBSE process template suitable for a specific domain; S78. Output the constructed domain-level MBSE process definition model as the basic support structure for enterprise standardization, cross-project reuse, and project-level process tailoring.

8. The domain-specific MBSE process definition method according to claim 1, characterized in that, S8 specifically includes: S81. Based on the specific project's research and development objectives, project cycle, organizational structure, and delivery requirements, extract the project's characteristic parameters to form a tailored input configuration list; S82. Analyze the established domain-level MBSE process templates to identify content that does not match the current project's research and development objectives, process requirements, and role capabilities; S83. Based on project requirements, the domain-level process is modularized, including deleting irrelevant process stages, merging adjacent activities, adjusting the order of modeling activities, replacing process roles, and modifying model delivery paths; S84. Reconfigure the retained process activities, optimize the role allocation results based on the project's organizational resources and personnel capabilities, and ensure that each task has a clear responsible party; S85. Define the task boundaries and model artifact delivery standards in the project-level MBSE process, and clarify the input information, execution conditions and output requirements for each activity; S86. Adjust the model delivery path to ensure that the generation, use, approval and archiving of the model in the trimmed activity structure have logical integrity and a closed loop of responsibility. S87. Generate a project-specific MBSE process execution checklist, including process structure, role assignment, modeling task arrangement, model delivery nodes, and process time plan; S88. Output the instantiation results of the project-level MBSE process as a guide for the modeling process during the project implementation phase, and use it to support subsequent engineering activities such as process management, task execution and data tracking.

Images