2.1. Statistical analysis of relevant papers

Based on the conducted systematic literature review described in the previous section, 198 paper with reference to utilization were identified. In advance to a detailed analysis and discussion of the contributions in the following section, the overall statistics of the results are analysed first. In order to enable a comparison of the results from the study within this paper, a comparative study on the general use of SysML in scientific papers was performed. In contrast to the study of Wolny et al. (Reference Wolny, Mazak, Carpella, Geist and Wimmer2020), the search string was not limited to the paper titles, but also considered author keywords. As a result of this comparative study, 1501 contributions concerning SysML were identified. Reviewing those results regarding their years of publication (Figure 3a), a rising trend between 2005 and 2013 as well as a declining trend between 2014 and 2017 can be observed, which matches the findings of Wolny et al. (Reference Wolny, Mazak, Carpella, Geist and Wimmer2020). Since the year 2018, the number of contributions focusing SysML increased again to approximately the level of 2017 in the year 2021. Comparing those numbers to the resulting 198 publications within this systematic literature review, it can be observed that the rising trend of SysML papers in general is not represented in the results of utilization papers. In the years after 2009 the number per year declines, but rises again after 2011. After a drop in papers per year in 2015 and a high in 2016, the number averages at about 12 papers per year (Figure 3a).

Figure 3. Comparison of publications per year (a) resulting from systematic literature review on utilization (198 papers) and general search on SysML (1501 papers) as well as the share of publications per year (b) concerning utilization.

In order to emphasize this result, the share of publications of general SysML and utilization paper is shown in Figure 3b. Thus, about 11% of the total SysML papers per year address the utilization within the past five years. This leads to the finding in the context of the conducted literature review, that there is a continuous but not rising interest in this aspect of SysML model reuse.

2.2. Clustering and distribution

The 198 papers of the literature review show all facets of the term utilization. With the generic initial understanding and the identification of relevant bibliographical characteristics for the search string, a broad field for the further reuse and the utilization is given. However, each of them describes an individual use case to answer a specific research question. For example, while the specific use case is focused on directly creating a Failure Mode and Effects Analysis (FMEA) from a SysML model (Girard et al. Reference Girard, Baeriswyl, Hendriks, Scherwey, Müller, Hönig, Lunde, Baraldi, Di Maio and Zio2020), the general aim is to derive a development artefact from a system model. Insights of these derived artefacts or documents can lead to manual feedback towards the system model. For creating these classes, the relevant papers were labelled with their specific use cases. Hence, these individual approaches can be clustered into larger classes (see Table 1, where a short description of each is given), which define the overall aim of the paper assigned to those classes. A detailed description of the classes with examples is given in Section 2.3.

Table 1. Definition of classes for the utilization of SysML models and assessed papers

The analysis of the results of the conducted literature study regarding the aforementioned classifications reveals an uneven distribution of research efforts towards the utilization, see Table 1. Since the resulting classes in section only use selected contributions as examples, Table 1 lists all 196 papers within their respective classes. The complete list of literature is provided in the Supplementary Material. For this literature review, the relevant papers were labelled with specific use cases. Merging these use cases led to the creation of the presented classes.

While the majority with 57% of the publications is classified as model transformations, only a fraction of the papers (3%) considers model synchronization, which was simplified as a form of bidirectional model transformation. Interestingly, model transformation could be assumed as a pre-stage for bidirectional synchronization and explain the missing publications in this class as they require preceded works. However, this cannot be observed by analysing the allocation of classes over the years. Generally the term “Single Source of Truth” or “Authoritative Source of Truth” is often mentioned with system models and MBSE approaches (Kruse & Blackburn Reference Kruse and Blackburn2019; Henderson et al. Reference Henderson, McDermott, van Aken and Salado2023). It is considered as one of the main aims for introducing an MBSE approach. Although there is no official definition of this term, it goes along with improved accessibility for information. This could be achieved by synchronizing models bidirectional and defining the system model as the source for relevant information throughout the system development. Nevertheless, the model transformation is the dominant research direction within the utilization of SysML models since 2006.

