1 Introduction

Product development is faced with the great challenge of covering an ever-increasing external variety demanded by the market, which is caused by megatrends such as individualization (Krause and Gebhardt 2018). Conversely, a high level of product standardization offers the potential to achieve higher productivity and shorter throughput times with more automated processes through reduced process complexity. Modular product architecture design represents an approach from the product development point of view for overcoming this conflict of objectives. The goal is to control the variance of variants, which is regarded as a central field of application in a company (Krause et al. 2021).

Modularity in this context is a gradual property of product architectures. It can be described by the properties and characteristics of modularity (Hackl et al. 2020; Salvador 2007), where the subdivision into properties and characteristics is based on Weber (Weber 2007). The properties of modularity are commonality and combinability. Commonality means that a module can be used several times in different or the same product variants. This is made possible by the characteristics interface standardization and oversizing in order to be able to use modules several times. In addition to interface standardization, combinability is also made possible by decoupling and function binding. Commonality makes the reduction of the internal variety possible whereas a large external variety can be made possible by the combinability (Hackl et al. 2020). Modular product structuring—also called platform design—and variant management is the subject of current research at various research institutes. Bonvoisin et al. have focused on drivers, design principles and metrics of modularization (Bonvoisin et al. 2016). Otto et al. compared several modularization methods and generated a global view on the approach of modularization methods. The methods existing in the literature were assigned to different activities in order to clarify, which method supports in which phase of the product family development (Otto et al. 2016). Krause et al. likewise give an overview of methods for the development of modular product architectures and discuss the potentials and limits of modularization (Krause et al. 2018). Gebhardt et al. focus on the strengthening of knowledge transfer to industry. They define the platform strategy, the module strategy and the common parts strategy and provide an adapted overview of methodical approaches (Gebhardt et al. 2016).

The development of modular product architectures is increasingly holistic. The approaches often pursue a systemic view, which aims at the analysis and synthesis of technical products. According to Bender, this allows overall tasks to be broken down into subtasks, and different technical disciplines can be integrated using this approach (Bender et al. 2018). Interface consideration between different disciplines also takes place. For example, the integrated product generation model (iPeM) follows the goal of creating an interface between process management and product development (Albers et al. 2016). Further application cases for integrative approaches are product service systems (Rennpferdt et al. 2019) or the linking of structural optimization and modularization (Hanna et al. 2020).

As already indicated, many life phases and disciplines are involved in the development of modular product architectures. Module drivers from different life phases are integrated in modularization methods, in order to consider product-strategic aspects in the module formation. Impacts and effects of modularization on all life phases could also be identified (Hackl et al. 2020; Schwede et al. 2020a). Currently, approaches for the selection of suitable product architecture concepts (Richter et al. 2016) or also the selection of modularization methods (Schwede et al. 2019b) are researched in dependence of impacts.

Current research is investigating various trends in the field of modular product architecture. For example, methods are being developed in which future changes in internal and external variety are taken into account at an early stage in the development processes (Greve et al. 2020b). In this context, the scenario technique can also be used (Gausemeier et al. 2000) in an adapted way. The trend towards individualization poses a challenge for modular product development. Gräßler developed a methodology for the redevelopment of customer relevant modular kits (in German called “Baukasten”), which considers continuously variable components (Gräßler 2004). It also focuses on the extension of already known methods for the design of variable individualization options. Current research in this area deals with individual performance fulfilment through product individualization (Kuhl et al. 2021). Individualization also plays a role in sales. With the help of product configurators, individual customer requirements can be taken up and implemented (Rennpferdt et al. 2020a; Seiler et al. 2020b). The consideration of future product characteristics and also the consideration of specific customer requirements lead to necessary product changes and thus to an increasing variance-induced complexity (Lindemann 2009), which causes indirect costs in different life phases. Thus, the calculation of complexity costs plays a major role. By a cost forecast these can be considered early in the course of the concept selection (Ripperda and Krause 2015). The structured treatment of the complexity of product and process is supported by a situational use of development methods and product models (Lindemann and Ponn 2011).

The holistic approaches and the trends presented have in common that more and more knowledge is built on top of each other in the course of methodical modular product development and must be linked with each other in the most diverse ways. This leads us to another digital trend in product development: Model-Based Systems Engineering (MBSE).

