1. Introduction
In engineering design, models of the product under design are essential tools for designers (e.g., Eckert & Hillerbrand, Reference Eckert and Hillerbrand2022; Eisenbart et al., Reference Eisenbart, Gericke and Blessing2011), from the first hand-drawn sketches of the product to close-to-production prototypes and simulation models. These product models represent different aspects of the technical system, contain different design knowledge (Reference Hubka and Edersee Hubka & Eder, 1990), and fulfil specific purposes (Reference Buur and Andreasensee Buur & Andreasen, 1989). In the case of the Design Structure Matrix (DSM), for example, such a purpose may be the representation of the system elements and their interactions (Reference Eppinger and BrowningEppinger & Browning, 2012), thereby containing design knowledge about the system’s structure. A product model is understood in this contribution as “a human-made, pragmatic, reductive representation of a technical product carrying attributes similar to the modeled original for the purpose of depicting its function, behavior, or structure, or for analyzing its behavior” (Paehler & Matthiesen, Reference Paehler and Matthiesen2024, p. 1). Due to the representation of different aspects, different design knowledge and different specific purposes, multiple product models are necessarily used within a design process (e.g., Ehrlenspiel & Meerkamm, Reference Ehrlenspiel and Meerkamm2017; Maier et al., Reference Maier, Wynn, Howard, Andreasen, Chakrabarti and Blessing2014).
The use of multiple product models within a design process requires frequent switching between them, resulting in a sequence of product models in the course of the design process (e.g., Andreasen, Reference Andreasen1994; Husung et al., Reference Husung, Weber, Mahboob, Krause and Heyden2022). As such, by improving the switching between the product models, the design process as a whole can be accelerated (Reference Jones, Snider and HicksJones et al., 2020). Improving the switching includes increasing the design knowledge passed between product models, i.e., increasing the design knowledge used or integrated from one product model when building another product model. This ensures that the design knowledge is also available in the further course of the design process through the subsequent product models or is available in multiple product models during their iterative, parallel use. If the design knowledge is not passed on and thereby not included in the following product models, it may have to be laboriously acquired again at a later point in the design process. To support the passing on of design knowledge between product models, links between them can be established. In the case of separate product models, linking relates to how the output or design knowledge of one product model can be used as input for the next product model (see for example Grauberger et al., Reference Grauberger, Goetz, Schleich, Gwosch, Matthiesen and Wartzack2020; Li et al., Reference Li, Horber, Grauberger, Goetz, Wartzack and Matthiesen2024; Wilschut et al., Reference Wilschut, Etman, Rooda and Vogel2018). The individual product models remain unchanged. This type of linking thus differs from approaches which integrate several product models into a higher-level structure or language such as SysML (see for example Drave et al., Reference Drave, Rumpe, Wortmann, Berroth, Hoepfner, Jacobs, Spuetz, Zerwas, Guist, Kohl, Syriani and Sahraoui2020; Mahboob & Husung, Reference Husung, Weber, Mahboob, Krause and Heyden2022). Linking product models therefore allows design knowledge to be passed between product models, improving the efficiency of a design process.
In a literature review, in which links between product models were analysed based on the descriptions of the inputs and outputs, only a few links could be identified for multiple product models, leaving it open how these could be integrated into a design process (Reference Paehler and MatthiesenPaehler & Matthiesen, 2024), indicating an overall need to identify further links. And while links based on standardised data interfaces are intensively researched and used in some cases, e.g. for computer-aided, quantitative models (e.g., Jacobs et al., Reference Jacobs, Konrad, Berroth, Zerwas, Höpfner, Spütz, Krause and Heyden2022; Wong & Wynn, Reference Wong and Wynn2023), especially links for qualitative product models remain missing. For these, enabling the passing on of design knowledge when switching product models and thus the efficient combination of product models in design processes offers potential, as publications on pairs of linked product models demonstrate (e.g., Grauberger et al., Reference Grauberger, Goetz, Schleich, Gwosch, Matthiesen and Wartzack2020; Gu et al., Reference Gu, Hu, Peng and Li2012). But linking product models poses a challenge for researchers due to the variety of different product models, their types of representation, and the design knowledge represented. Further, it is complicated as product models themselves, such as the DSM (Reference Eppinger and Browningsee Eppinger & Browning, 2012), Working Space Model (Reference Beetz, Schlemmer, Kloberdanz and Kirchnersee Beetz et al., 2018), or Tolerance Graph (Reference Goetz, Schleich and Wartzacksee Goetz et al., 2018), as well as their inputs and outputs, are often described differently. To derive links nevertheless, previous publications used individual, non-systematised procedures (e.g. in Grauberger et al., Reference Grauberger, Goetz, Schleich, Gwosch, Matthiesen and Wartzack2020; Gu et al., Reference Gu, Hu, Peng and Li2012). Consequently, the problem is that it is a challenge for researchers to derive the links between product models required for the passing on of design knowledge.
1.1. Research focus
It is necessary to pass on design knowledge through links between product models to efficiently utilise the design knowledge built up throughout a design process. Yet, researchers lack support for deriving new links between product models. The aim of this paper is therefore to provide a systematic approach that researchers can use to derive new links between product models in engineering design research, such as the DSM, Tolerance Graph, or Working Space Model. This approach shall enable researchers to increase the number of links between new or existing product models and other product models to support the passing on of design knowledge during the sequential or iterative use of product models and thus increase the efficiency of design processes.
The systematic approach is to be developed based on publications in which links between product models have been identified. Section 2 therefore first analyses how these publications proceeded to derive the respective links. The analysis focusses on the identification of recurring steps as basis for development of the systematic approach. Section 3 then presents the systematic approach based on the analysis and further literature. To illustrate the application and benefit of the approach, it is applied in an illustrative case in Section 4. In this illustrative case, for two product models for which the possibility of a link is already known from the literature, the systematic approach is used to derive a link and the result is compared with the literature. Subsequently, the systematic approach and the illustrative case are discussed in Section 5 and the implications are concluded in Section 6.
2. Analysis of how links between product models are derived in the literature
As a basis for the development of the systematic approach, how links between product models are derived and presented in existing literature was analysed. The derivation and presentation were analysed both, as they cannot be separated based on the publications. For the analysis, seven exemplary, typical publications were selected in which different product models were linked with each other. These were then analysed concerning the steps of derivation and presentation used in each of the publications. Table 1 provides an overview of the results of the analysis.
Table 1. Steps used to derive and present links between product models in the literature in ascending order from left to right according to the order in the publications
As the result of the analysis in Table 1 shows, the same steps were used in five of the seven publications: The combination of the description of the link on a theoretical basis with subsequent evaluation of the link by applying it to an example case. The theoretical basis is usually derived from the state of research on the individual product models to be linked (Reference Albers, Matthiesen, Revfi, Schönhoff, Grauberger and Heimickee.g., Albers et al., 2019) or a literature review in which several modelling approaches and their limitations are examined (Reference Bonev, Wörösch, Hauksdóttir and Hvame.g., Bonev et al., 2013). However, no step between the theoretical basis and the description of the relationship is presented in the publications, causing the steps in Table 1 to begin with the description in the case of these publications. In other words, the (intermediate) results are visible, but not the activities that were carried out between them. It is therefore not possible to draw conclusions from the publications on the basis of the analysis as to how in detail the researchers derived the links. One possible explanation is that the researchers already knew at least one of the product models to be linked very well, as they themselves had previously published on this product model (e.g., Grauberger et al., Reference Grauberger, Goetz, Schleich, Gwosch, Matthiesen and Wartzack2020; Müller et al., Reference Müller, Panarotto and Isaksson2021). Also, in Grauberger et al.’s Reference Grauberger, Goetz, Schleich, Gwosch, Matthiesen and Wartzack(2020) example case for evaluation, there is a standardized nomenclature for naming the parts of the technical system, which is not presented as part of a derivation but contributes significantly to identifying the link. This suggests undescribed steps. Thus, five of the seven publications have the same two steps, but the researchers focus on the description and evaluation of the link rather than the derivation.
Vogel-Heuser et al.’s Reference Vogel-Heuser, Böhm, Brodeck, Kugler, Maasen, Pantförder, Zou, Buchholz, Bauer, Brandl and Lindemann(2020) approach differs from the most frequently used approach in that the application example is first introduced and the link is then explained using the example. The evaluation then takes place on a theoretical basis. The link is presented tangibly with reference to the application example, but it also remains unclear where the knowledge for the link comes from. In contrast to the two procedures described so far, Keller et al. Reference Keller, Alink, Pfeifer, Eckert, Clarkson and Albers(2007) already built the separate product models for an application example before linking and then derived the link based on the findings. This reveals the way in which new findings on the product models were initially collected through the shared example case. In the subsequent evaluation based on the same use case, the product models that had previously been built separately were used as a reference to emphasize the differences. Keller et al.’s Reference Keller, Alink, Pfeifer, Eckert, Clarkson and Albers(2007) approach therefore distinguishes itself from the other approaches analysed, as the initial modelling with the separate product models for a shared example case makes it possible to understand how findings for linking the product models were obtained. However, the necessary step between creating the separate product models and linking them is missing.
3. A systematic approach to deriving links between product models
This section presents a systematic approach to deriving links between product models. It is based on the findings from the analysis in Section 2, in particular the following findings:
-
Building the product models to be linked for a common example case allows for findings on the product models in addition to the theoretical basis from the current state of research.
-
A consistent nomenclature that standardizes the labelling of the parts of the technical system in the example case can potentially support the identification and traceable presentation of the link.
-
The link should be applied to an example case and evaluated through this application in the end. If the product models were previously created separately for the same use case, these can be used as a benchmark for evaluating the link.
-
The identification of the linking possibility and its assessment that the link is indeed feasible, as central steps of the derivation, are not described in detail in the analysed publications. It is therefore not possible to simply refer back to a step used there; instead, additional literature must be consulted.
The systematic approach shown in Figure 1 is based on these findings. It begins at the point where there are two product models at hand that are to be linked as added value is expected from their combination or they are to be used together efficiently in a mutual design process. The basic assumption at this starting point is that the two given product models can be linked with each other on the basis of the data/information/knowledge required for their building or during modelling and the data/information/knowledge resulting from the product models. To investigate this basic assumption, the following steps are taken, which are presented in detail later on. At first, in step 1 the product models to be linked are built in the context of a shared example case. These are then described in a standardized way at the most detailed level of abstraction possible to obtain a comparable description in step 2. These standardized descriptions are analysed in step 3 with regard to recognizable links between the product models. If a link is found within the standardized description, it is attempted to verify it in step 5 by means of the product models in the example case. If step 5 is successful and the link can be verified, the basic assumption is confirmed and the approach is completed. If no link was previously found in step 3 or the link found could not be verified in step 5, it is attempted to establish a link through a description on a higher level of abstraction. To do this, it is first decided whether a variation of the abstraction level is possible, which is particularly relevant after several iterations. If the answer is yes, the variation is carried out in step 4 and subsequently, step 3 is carried out again and so on. If no (further) variation of the description is possible, the approach is aborted without linking and the basic assumption could not be confirmed. Thus, the approach is an iterative, systematic approach in which it is attempted to confirm the basic assumption through each iteration until no further iteration can (or wants to) be undertaken.
Figure 1. Overview of the systematic approach to deriving links between product models
-
Step 1: Build the two product models for a common design problem
In this first step, a design problem of a technical example system is first selected as an example case. This can be, for example, the design problem from which the need for linking the product models has arisen. The prerequisite for the design problem is that both product models must contribute to solving the problem and that the problem cannot be solved by one of the product models alone. The two product models to be linked are then built for the chosen design problem. A standardised nomenclature for the assemblies/parts/surfaces/functions/etc. of the example system is introduced and used during the modelling process. The nomenclature may have to be extended during the modelling process if it emerges during the building of the product models that elements of the example system are not yet included. At the end of this step, the two product models for the common design problem are thus available with a common nomenclature.
-
Step 2: Standardise the descriptions of the product models
A standardised textual description is used to help make links between product models recognisable, even though the product models themselves may have different types of representation (e.g., textual, graphical or tabular). For this purpose, the product models created in step 1 are presented according to the stances for product models according to Paehler et al. Reference Paehler, Grauberger and Matthiesen(2023)(see Figure 2). The stances are referred to as they offer a structured vocabulary to describe product models in a comparable way. However, the classification-oriented stance does not contain any concepts that enable conclusions to be drawn about the data/information/knowledge of a product model. Nevertheless, the functionality- and message-oriented stances provide a comparable description for linking product models and are therefore used as a template within the systematic approach. Therefore, within this step, the concepts of these two stances (input, modelling, etc.) are filled out according to the respective descriptions of the terms. In the first iteration, the intention is to achieve a description at the most detailed level of abstraction possible. This means, for example, that relationships between elements of the technical system are specified using the nomenclature of the respective parts. By the end of this step, a template is completed for each product model, consisting of a filled-out functionality- and message-oriented stance.
Figure 2. The functionality- and message-oriented stances provide a way to describe product models comparably for their linking (Reference Paehler, Grauberger and MatthiesenPaehler et al., 2023)
-
Step 3: Analyse the descriptions with regard to possible links
In this step, the standardised descriptions from step 2 are utilised to try to identify links. If the abstraction level has already been varied (see step 4), several filled-out templates are available as descriptions, all of which must be compared, also crosswise across different abstraction levels. To do this, the descriptions are analysed with regard to the following two questions:
a) Is there an overlap between the data/information/knowledge resulting from one product model and that which can be incorporated into the other product model? To answer this question, the ‘captured construct’ and the ‘output’ of one product model are compared with the ‘input’ and ‘modelling’ of the other product model and vice versa. An overlap must occur in only one of the comparisons for the question to be answered with yes.
b) Is there an overlap between the representation of the data/information/knowledge between the two product models? To answer this question the ‘medium’ and ‘modelling language’ between the two product models are to be compared. Both comparisons must be in agreement to answer the question with yes.
The answers to the two questions result in different outcomes with regard to the linking of the two product models. Figure 3 shows the decision tree, which shows the respective outcomes depending on the answers to the two questions. Thereby, at the end of this step, there is either a link or there is not.
Figure 3. Decision tree, whether or not a link has been identified based on the questions a) and b)
-
Step 4: Vary the level of abstraction of the descriptions
This step is necessary as the product models may be described at different levels of abstraction in step 2 due to the product models themselves and therefore no link can be identified directly in step 3. By varying the level of abstraction of the descriptions and analysing them across levels in step 3, a more holistic basis is created for the potential identification of a link. To this end, the description on the highest available abstraction level per product model is taken and each concept within the description (input, modelling, etc.) is abstracted to the next higher abstraction level (if possible). In the case of ‘modelling language’, for example, this can mean abstracting model-specific symbols that represent a specific function to ‘symbolic representation of the function’. The results of this step are therefore the existing templates together with another filled-out template as a description of each of the product models.
-
Step 5: Verify the link using the design problem
The link identified in step 3 using the textual descriptions is brought back into the design problem and verified therein. For this, the two product models are rebuilt within the example case. However, in contrast to step 1, they are not built independently of each other, but the product model that provides data/information/knowledge is built first. Subsequently, it is attempted to pass the data/information/knowledge into building the other product model according to the identified link. In this way, the application is used to verify the feasibility of the link. However, it is not possible to conclude from the application in the example case that the link works universally. Consequently, there is a verified link at the end or it could not be verified.
4. Exemplary application of the systematic approach
In the following, the systematic approach for deriving links between product models is applied to an example to demonstrate the steps of the approach. The Contact and Channel Model (C&C2-M) according to Matthiesen et al. Reference Matthiesen, Grauberger, Hölz, Nelius, Bremer, Wettstein, Gessinger, Pflegler, Nowoseltschenko and Voß(2018) and the Tolerance Graph according to Goetz et al. Reference Goetz, Schleich and Wartzack(2018) were selected as product models for this exemplary application. The C&C2-M is a product model that uses predefined model elements according to basic hypotheses to analyse the relationship between the embodiment and function of a technical product (Reference Matthiesen, Grauberger, Hölz, Nelius, Bremer, Wettstein, Gessinger, Pflegler, Nowoseltschenko and VoßMatthiesen et al., 2018). The Tolerance Graph is used for early tolerance analysis and represents a technical system as a graph that is enriched with additional information for tolerance analysis (Reference Goetz, Schleich and WartzackGoetz et al., 2018). Individual tolerance chains are extracted from the Tolerance Graph for analysis, showing the relevant geometry elements and associated tolerances that affect the function (Reference Goetz, Schleich and WartzackGoetz et al., 2018). These product models were selected as it is already known from Grauberger et al. Reference Grauberger, Goetz, Schleich, Gwosch, Matthiesen and Wartzack(2020) that a link is possible, so there is a benchmark.
-
Step 1: Build the two product models for a common design problem
As described, the C&C2-M and the Tolerance Graph are to be linked using the systematic approach. Consequently, the basic assumption at the start is that the C&C2-M and the Tolerance Graph can be linked with each other on the basis of the data/information/knowledge required for their building or modelling steps and the data/information/knowledge resulting from the product models.
To investigate this basic assumption, an assembly problem of an angle grinder was selected as an example case. An angle grinder is a hand-held power tool that utilizes a fast-rotating disc tool for grinding and cutting workpieces. A bevel gear between the motor and the output shaft on which the disc tool is mounted is essential for its function. The design problem in this example case is that the output shaft can sometimes not be mounted due to a manufacturing-related misalignment of the output shaft in relation to the housing. The two product models are to contribute to finding out what causes the assembly of the output shaft to be prevented in these cases. The C&C2-M is intended to contribute to which parameters influence the function depending on the misalignment, and the tolerance graph is intended to contribute to the influencing tolerances.
The two product models are first built for the example case described. For more information on how to build these product models, please refer to their respective publications. Figure 5 (left part) shows the two resulting product models. The C&C2-M was built upon a simplified schematic sketch of the bevel gear (shown in the background). Within the Tolerance Graph, the extracted functional tolerance chain is shown in green. The key characteristic, the parameter that is decisive for the fulfilment of the function, is shown in red. Both product models were created using the same nomenclature, so the labelling within the C&C2-M corresponds to the labelling within the Tolerance Graph. The schematic representation labelled with the nomenclature is shown in the legend.
-
Step 2: Standardise the descriptions of the product models
In this step, the previously created product models are transferred to the standardised textual descriptions. Each of the descriptions was carried out aiming for the most detailed level of abstraction possible, for example, the output of the C&C2-M is described by the contact surface between two parts based on the nomenclature.
-
Step 3: Analyse the descriptions with regard to possible links
The descriptions of C&C2-M and Tolerance Graph are analysed with regard to questions a) and b) from step 3 in Section 3. As question a) is answered with no based on the current descriptions, no link is identified according to the decision tree in Figure 3. In the further process of the approach as shown in Figure 1, ‘Was a link found?’ is hence answered with no, but ‘Possible to vary the description?’ is answered with yes, as the textual descriptions are both still on a very detailed abstraction level. The next step is therefore step 4.
-
Step 4: Vary the level of abstraction of the descriptions
The concepts within the descriptions are all individually attempted to be abstracted to the next higher level of abstraction. Figure 4 shows the resulting textual descriptions of the two product models. In the case of the ‘output’ of the Tolerance graph, for example, the previous description ‘key characteristic’ is abstracted to ‘location of the function-determining parameter’ based on the understanding of the term according to Goetz et al. Reference Goetz, Schleich and Wartzack(2018). For the ‘medium’, for example, no abstraction is possible for either product model, so these concepts remain as before. Hence, the textual descriptions of the two product models after the variation of the abstraction level and thereby in their second iteration are achieved.
Figure 4. The textual description of the product models after their variation (step 4) and the resulting recognisable link (step 3, iteration 2)
Step 3, iteration 2: Analyse the descriptions with regard to possible links
The textual descriptions of the two product models are analysed again. As there are now two descriptions per product model, the analysis is carried out both between the descriptions of the second iteration and between the descriptions of the first and second iteration. When comparing the ‘output’ of the Tolerance Graph in the second iteration with the ‘modelling’ of the C&C2-M in the first iteration, an overlap is apparent: By providing the ‘location of the function-determining parameter’, the ‘output’ of the Tolerance Graph provides information for defining the boundaries for function fulfilment in the C&C2-M. Accordingly, question a) from step 3 is answered with yes. Question b), however, is answered with no, as only the ‘medium’ overlaps, but not the ‘modelling language’. Thereby, according to the decision tree in Figure 3, a link has been identified where processing of the data/information/knowledge is required due to the representation. As a link has been identified, step 5 is next.
-
Step 5: Verify the link using the design problem
Bringing the identified link back into the example case, the Tolerance Graph is built first, as it is intended to provide information for the C&C2-M. The Tolerance Graph is therefore built identically to step 1 and thereby remains unchanged. The C&C2-M is built afterwards. In contrast to the product model built in step 1, this time it is built for the area around the ‘location of the function-determining parameter’, as it results from the output of the Tolerance Graph. In this way, only a smaller area of the technical system is modelled in the new C&C2-M, but more precisely resolved. Figure 5 shows the new, refocussed C&C2-M resulting from the link. This means that the link between the two product models has been verified successfully. The basic assumption can therefore be confirmed with respect to the example case.
Figure 5. The C&C2-M and the Tolerance Graph before (step 1) and after (step 5) the linking
5. Discussion
The systematic approach outlined combines the findings from the analysis of publications in which links were derived and presented with further literature, particularly with regard to the standardised, textual description of product models. In doing so, the systematic approach provides practical, reproducible steps for researchers to support them in deriving a link between two product models in engineering design research. In comparison to the publications analysed in Section 2, the step of derivation is thus described in more detail and at the same time the already established steps are adopted. This enables the derivation of further links between product models that are not yet known in the current state of research thereby strengthening the passing on of design knowledge within design processes. Furthermore, the analysis of the publications in Section 2 did not show such a traceable description of the derivation of a link as the approach potentially enables. In this way, the approach also offers the potential to increase the traceability of the derivation of links within the publications. Nevertheless, the approach requires that there are two product models to be analysed with regard to a possible link at hand; it does not support the search for two suitable product models. The selection of the product models to be linked is hence still left to the expertise of the researchers, as in the current state of research. Furthermore, if two product models are selected that represent the technical system at distinct levels of abstraction, which means that there is no overlap between the two product models in the nomenclature of the system elements, it is unlikely that a link can be found due to the textual approach used in the analysis in step 3. In this respect and also with regard to the building of the selected product models within the approach in step 1, considerable expertise from the researchers is still required.
6. Conclusion
In this contribution, a systematic approach to deriving links between product models for design researchers was outlined and applied successfully to an illustrative example, linking the C&C2-M and Tolerance Graph. This approach offers researchers support in linking new or existing product models for strengthening the passing on of design knowledge between product models within a design process. Thereby it contributes to the efficient use of different product models within a design process and offers the potential to increase the density of known links within the body of product models in the state of research in the long term.
As the approach was initially developed and outlined in this contribution, it requires further investigation in the future, particularly regarding its generalisability. Therefore, it should be applied to other pairs of product models, both pairs where links are already known and pairs where no links are yet known, to evaluate the results of the approach, its usefulness for researchers, applicability, and limitations. Further, investigations on how to preliminarily classify product models to support the selection of product models worth considering to be linked would reduce the dependability on the expertise of researchers. Based on such investigations, the systematic approach can be further developed towards refining the steps or adding additional steps to ensure its usefulness for researchers in engineering design research and to strengthen the passing on of design knowledge in design processes.
Acknowledgement
The research described in this manuscript has been funded by the German Research Foundation (DFG) within the project “Research map of models for modelling embodiment and function of technical systems to support linked model usage” (446789859). The support by the German Research Foundation (DFG) is gratefully acknowledged.
Open access