2.3. Detailed class description and interaction with the system model

After labelling all relevant papers, the presented classes in Table 1 were identified as common thread to describe the format of reusing and utilizing system models. In addition to these classes, different approaches for building up the system model can be observed as depicted in Figure 4. While some use the initial system model directly, others are creating new sub-models and packages with the only purpose of utilizing these. The utilization process itself can also be differentiated into three different categories. First, the system model is feeding a database that can then be further used for the different approaches. Second, the tool API is used to connect different tools, for example, the connection between other software, such as Cameo or Matlab Simulink (Chabibi et al. Reference Chabibi, Douche, Anwar and Nassar2016). Third, the system model’s XMI structure is utilized to extract the relevant information from the model (Wilking et al. Reference Wilking, Sauer, Schleich and Wartzack2022a). The approaches are not restricted on the usage of only one class but can be assigned to multiple classes. The individual classes with examples are explained individually in the following sections whilst referring to Figure 4 as indicated by lower case characters.

Figure 4. Derived classes of utilization with automated and manual tasks and use cases. The assigned characters (a–j) are described individually within the textual class description.

3.1. Definition and classification system

The literature review enabled the analysis of bibliographical characteristics for the reuse and utilization of SysML system models. Within the introduction in Section 1, an initial understanding was given, that was based on the subjectively and implicitly usage of the term “utilization”. To enable a common understanding of the term as well as giving a basis for harmonized modelling strategies, a definition is presented in this section. Shortly after the introduction of SysML first attempts were made to further reuse the models. In fact, reuse describes the generic reuse of the models and therefore can also mean that elements of a system model are reused, for example, throughout several product generations (Albers, Bursac & Wintergerst Reference Albers, Bursac, Wintergerst, Mastorakis and Solomon To2015). This reuse is defined as an advanced use of the three purposes for system modelling, that is, improvement of communication, analysis of the technical system and the documentation of it (Friedenthal, Dori & Mordecai Reference Friedenthal, Dori and Mordecai2021).

More specific the utilization of system models describes the reuse for use cases or several application scenarios along the product life cycle of the system by creating machine-readable system models. The authors of this contribution therefore define utilization as a subcategory of reusing system models. Those models are used for automated vertical and horizontal distribution of their included information as well as interfacing domain-specific tools (e.g., requirements management system). Therefore, utilization adds new objectives for existing or adapted system models, whereas recycling of system models does not change the objectives of the modelled information. This definition of the utilization is shown in Figure 5. However, utilization is only one form of reusing system models, as mentioned before.

Figure 5. Definition of the reuse in terms of system model utilization.

The utilization of system models in the context of SysML can therefore address the introduced classes of artefact derivation, execution, model simulation, model transformation, semantic integration and/or model synchronization (Figure 5). Although this review was conducted for SysML models only, the classification system is also suitable for other languages and utilization scenarios, such as within Capella and the connection with discipline-specific models. However, other approaches might lead to additional use cases that cannot be grasped by SysML.

In addition to the classes, every single use case of utilization, such as verification and validation, Digital Twins, and so on, and stages within the life cycle according to ISO/IEC/IEEE 15288 (2015) can be assigned to a class. This leads to a three-dimensional classification system for the utilization of system models, as shown in Figure 6. The orange indications within this figure are relevant for the exemplary application for two different scenarios of the proposed classification system within Section 3.2. Interdependencies between the three axes are possible. While classes can be found in any life cycle stage, specific use cases might predefine a class and a stage of the life cycle. This does not lead to a limitation of the classification system, but reveals applied and potentially more feasible approaches.

Figure 6. Proposed classification system for the utilization with integration of scenarios S1.1 and S1.2 (see Table 2) with upstream modelling activities and scenario S2 (see Table 3) into the classification system; visual design based on VDI/VDE Society Measurement and Automatic Control (2015).