In order to thematize MBSE, a distinction must first be made between it and Model-Based-Engineering (MBE). If models represent an integral part in a development process, one speaks of MBE. The goal of MBE is to increase the effectiveness of the engineering as, for example, inputs are generated from these models in individual steps of the development process (Paetzold 2017). Software plays a major role in depositing the process with models (Liebel et al. 2018). Software extends standardized 3D representations with additional product information, which is directly related to the deposited models. MBSE can be understood as a sub-discipline of MBE. This sub-discipline includes all models that support the aspects of systems engineering. MBSE describes an interdisciplinary approach to the description of technical systems. The description proceeds thereby mostly from requirements, which result from the underlying use cases. Alt describes the core of the modeling process according to the scheme of Input-Processing-Output (Alt 2012; Delligatti 2013; Walden et al. 2015). Requirement engineering represents a major activity within MBSE. Implicit requirement management must of course take place throughout the entire product development process (Göhlich and Fay 2021). Due to the increasing scope of products and company processes, MBSE is finding its way into a wide variety of industries.

Nowadays, it is used more and more to represent complex systems such as products, which contain elements from different disciplines. In addition, process steps with many participants are modeled. Through modeling, a process-accompanying system model can be developed that visualizes the dependencies of different stakeholders (Riedel et al. 2020). In order to fully exploit the potential of data linking on the company side, suppliers are increasingly demanding the use of MBSE. However, continuous process support with MBSE is very costly and not necessarily profitable for suppliers. However, as soon as MBSE is established and anchored in the processes, the modeling does not cause any additional or duplicate work, and the data and models are used and linked consistently, the benefit should increase (also for suppliers). Wilking et al. are investigating the extent to which the additional effort caused by the use of MBSE can be compensated (Wilking et al. 2020). Furthermore, the goals to be achieved through the use of MBSE should be clearly defined in order to make the success of MBSE measurable (Kößler and Paetzold 2017). In addition to the application of MBSE in industry to support processes, this approach also represents an interesting option for managing the data relationships in methodical product development. The associated potential of model-based data links fits in with the increasingly integrative approach in the field of modular product architectures. Initial solutions in this area are already present in the literature.

MBSE is used, for example, to enable a consistent representation of modular kits. This means that knowledge can be used across generations (Albers et al. 2019). MBSE can also help in the new development of modular product families to use existing knowledge for further product variants and to make changes consistently traceable during development (Küchenhof et al. 2020). Configurator systems can also be strengthened by MBSE. By storing system models, optimal variants can be configured while taking user goals into account (Wyrwich et al. 2020). In the applications presented, SysML is mainly used as the modeling language to model data relationships. In addition, the presented applications make clear that modeling with SysML in the sense of MBSE as a competence is increasingly relevant also in the education of engineers. For this purpose, e.g. the Karlsruhe SysKIT Approach was developed (Matthiesen et al. 2014).

As can be seen from the research landscape presented, there are many new research trends in the context of modular product architectures, making the topic increasingly comprehensive. First approaches show the potential of MBSE to support product development. Besides the presented application examples, especially methodical product development can benefit from MBSE. In this book chapter, the application of SysML in methodical product development is presented on the modeling of method units of the Integrated PKT Approach for the Development of Modular Product Families (abbr.: Integrated PKT Approach). This is based on a consistent meta model of product data developed specifically for this purpose.

2 Integrated PKT Approach for the Development of Modular Product Families

The development of the Integrated PKT Approach is based on the fundamental idea of the conflict of objectives described at the beginning between desired external variety and required internal variety (Fig. 14.1). The Integrated PKT Approach takes into account diverse strategies and approaches of variant management (Greve et al. 2020a; Krause and Gebhardt 2018).

Fig. 14.1
figure 1

Integrated PKT Approach for the Development of Modular Product Families (Krause and Gebhardt 2018)

Full size image

