Author: Chen Jinwen, Li Li, Qian Zhiwei, Jiangxi Hongdu Aviation Industry Group Co., Ltd
Summary: Through the technical research of multi-dimensional classification of MBSE models, MBSE model organization methods based on project areas, and stream-based model version management methods, this paper realizes the centralized management and sharing of various MBSE models of different projects and heterogeneous and scattered, improves the efficiency of model retrieval and sharing, and promotes the collaborative design of model-based products.
1 Introduction
With the development of digital technology, Model-Based System Engineering (MBSE) has become the latest direction of system engineering development, emphasizing the model as the core of system design [1]. MBSE is an effective means to solve complex system problems, which changes the traditional design mode of transmitting information in the form of documents, and reflects the system functions and behaviors more clearly and accurately through visual and graphical system models [2], and revises the scheme and architecture in the early stage of design, so as to effectively improve the design efficiency and quality of complex systems.
After years of exploration and practice, Hongdu has accumulated valuable experience in the field of MBSE, realized the demand management of multiple models of the whole aircraft, established the functional logic model of aircraft-level, avionics, flight control, environmental control, fuel and other systems based on the SysML language [3], and established a multidisciplinary simulation model library of landing gear system and environmental control system based on Modelica language [4], forming the capability of demand management, system definition, functional analysis, architecture design, modeling and simulation verification. However, the following problems remain:
(1) Most of the MBSE models generated in the process of project development are stored in local management, and there is a lack of unified platform management, such as demand models, demand templates, etc., which are managed in the demand management software, and functional models, logical models and physical characteristic models are managed locally, and it is very inconvenient to retrieve and share models, and the model management with the project as the traction is not realized, which increases the cost of enterprise resource maintenance, and the efficiency of model management and sharing is low.
(2) The MBSE model is scattered on the personal computers of various system engineers, lacks control over the technical status of the model, and the utilization rate of the model in the same project and between different projects is not high, so it is impossible to realize the multi-person collaboration in the same project area based on the model, and the model reuse between different project areas.
In order to solve the above problems, this paper realizes the centralized management and sharing of various MBSE models of different projects and heterogeneous and scattered through the technical research of multi-dimensional classification of MBSE models, MBSE model organization methods based on project areas, and model version management methods based on streams, so as to improve the efficiency of model retrieval and sharing, and promote the collaborative design of model-based products.
2 Overview of the MBSE model
The MBSE models mentioned in this article are mainly divided into requirement model, functional model, logical model and physical property model, and each type of model is defined as follows:
Definition 1: A requirements model is a model that can handle the level of abstraction that can be dealt with, fully or partially expressing requirements [5].
The requirements model is defined as a weighted acyclic graph G=(I,O,R). where I is the set of non-empty vertices of Figure G, which is composed of a finite set of demand features describing the requirements model. O∈I is the root node of graph G, which is called the root feature of the demand model, and the root feature of the demand model is the unique identifier that distinguishes the demand model, which is mainly used to describe the information related to the entire demand model, and the root feature O of the demand model G is recorded as Root(G), that is, O=Root(G); R∈IxIxN forms the weighted edges of the graph, which represents the similarity of the demand features in the graph, where N is the set of natural numbers. The weighted edge w of the graph gives the value of the semantic similarity between the requirements features in the demand model, and the semantic similarity between the requirements features T1 and T2 is recorded as Rw(T1,T2).
Definition 2 Functional model refers to a system "black box" model that describes the functions of the system and its boundaries, which can be expressed in the form of functional architecture diagrams, use case diagrams, activity diagrams, sequence diagrams, etc., to support the capture and analysis of functional requirements [6].
Definition 3 Logic model refers to a "white-box" model that describes the logical composition of the system and its data flow and control flow relationships, which can be expressed in the form of logic architecture diagrams, swimlane diagrams (white-box activity diagrams), timing diagrams, state machines, functional flow block diagrams, and data flow diagrams to support the capture and distribution of requirements [6].
The functional model and the logical model can be described as M = (S, E), where S represents the set of model elements and E is the set of relationships between model elements. The directed weighted graph corresponding to the model can be described as WG=(S,E,W), where S and E are the same as S and E in M, and W represents the weight set, which is the strength of the relationship corresponding to the relationship elements in E.
Definition 4 Physical property model refers to the model that describes the physical implementation of the system and its multidisciplinary physical properties [7], including different types such as geometric models, mechanical models, control characteristic models, electromagnetic effect models, etc., including single-discipline and multi-disciplinary physical property simulations, which are used to support the trade-off analysis of requirements and scenarios.
3 Research on MBSE model management and sharing technology
3.1 Multi-dimensional classification method of MBSE model
For example, the system level mainly involves the definition and allocation of system requirements and the model generated by the architecture design process, while the subsystem level and component level involve the model generated by the functional implementation and physical design process. From the perspective of the product development stage, the MBSE model runs through all aspects of the product development stage, and different engineering activities need to continuously improve and maintain the MBSE model. From a product architecture perspective, it's a positive design process from requirements, functionality, logic, and physics. Therefore, this paper classifies MBSE models from three dimensions: product level, product development stage and architecture view, and proposes a multi-dimensional classification method based on product level, development stage and architecture view.
Figure 1 classifies models based on product hierarchy, development stage, and architecture views
(1) Divide the model from the dimension of product level
Figure 2 divides the product hierarchy into system-level, subsystem-level, and component-level, and the one-way edges in the diagram represent one-to-many relationships. Thereinto:
The system level is the structural component of a product, which may contain multiple systems, subsystems, and components, or may consist of just one simple component. The values of l and m in the system-level requirements model are as follows: {R(l,m)|l≥0,m≥0,l+m≥1}; The values of p and q in the functional model are: {F(p,q)|p≥0,q≥0,p+q≥1}; The values of you and v in the logical model are as follows: {L(u,v)|u≥0,v≥0,u+v≥1}; The values of x and y in the physical property model are as follows: {P(x,y)|x≥0,y≥0,x+y≥1};
The subsystem is mainly composed of components, which is the basic component unit of the product, and the values of n, r, w and z are: {(R(n),F(r),L(w),P(z))|n≥1,r≥1,w≥0,z≥0} (when w=0, the components at the subsystem level have no logical architecture, which is the smallest unit constituting the subsystem, and the components meet some functions and performance requirements of the subsystem; When z=0, the current component does not need to be physically modeled and simulated);
Components are built from a set of requirements, functions, logic, and physical models, and are the basic units that make up systems and subsystems.
Figure 2: Product hierarchy
(2) The model is divided from the dimension of product development stage
The military aircraft development stage is divided into the demonstration stage, the engineering development stage, the assembly and finalization stage, and the batch production/support stage. In the demonstration stage, the demand model and function model will be generated; In the engineering development stage, the demand model and functional model generated based on the same project are refined and decomposed, and the product design output results such as the demand model, functional model, logical model and physical characteristic model after the gradual refinement of the project are generated. Update and maintain the demand model, functional model, logical model and physical characteristics model in the same project in the finalization stage; The Batch/Guarantee phase updates maintain the requirements model within the same project.
Figure 3 is based on the model classification based on the product development stage
3.2 MBSE model organization method based on project area
In Figure 4, the MBSE model can be freely combined and organized according to model tags such as resource number, field, project, development stage, system, etc., for example, the model instance is organized by product demand model library, functional model library, logic model library, etc. according to the resource number, the model instance is organized by aviation, aerospace, weapons, etc. according to the field, and the model instance is organized by belonging to different projects according to the project, and so on. At the same time, it supports the free combination of multiple attributes, such as displaying the corresponding model examples of different development stages under different projects according to the project and development stage, and displaying the corresponding model examples of different systems under different projects according to the project and system.
The development of military aircraft is guided by the project, and the models generated in the process of project development are mainly displayed in the form of project views, so they are organized according to the project, development stage or project and system form, so as to improve the efficiency of model management and sharing between the same project regions, and at the same time realize the "paid" and "controllable" sharing of models between different project regions, and give full play to the value of the model.
Figure 4 Organization of the MBSE model
3.3 Stream-based model versioning method
Figure 5 illustrates the principle of model versioning based on data flow, which brings great flexibility to the multi-versioning management of models. A flow can represent a product model design process, and at a certain stage of the product, several sub-streams can be derived at the same time based on the current baseline version, and the sub-flows can represent different versions of the product model, belong to different teams or different system engineers, carry out different model design according to a unified model baseline, and finally deliver the optimal model for the project. Streams can be compared with each other, and problems found in a stream can be zeroed in in a child stream or merged into a parent stream through a child stream.
Figure 5: Flow-based model versioning
Figure 6 shows the evolution process of model versions between different multiple states of the same product, product 1 (state A) is the mainstream of product 1 model, and product 1 (state B) and product 1 (state C) models are derived from the product 1 (state A) model. The initial version of the product 1 (state B) model is the same as the version of product 1 (state A), that is, v1.0, and the v2.0 model is derived on the basis of v1.0, and a new version is derived on Stream 1. Based on the v1.0 model of product 1 (state A), product 1 (state C) derives a branch of Stream 2 to form the initial version v1.0 model, derives the v1.1 model on the basis of v1.0, and generates the v1.2 model of product 1 (state C) based on the v1.2 version of product 1 (state A).
Figure 6: Model version evolution between different states of the same product
Figure 7 shows the evolution of model versions between different products, product 1 (state A) is the mainstream of product 1 model, and product 1 (state B) and product 2 (state A) models are derived from the product 1 (state A) model. The initial version of the product 1 (state B) model is the same as the version of product 1 (state A), that is, v1.0, and the v2.0 model is derived on the basis of v1.0, and a new version is derived on Stream 1. Based on the v1.1 model of product 1 (state A), a branch of Stream 2 is derived to form the initial version v1.0 model, and the v1.1 model is derived on the basis of v1.0, and the v1.2 model of product 2 (state A) is derived based on the v2.1 version of product 1 (state B).
Figure 7: Model version evolution between different products
3.4 Model sharing mechanism based on project area and flow
Figure 8 shows how to share the model between the same product and different products, where product 1 (state A) corresponds to the mainstream of the model, and product 1 (state B) is the diversion of product 1 (state A), and the model owner can share the model with people, organizations, and roles according to the project, flow (corresponding baseline), and individual version. By default, all versions of the model in product 1 (state A) are shared with person 1 or organization 1 or role 1, and the model of product 1 (state B) is shared with person 1 or organization 1 or role 1 in a certain version (for example, v2.1) of the corresponding flow, and all versions of the model corresponding to product 2 (state A) are shared with person 2 or organization 2 or role 2 by default, and product 1 (state A) is shared with person 2 or organization 2 or role 2 in a version (such as v1.1) of the model on the flow (for example, v1.1).
Figure 8: Model sharing between the same product and different products
Figure 9 shows the process-based product model sharing mode, in which the output of activity 1 in a development process of product 1 is a model (v1.0), which corresponds to the model in the main stream of product 1 (state A), the output of activity 1 node is used as the input of activity 2 node, and the model is shared through process execution, and the output of activity 2 is a model (v2.0), which corresponds to the model in Stream 1 (v2.0) of product 1 (state B).
Figure 9: Process-based product model sharing
4 Technical architecture of MBSE model management and sharing platform
Figure 10 shows that the MBSE model management and sharing platform consists of an application layer, a service layer, and development tools, and uses a common database to store models.
Application layer: Engineering designers and simulation analysts operate the interface, send requests to the service layer and database according to their respective permissions, and call the corresponding design tools to load the model.
Service layer: Created based on the microservice framework, it provides functions such as process modeling, process-model association, model management, and tool adapters, as well as requirements services, system design services, and physical modeling services.
Development tools: mainly including requirements analysis and management, system function logic architecture design, multi-physics modeling and simulation analysis and other tools and model management platform, model management is driven by mainstream databases, unified storage and management of various granular models of each development tool, providing data services for the application layer and service layer.
Figure 10 Technical architecture of the MBSE model management and sharing platform
5 MBSE model management and shared application mode
Figure 11 shows the relationship between MBSE model management and sharing, and the model is shared with the same project team member through three ways: model retrieval, push, and process-based push, and the process-based push needs to define the association between the process and the model in advance. In different project areas, the model sharing method is similar to that of the same project area, provided that the model is authorized first to realize the sharing of the model among different project personnel.
Figure 11: Model management and sharing diagram
Upload the MBSE model to the model management and sharing platform for management, and integrate with the MBSE design environment based on the tool adapter. Each MBSE design tool retrieves and loads the model through the interface, or establishes the association between the process activity node and the model resource, so as to push the model based on the process and carry out the MBSE design work.
Figure 12 MBSE model management and sharing application mode
Taking the requirements capture and decomposition process of XX project and XX system as an example, two ways of model sharing are introduced.
(1) Based on the process push model
Define the requirements capture and decomposition process in the integrated R&D platform, and establish the association between process activities and related models, such as the association of requirements analysis and definition activities with XX project and XX system requirements. The plan manager applies the process template to decompose the task, and the designer receives the issued demand analysis and definition task and the demand model associated with the activity, and at the same time can push the relevant model according to the task attributes (such as XX project, XX system, etc.) or keywords, and open the pushed demand model in the demand management software to complete the demand analysis and definition work.
(2) Model retrieval
When carrying out requirements analysis and definition in requirements management software, models can be retrieved through advanced search, full-text search, etc. For example, if you enter the conditions of XX project and XX system, you can retrieve the demand model through the interface in the demand management software to realize the sharing of the demand model.
6 Conclusion
In view of the needs of MBSE innovation and development of aviation products, combined with the needs of MBSE model technology status management in the process of product development, this paper breaks through the MBSE model management and sharing technology, explores and forms a model management and sharing application mode based on project area and flow, and proposes a technical architecture of MBSE model management and sharing platform to realize the centralized management and sharing of heterogeneous and scattered MBSE models, which can improve the efficiency of model retrieval and sharing, and promote the collaborative design of model-based products.
[References]
[1] Zhu Jing; YANG Hui; Wait. Overview of model-based system engineering[J].Aero Engine,2016(04).
[2] ESTEFAN J A.Survey of modl-based systems engineering(MBSE)methodologies[R]. INCOSE MBSE Focus Group,2008.
[3] Jiang Caiyun, Wang Weiping, Li Qun. SysML:a new system modeling language[J].Journal of System Simulation,2006.6,18(06).
[4] Modelica Association.Modelica-A Unified Object-Orintd Language for Physical Systems Modeling-Language Specification[S]，2014.
[5] Chen Yingxin. Computer Simulation,2010.5,27(05).
[6] Xu Yongjun. Application of systematic propulsion system engineering, method and tool platform in aviation product development[J].Aviation Manufacturing Technology,2014.18.
[7] Liu Bin, Zhang Yunyong. Industrial Internet application based on digital twin model[J].Telecommunications Science,2019.05
Transferred from the official account: the god of PLM