For an application of the classification system and finally the derivation of connected methodical modelling approaches, further considerations have to be stated. Since machine-readability and interoperability between SysML and other models are highly depending on a tool support, many of the described scenarios are using the XMI structure of SysML models (Handley et al. Reference Handley, Khallouli, Huang, Edmonson and Kibret2021). This requires awareness in the modelling process of the system model. As humans are able to interpret text fields on a diagram and might make the correct association with nearby diagram objects, the machine-readable context is gone and information is lost in the visualization of the model, but not in the model itself. This is not necessarily caused by a false application of SysML, but rather by the given interpretation spaces coming along with this language. The further utilization of system models therefore requires modelling recommendations and guidelines or simplified APIs that enable the utilization described in this definition. Universal methodical approaches are not yet existing, since the applications are use case specific and might require different methods. Therefore, a thorough classification of the approach, for example, through the presented classification system, might help to develop certain guidelines and methods to enable a harmonized approach for the utilization. However, the allocation within the classification system must not be limited to a distinct point but can be enlarged to multiple sections, for example, for relevancy along different life cycle stages. Nevertheless, a separation of the class is recommended, as these significantly influence the purpose of the utilization. Yet, multiple classes can be combined to a connected application scenario that involves different classes but their purposes are dissociated from each other. The recommended classification system therefore offers a separation of the described classes in layers, as they are strictly separated. In addition, the context of the life cycle stage is given based on ISO/IEC/IEEE 15288 (2015). Models have different purposes regarding their usage within the life cycle of a system. Nevertheless, almost every class of the utilization can be discovered in every stage of the life cycle regarding the analysed paper, which can be seen in the Supplementary Material. Furthermore, the separation of use cases for the utilization supports the definition of a goal for the approach that might be achieved in a later stage of the life cycle but must be conducted in a previous one, for example, through the creation of models for the operation phase that are created during the development. This shift of the required effort can be useful to create the right modelling approach in the right context of the product creation. The given examples for use cases, such as the Digital Twin, show this shift. While Digital Twins might benefit from the utilization of the SysML model during operation, the required modelling and utilization effort will happen during its development and concept phase as well as the twinning during the production and instantiation (Stark et al. Reference Stark, Anderl, Thoben and Wartzack2020). But the assignment to a use case can be shaped by different implications and can have intersections with other use cases. The shown use cases in Figure 6 are examples for published work, such as a system model-driven student project for engineering education (Wilking et al. Reference Wilking, Behringer, Fett, Goetz, Kirchner and Wartzack2023). While some use cases reveal technical implications for methodical recommendations, others can simply provide similar approaches to the designer. Used within product development, the classification of the system model towards utilization reveals insights in the application scenario as well as required modelling activities. This is necessary to develop further methodical approaches for the specific utilization scenario.

3.2. Application of the proposed classification system for utilization

For a further description of the definition of the term and the integrated classification system, as well as first recommendations towards guidelines for a methodical approach, two scenarios are given which describe different use cases, classes, and stages of the product life cycle. The variety of use cases for the utilization of system models is huge. However, the two use cases can give first valuable feedback on the requirements for modelling guidelines or methodical approaches towards the utilization. Figure 6 shows their integration into the classification system, where they are indicated in orange colour.

3.2.1. S1: SysML 4 Digital Twins