The current trends in the field of modular product architectures are addressed in different method units (Greve et al. 2020b). Method units are continuously being developed in the application fields of aerospace, mechanical and plant engineering, and medical technology (Rennpferdt et al. 2020b) and tested in industrial collaborations (Rennpferdt et al. 2020a). The individual method units can be combined with each other in a way that is specific to the application in order to provide customized support for companies that want to reduce their internal variety (Krause and Gebhardt 2018). This approach is characterized in particular by the fact that the targeted redesign of product architectures takes place not only at the conceptual level. The approach also provides a constructive redesign, a modification or even a redesign of components in order to reduce variant-related complexity. In addition, it is a workshop-based approach in which experts with their special product knowledge from different disciplines are integrated. In the course of this, discussions in project teams are simplified through visualizations of data relationships. The basis of the Integrated PKT Approach is the Design for Variety and Life Phases Modularization. Design for Variety can be used to achieve a better starting point for Life Phases Modularization. It combines technical-functional and product-strategic aspects for modularization. The aim is to achieve a modular product architecture that is geared to strategic, company-specific and product-specific benefits (Krause and Gebhardt 2018).

2.1 Design for Variety and Life Phases Modularization

The method unit Design for Variety can be understood as preliminary stage for the Life Phases Modularization. The implementation of both method units is supported by tools (Fig. 14.2).

Fig. 14.2
figure 2

Tools of the method unit Design for Variety (top and middle; according to Seiler and Krause 2020) and tools of the method unit Life Phases Modularization (bottom; according to Greve et al. 2020a)

Full size image

The goal of Design for Variety is to arrange components variant-oriented, whereby only a small part of the components is to depend on the customer relevant properties (Kipp et al. 2010). In a first step, the external variety is taken up with the help of the Tree of External Variety (TEV) (Fig. 14.2, upper left), in which the customer relevant properties and their characteristics are recorded. For the representation of the variety of the functions, the Product Family Function Structure (PFS) (Fig. 14.2, upper right) is created (Kipp et al. 2010). The representation of the internal component variety of a product family is done in the Module Interface Graph (MIG) (Fig. 14.2, middle left).

The MIG shows a reduction of the design to the essentials. Like the other tools, the MIG presents the information of all product variants in the product family. The components are shown in a simplified form. The variety of the components is determined by the color of the filling in the visualizations. Standard components (white) exist in only one version within the product family, while variant components (gray) exist in several defined versions. Optional components are marked by a dashed frame. The components are connected to each other via color-coded flows (Gebhardt et al. 2014; Krause and Gebhardt 2018). The variant-oriented design of the product architecture itself is done with the help of the Variety Allocation Model (VAM) (Fig. 14.2, middle right). This model shows the connection between the customer relevant properties, functions, working principles and components and makes it possible to revise these by applying the four ideals of variety-oriented product structuring with the aim to reduce the variant component and to increase the standard components (Kipp et al. 2010). Within the scope of the method unit Life Phases Modularization, technical-functional and product-strategic views are taken into account (Greve et al. 2020a). First, the modularization of the components takes place from a technical-functional view. For this purpose, the heuristics according to Stone et al. (2000), for example, are applied to the MIG. For the product-strategic modularization of the individual life phases of a company, Network Plans (NP) are provided in which modules are formed on the basis of life phase-specific module drivers (Fig. 14.2, bottom left). A special case is the life phase sales, in which the customer relevant properties are used as additional module drivers. The modularization concepts of the individual life phases are then collected in the Module Process Chart (MPC) and subsequently harmonized (Fig. 14.2, bottom right).

2.2 Interim Summary—Deficits of the Document-Based Approach

For the execution of the individual method steps, different information and also different tools are needed. The tools were developed for the visualization of the data correlations. Tools in the context of methods are instruments that are intended to support the execution of method steps (Gebhardt and Krause 2016). These tools differ in terms of versioning. For example, the TEV only represents an actual state and is therefore to be regarded as static. In the VAM, among other things, data correlations are changed in the tool during the execution of the corresponding method step, whereby a new version of the VAM is created. The modification of the tools is currently done manually on printed posters representing the tools. This also makes it difficult to map large product families. Therefore, the mappable limit for the manual approach is about 80 components.