Wilking et al. (Reference Wilking, Sauer, Schleich and Wartzack2022b) describe an approach to utilize SysML models that are visualizing the behaviour of a Digital Twin system. Since models are a significant part of a Digital Twin (Schleich et al. Reference Schleich, Anwer, Mathieu and Wartzack2017), MBSE is a promising approach for the design of Digital Twins (Wang et al. Reference Wang, Steinbach, Klein and Anderl2021). System models add a special value to the development and operation of Digital Twins by defining the general behaviour of the physical and digital counterparts as well as connecting relevant information and other models that are used within the Digital Twin concept. Examples for this are the integration of the system into its environment or the inclusion of model decay regarding the physical counterpart throughout its lifecycle into the behaviour of the system. In this scenario, a system model was created as a central model that visualizes the interaction of multiple relevant models for the Digital Twin as well as the detected and stored operational data from the physical counterpart. Packages of that model were directly derived and used as executable code to base the actual behaviour of the Digital Twin completely on the SysML model, see Table 2. In addition, a machine learning algorithm as well as relevant information for its execution was implemented into the system model to directly connect physical elements of the model with relevant elements for machine learning (Wilking et al. Reference Wilking, Sauer, Schleich and Wartzack2022a). This enabled parallel activities to model and execute the behaviour of the Digital Twin, for example, by conducting a precise but time-consuming simulation and parallel run a machine learning script to gather less detailed but therefore quick recommendations towards the current state of the system and required actions, for example, maintenance intervals. This scenario shows a case in which the benefit of the utilization is achieved within a later stage of the life cycle, but the effort has to be invested already during the development. This is a significant shift of effort and benefit and requires a thorough consideration within the modelling approach, as existing approaches do not yet involve the utilization and the preparation of utilized system models. In addition, the whole use case is taking advantage of two classes, showing that a combination is possible and for some cases reasonable.

Table 2. Scenario description of “SysML 4 Digital Twins”

3.2.2. S2: Formalization of integrated variation management and its use in robustness evaluation

A second scenario is introduced by Horber et al. (Reference Horber, Goetz, Schleich and Wartzack2022a), which proposed an approach to formalize engineering activities in the context of integrated variation management. Motivated by the variety of different methods, tools as well as data in variation management and a lack of their integration into a consistent model, the approach uses activity, requirement and block diagrams (SysML) to model the contents of integrated variation management. Its use enables the consistent reuse of model elements in connected approaches within the variation management domain, see Table 3. As applied by Horber et al. (Reference Horber, Goetz, Schleich and Wartzack2022a) to early stage variation management, which focuses on the development of robust product concepts, the created model can be utilized for further approaches, for example, the robustness evaluation (Horber et al. Reference Horber, Li, Grauberger, Schleich, Matthiesen and Wartzack2022b). The approach uses qualitative sketches of product concepts, combines them with embodiment-function-relations and transfers the qualitative model into a corresponding SysML model. The contents of the model can then be retrieved for robustness evaluation and build the basis for further development of the selected concept. Other model elements, such as key characteristics, are thereby relevant for even later stages like parameter design or even production.

Table 3. Scenario description for formalization of integrated variation management

3.3. Methodical implications resulting from the classification system

The two described scenarios give a detailed insight into the utilization of SysML system models as an equal purpose for the creation of system models. While the life cycle stages and classes are finite, the use cases allow various application scenarios for the utilization. However, it does not seem that the use cases affect the modelling approach significantly. In contrast, classes and stages of the life cycle have a significant influence on the approach. While the classes are naturally describing separate approaches and aims of the utilization, life cycle stages strongly influence the approach by determining the context of the creation and the use for a not yet or already existing system with significant differences for the modelling.

However, the scenarios have shown that a methodical approach towards harmonizing the modelling procedure is crucial. This is especially the case where the utilization is conducted along a value chain and where harmonized modelling strategies between stakeholders are necessary. Currently, some system modelling tools support interfaces with other tools and by that enable a model transformation for a further utilization. Thus, many of the other defined classes are not yet sufficiently integrated into systems model toolchains, as this is not only relevant for the system modelling tool, but also for discipline and domain-specific tools that integrate the system model.