In the method application, the required information is thus only stored in paper documents and tools of individual method steps are not linked to each other. Precisely because product strategy aspects are also included in Life Phases Modularization, knowledge from a wide range of disciplines is required for individual method steps, which means that many different disciplines are involved in the execution of the method steps. In addition, not only single product variants are considered in the methods, but entire product families. Furthermore, some information is taken up again and again in the different tools. An example of this are the components. These appear first in the MIG, where they are linked with other components via flows. In the VAM the variant components are linked afterwards with the working principles. They reappear in the technical-functional modularization in a next version of the MIG and then also in the NPs in the individual life phases, which are created in parallel. They can also be found several times in the MPC. Due to the fact that a lot of different and also recurring information is required in the individual steps, the documentation of the individual steps and also the individual results are very important in order to be able to trace back the execution afterwards and accordingly also to be able to understand it (Hanna et al. 2018). If the method units are carried out based on individual documents that are not linked to each other, data consistency is not ensured and redundant information sources can occur. Due to the fact that the method units Design for Variety and the Life Phases Modularization can also be carried out independently and due to the fact that a lot of expert knowledge is required in some steps, the method units have a lot of subjectively designable parts. Decisions are made based on the specific products or also based on the given company boundary conditions. Thus, it can sometimes be difficult to place individual module decisions in the context of the initial objective in retrospect.

3 Potentials Through Model-Based Approaches

In order to maintain an overview and to address this problem, data-driven management in the form of MBSE is used. As the approach no longer has to be paper-based, the limit of the components that can be mapped can be extended, as this is no longer a limiting factor. Another important point is the strengthening of consistency. This can be increased enormously by the use of model-based approaches. Other advantages coming with the MBSE environment are an increased plausibility check possibility, increased meta model transparency, increased product architecture maintainability and versionability for product generation developments. If a system does not contain any conflicting information, it is considered to be consistent. Inconsistencies are thus often a source of contradictions in the models, which are caused by a lack of consistency management as well as knowledge that is not explicitly documented and can lead to errors (Seiler et al. 2020b). Consistency in the data will enable traceability, for example of module decisions. Traceability of subsequent changes can also take place. This facilitates and enables the maintenance of the data in case of changes and adjustments. Since changes no longer have to be tracked manually, they are more controllable. The use of MBSE also has an impact on the methodical procedure. First of all, it has to be clarified that the introduction of MBSE does not contradict the workshop-based method implementation. On the contrary: MBSE strengthens the interdisciplinarity, which plays a major role in the methodical process: Subjective aspects of the stakeholders can be integrated into the development process, enabling acting in a more objective-oriented manner. The module decision can also be supported by software support. Through additional visualizations of data correlations, these become more comprehensible and can be actively used. The follow-up to method implementations is changing. By implementing the generic data contexts, workshop results can be documented easily and quickly in a model-based manner. Also, intermediate results of individual method steps can be recorded and are thus stored in a traceable manner.

3.1 Ensuring Consistency Through the Development of Meta Models

As already mentioned, the potential of model-based approaches is manifold: larger amounts of data can be processed, traceability, e.g. of changes, is strengthened and method implementation is simplified. The consistency enablement in itself can be understood as the basis for this. The consistency is thus made possible by a model-based approach in which the methodical modular product development is deposited with a consistent meta model for product data (Seiler et al. 2020b). To exploit this potential for the Integrated PKT Approach, it is backed by a meta model of product data developed for this purpose (Fig. 14.3). The meta model of product data defines the scope of the approach and provides a basis for software-supported implementation in modeling languages such as SysML.

Fig. 14.3
figure 3

Meta model of product data for the basis of the Integrated PKT-Approach (Hanna et al. 2018)

Full size image

In the meta data model, the individual elements of the tools are linked to each other via connections, which are not specified in more detail here in order to remain solution-neutral. The scope shown in Fig. 14.3 contains the tools presented in Sect. 14.2.1. It should be noted that this model is extensible due to its clear representation (Hanna et al. 2018).

3.2 Consistent Model-Based Implementation in SysML

The data relationships defined in the meta data model can now be implemented using MBSE. In the context of MBSE, SysML is a modeling language for object-oriented modeling of system models. The SysML contains nine different diagrams, from which four are structure diagrams, four are behavior diagrams and one is a requirement diagram (Alt 2012). They are used to model a functional system architecture at the system level. For example, Cameo Systems Modeler or Papyrus can be used as a modeling environment. The Cameo Systems Modeler has the special feature of providing a unique data store. In addition, it has more diagrams, tables and matrices, which allow the analysis of data relationships in the diagrams. With the help of consistent modeling, which is made possible by MBSE, horizontal and vertical traceability of individual elements can be enabled (Gilz 2014). A unique database, i.e., each element is contained only once in a model, and a generic description of the data relationships, for example in a meta data model, ensure consistency and the continuity based on it (Hanna et al. 2018). Thus, the basis of a model is set. In the following, such a model is presented, using a laser system as an example. The model is based on the meta data model presented in Sect. 14.3.1. In addition, the Cameo Systems Modeler is used to generate a uniform data base (Fig. 14.4). With the help of the elements contained therein, the tools from Sect. 14.2.1 could be built.

Fig. 14.4
figure 4

Implementation of tools on a consistent data base in SysML (adapted from Eichmann et al. 2018)

Full size image

In the center of the figure, a containment tree can be seen, which illustrates the consistent and unique data base. On the sides, selected tools of the Integrated PKT Approach are presented, which, as can also be seen in the meta data model in Fig. 14.3, all access elements of the “components” group. By storing the data at a central place we have a consistent data management. Due to the fact that there is a meta data model, other product application examples can now be created quickly and according to the same schema.

4 Extension of the Model-Based Implementation on the Basis of Two Application Examples

Methodical product development can be strongly supported by MBSE. For example, different tools can be demonstrated based on a consistent meta data model. However, the storage of a consistent meta data model also has many other advantages. In this section, two applications are presented, which could be developed on the basis of the model provided in Sect. 14.3.2 (Fig. 14.5). This results in an integrated holistic model.

Fig. 14.5
figure 5

Concept for the development on an integrated holistic model

Full size image

These are on the one hand a linked configurator system and on the other hand the linking of concepts for modular product families with their effects on economic target values. In the following two sections, the two application examples for extensions are presented. The links, which are shown as generic plus signs in Fig. 14.5, will be detailed and written more precisely.

4.1 Configuration Systems for Laser Processing Systems

Based on a modular product architecture, configuration systems are described as indispensable for mastering the increasingly comprehensive, variant-rich product architectures (Seiler et al. 2019). The configuration systems represent an instrument to optimally map concrete requirements of a customer to the most suitable product variant. However, a general limitation is that the configuration options usually cannot cover the complete range of customer requirements exactly (Liebisch 2014).

Since customers do not buy customer-relevant features, but rather decide on the basis of these features for variant module versions, a configurator generally has the task of processing all the information between customer requirements and bill of materials. This process is also often referred to as “translation”, representing one of the main tasks of a configuration system by translating customer requirements into discrete modules and module variants while consistently checking the determined product variant’s plausibility. The interaction platform towards the customer such a configuration system corresponds here to the front-end, by means of which the modular product architecture incorporated in the data structure is made accessible to the user. In this context, the use of MBSE offers a way of managing this modular product architecture with all its dependencies and limitations with regard to the configuration of the modules, which is intended to make verifiability for consistency traceable. In addition, it is not only necessary to ensure that the configurability function is visible to the user, but also to document it in conjunction with all decisions made on the basis of the product architecture and the set of dependencies and constraints linking the individual modules. Support for the maintenance of the configuration system in the course of changes or versioning of the underlying product architecture must also be guaranteed. MBSE opens up the potential to efficiently use structural and behavioral information as well as abstracted links in order to merge individual models into a coherent meta data model. In addition, the use of an appropriate MBSE tool, such as Cameo Systems Modeler, makes the individual configuration options traceable and verifiable. Accordingly, the database of such a configuration system must be able to map qualitative data, such as requirement links or customer relevant properties. This becomes all the clearer when the most important requirements for configuration systems are considered: These are to enable a consistent product configuration on the basis of a complete information system as well as the possibility of plausibility checks.