Many use cases are utilizing the XMI structure of the modelling language to further utilize the models. The XML files contain the whole model as well as the visualization. This leads to immense and confusing model sizes. Hence, individual packages within the model must be created, which leads to scenarios in which a model is just created for its further utilization but not used again. Thus, the overall benefit of the approach is diminished. A possible solution for this could be the introduction of a utilization view which enables the reduction of a model towards necessary aspects for the utilization without affecting the model itself. Views are a common tool in SysML to enable different degrees of detail on a model as well as different perspectives depending on the discipline and domain (Alt Reference Alt2012; Albers et al. Reference Albers, Bursac, Scherer, Birk, Powelske and Muschik2019). With this, it can be ensured that the model itself can still be used for other purposes, while the utilized version is reduced. However, this reduction cannot be generalized. In fact, while a model transformation reasonably should transfer the visual aspects of a diagram, other utilization classes might not use the diagram at all.

The need for such a methodical approach, that integrates the aimed utilization into the methodical model creation, and its effect on the benefit was shown by Fu et al. (Reference Fu, Liu and Wang2021) for the reuse of system models. Mendieta et al. (Reference Mendieta, La Vara, Llorens and Álvarez-Rodríguez2017) already discussed the tool-specific obstacles coming along with XML and SysML model recycling. Nevertheless, the presented classification system offers a first basic structure for modelling guidelines and recommendations. Especially with SysML v2, which is no longer based on UML and offers new potentials, for example, through changing the restriction of the XML exchange format by an accessible API.

The different classes distinguish fundamentally different approaches for the further reuse of SysML models with different aims and necessary efforts. While model transformations might aim to transfer individual diagrams into domain-specific models, such as shown in the transfer of electrical system designs between the Siemens tools Capital Systems Capture and System Modelling Workbench (Hick et al. Reference Hick, Sanladerer, Trautner, Ryan, Piguet, Wilking, Horber, Faustmann, Kranabitl, Kolleger, Bajzek, Schleich and Wartzack2023), others will require the collection of information from the whole model. Especially the transfer of the visual layout of a diagram into domain-specific tools will cause tremendous effort to develop certain modelling guidelines to ensure a transfer without information loss and, most importantly, a benefit with the domain or discipline-specific model. Furthermore, a synchronization requires a harmonized modelling approach throughout the whole model. This shows that the creation of the methodical approach depends on the aim and the corresponding class that was assessed for the utilization of the system model.

This basis of considerations for the methodical approach is enriched by viewing the life cycle stages. Engineers who want to utilize system models will be confronted with several challenges regarding the life cycle of the system. The model maturity significantly differs throughout the development until the instantiation of the system. Therefore, the actual point in time for making use of and benefit from the utilized model might differ from the point in which the system model is created. This leads to two aspects coming along with a life cycle related consideration for the utilization. First, the life cycle stage itself in which the model is utilized. A utilized system model for a concept phase will be based on a low-matured model foundation. Furthermore, it has different aims. Models, which are being used in later stages, will be confronted with a different level of detail regarding the system model or the connected domain-specific models. The second important aspect is considering the difference between utilization and creation of the model. This is a crucial consideration for models that decay over time and do not represent, for example, the behaviour of a system throughout the period of use. This decay needs to be considered. Approaches must integrate this dynamic to represent the stage of a system, in which the system model is utilized and not only the state in which the model is created. Summing up, methodical approaches have to consider these two differentiations for the utilization.

An additional aspect for considerations towards methodical approaches is the differentiation of use cases within the utilization. For example, utilization approaches for the Digital Twin use case are mainly focused on the operation phase of the system predefined by the use case that is describing a predominantly maintenance- and usage-oriented concept. In fact, specific approaches, such as deriving specified documents, for example, a FMEA can help to define a very specific guideline for the utilization, such as seen in several publications (Girard et al. Reference Girard, Baeriswyl, Hendriks, Scherwey, Müller, Hönig, Lunde, Baraldi, Di Maio and Zio2020; Hecht et al. Reference Hecht, Chuidian, Tanaka and Raymond2020). Some of the specific approaches can be clustered together with the classes of the utilization. However, as SysML application throughout enterprises and sectors can be affected by the usage of own profiles and adaptions. Specific guidelines for these might be an inspiring example. But they do not necessarily provide a generic approach for supporting enterprises in the attempt of utilizing their system models.