Above all, the forward and backward integration of all systems is one of the greatest advantages created by MBSE. This database is also used when using product configurators, which are described below using the example of customized laser machines. At this point, one majorly important fact to be stated considers the relation of the customer and the company product. As for the example of customer individual laser processing machines, customers tend to consider the individual machines’ (the company product) as black boxes, forming complex systems which enable the processing of the customer product. The customer product, for example a part of a car’s gear train, imposes a set of customer requirements towards the machine they are processed on. As the customer itself usually is not able to express these requirements in the perspective of the machine building company, a translation process is required. The customer requirements—and therefore the customer perspective—is translated into the company perspective, leading to a set of customer relevant properties. These customer relevant properties can then be used as a baseline for the subsequent configuration process. In order to realise the aforementioned translation of customer relevant properties into suitable module variants, selected tools of the Integrated PKT Approach are examined. Here, the use of a NP adapted to the special requirements of a product configuration system appears to be the most suitable from a sales perspective (Fig. 14.6).

Fig. 14.6
figure 6

Configuration Network Plan of laser systems

Full size image

Figure 14.6 shows both the generic structure of this NP (here: Configuration Network Plan) with its relation to customer and company product and the implementation of such a possible NP for individually configurable laser welding systems in the MBSE environment of the Cameo Systems Modeler (Seiler et al. 2020a). As the figure displays, the customer product imposes a set of customer requirements towards the company. These customer requirements are then used in order to determine the matching modules as well as the components they consist of.

By directly assigning customer relevant properties to components clustered into individual modules, the underlying product architecture can be modelled in its entirety. By using corresponding dependency matrices for the definition and representation of the individual object links, the set of rules for completing the modular kit can also be modelled semantically. The extraction of this modular product architecture as well as the set of rules via a corresponding user interface then in turn provides the continuous and consistent data basis for the configuration system. With reference to this database, the appropriate product variant is determined for each data set of customer requirements and their individual characteristics are recorded via the user interface of the configuration system (front-end) (Laukotka et al. 2020b).

In the case of the exemplary gear train part, one of the customer requirements describes the ability of the machine to process the part in its geometric dimensions. This customer requirement is then translated by using the configuration system’s frontend into a customer relevant property. By applying the configuration hyperspace algorithm as described in Seiler and Krause (2020), the configuration system determines the corresponding module to this customer relevant property according to the underlying NP. Furthermore, the components and therefore, specific article numbers forming individual models are linked within the MBSE structure as well, enabling an automated generation of a final product variant bill of material (BOM). All other customer requirements are linked to corresponding modules analogically, leading to a final configured product variant.

4.2 Model-Based Representation of the Effects of Modular Product Families

Another application of the procedure of modeling based on the meta model of product data in Fig. 14.3 is the representation of the effects of modular product families, which have been recorded in the past years and visualized in an Impact Model of Modular Product Families (abbr.: Impact Model) (Hackl and Krause 2017; Hackl et al. 2020). The Impact Model shows impact chains and is a cause-effect model. Based on the properties and characteristics of modularization, effects are presented in the form of impact chains, which are assigned to the different product life phases. Finally, these effects lead to economic target values time, costs, quality or flexibility. The initial literature-based content of the Impact Model was validated in industry surveys and interviews (Schwede et al. 2020c; Greve et al. 2020a). The Impact Model is a visualization that contains many different elements (Fig. 14.7, top).

Fig. 14.7
figure 7

Procedure for model-based Impact Model

Full size image

In addition to the main visualization, additional information such as boundary conditions for individual effects are available. An example therefore is the boundary condition ‘production type’. This boundary condition has an impact on the effect ‘lowering procurement costs’: Due to the strengthening of the commonality, the effect of ‘lowering procurement costs’ is more pronounced for mass producers than for individual producers (Hackl and Krause 2017). Other additional information may include, for example, key figures or validation results for individual effects.

For configuration systems, the model is based on the meta model of product data. As described, there are a large number of different elements for the Impact Model. In order to obtain an initial overview, similar to the development of the meta model of product data, a meta model for the Impact Model was created according to the same schema (Fig. 14.7, middle). The Impact Model itself is represented in a Block Definition Diagram, with the various visualization elements integrated as Blocks. The Block Definition Diagram is a good choice in this case, as it can be used to represent a wide variety of elements with different, even self-defined, connections. Boundary conditions are also integrated into the model to strengthen it (Fig. 14.7, bottom).

In order to map the boundary conditions in SysML, the elements in SysML were analyzed. The combination of the element types “requirement” and “constraint” turned out to be the most suitable for modeling. The SysML-elements have been modified by defining new stereotypes. Constraints are linked via Requirements in the Requirements Diagram. The causal relationship described above is stored in an if-statement in an element of the type ‘constraint’ (Schwede et al. 2019a).

In addition to the representation of the effects of concepts of modular product architectures, a link to the tools of the Life Phases Modularization can also be made (Schwede et al. 2019b). The aim behind this is to strengthen the objectives of Life Phases Modularization. For this purpose, module drivers represent the bridge between the modularization methods and the elements of the Impact Model (Fig. 14.8) (Schwede et al. 2020a).

Fig. 14.8
figure 8

Linking Life Phases Modularization to Impact Model via module drivers (Schwede et al. 2020a)

Full size image

In different modularization methods, there are different reasons that lead to the formation of modules; this is the case with product-strategic and technical-functional modularization methods. Comparing the different reasons for module formation with the effects in the Impact Model, modularization methods can also be linked to the Impact Model. The aim of this is to compare different modularization methods with each other in terms of the goals and effects addressed in each case. The already existing SysML-model of the Impact Model is to be used for this purpose. By integrating individual method steps of modularization methods in the form of behavior diagrams, these can be linked to the elements of the Impact Model via elements (here: module drivers). By implementing this coupled SysML-model, indirect relationships can be represented in special views. In addition, queries can be defined that filter the model, for example, depending on the use case.

4.3 Derivation of the Potentials of the Model-Based Approach Using the Application Examples

By using a meta model of product data, an extensible consistent holistic model could be derived, which in turn can strengthen the initial meta model of product data (Fig. 14.3. By linking configuration systems, customer requirements can be addressed better and more efficiently. By linking the effects of modular product families from the Impact Model, the objective of Life Phases Modularization can also be strengthened and concretized.

Intra sub model analyses are made possible in a next step. For example, based on customer relevant properties, product variants can be easily configured. If now, for example, there are two product variants that match the customer relevant properties, further effects on different life phases can be illustrated with the help of the linked Impact Model. In addition to using the customer relevant properties as module drivers in the NP, it would also be possible to identify other module drivers that bring along desired effects. All in all, it can be said that the technical requirements can be satisfied by the configurator and that the economic effects or objectives can be kept in mind by linking the Impact Model.

Furthermore, as modular product architectures come with a higher degree of complexity than classically structured product architectures, the data linking between different models can be performed in a more efficient, traceable and versionable way. Additionally, the modular product architecture’s maintainability can be increased as changes and their effects on linked components and models can be perceived directly. This allows new findings to be integrated on an ongoing basis. The open formulation of the data relationships in SysML makes it easy to add these new insights and to involve experts. As another aspect, plausibility checks for changes and adaption can directly be implemented into the MBSE environment. These specific advantages can directly be transferred towards the connected applications, such as the product configuration system or the described Impact Model.

5 Conclusion and Outlook

In addition to the applications of MBSE in the context of product development listed in Sect. 14.1, this book chapter showed that methodical modular product development can also benefit from MBSE. By implementing tools from different method units of the Integrated PKT Approach, a holistic model is developed. Due to the open design of interfaces, this model is expandable, thus, other tools of method units for current trends in product development can also be integrated. A planned enhancement is the key figure background of the Impact Model in order to strengthen it further. Furthermore, an interface to the modeling of production systems is to be created, which will enable a coordinated design of product architecture and production system (Schwede et al. 2020b).

The data correlations that arise during the development of modular product families can be used consistently, which opens up completely new possibilities in development. One of these possibilities is the use of this holistic model as a reference model for Digital Twins. Among other things, the holistic model provides a generic description of product families. From this holistic model individual master models of product variants, then used as masters for Digital Twins, can be derived (Laukotka et al. 2020a, b). This procedure represents an extension to the assumption that frequently only individual products are focused in the context of Digital Twins (Stark et al. 2020). By using the holistic model, which represents entire product families, the approach of Laukotka et al. is set one level higher. This takes into account the current trend of developing product families instead of individual products (Laukotka et al. 2020b).