2.1. Systems engineering

The International Council on Systems Engineering (INCOSE) clearly describes systems engineering (SE) as an interdisciplinary approach that “means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem […]” (Walden et al. Reference Walden, Roedler, Forsberg, Hamelin and Shortell2015). With rising applications of SE worldwide and in different domains, an ambiguous understanding of SE has developed that has concurrently led to slightly different interpretations and practices of SE (Inkermann Reference Inkermann2021). Likewise, from the start, there was a need to support engineers and enable effective coordination of projects (Martin Reference Martin1997). Clearly described processes that target main engineering activities, such as system requirement definition, architecture definition or verification, are defined by INCOSE (2007) and ISO/EC/IEEE (2015), as well as the widely known V-Modell (VDI/VDE 2021). Additionally, complementary methods define, among other things, how to decompose tasks or sequence actions as well as the required input information. At that SE is not simply the engineering of systems but a clearly defined set of tasks, processes, and methods.

2.2. Model-based systems engineering

SE and its tasks, processes and methods all come with the associated data that must be documented. With rising project complexity, handling the likewise rising amount of information poses a challenge. This is faced by turning to a more formalised way of storing data, such as semi-formalised modelling languages. This shift to a model-based approach also allows for integrating different views of a system into a single consistent system model.

INCOSE describes this approach as model-based systems engineering (MBSE) and “the formalised application of modelling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. MBSE is part of a long-term trend toward model-centric approaches adopted by other engineering disciplines, including mechanical, electrical and software” (INCOSE 2007). In their INCOSE Handbook, MBSE is listed as one of the cross-cutting SE methods, clearly linking MBSE to SE (Walden et al. Reference Walden, Roedler, Forsberg, Hamelin and Shortell2015). Before that and independently from SE as defined by INCOSE, Wymore uses the term proposing system theoretic models and physics-based engineering models to represent organisational problems and “are developed, manipulated and managed by system engineers throughout the lifecycle” (Wymore Reference Wymore1993). The linkage between MBSE and SE is also highlighted by Friedenthal, Moore, & Steiner (Reference Friedenthal, Moore and Steiner2015), who says, “MBSE emphasises the use of models to perform SE activities that are traditionally performed using documents”.

In consequence, MBSE shall not be understood as applying modelling to any (engineering) process but as explicit support of SE activities as defined by INCOSE (2007) and ISO/EC/IEEE (2015), as well as using semiformal system modelling techniques. However, an exploratory study of publications has shown a diverse understanding of SE and MBSE, and the term MBSE is often not used accordingly (Berschik et al. Reference Berschik, Schumacher, Laukotka, Krause and Inkermann2023). Usually, only some elements related to MBSE are used and applied to different tasks or challenges. In addition to the required linkage to SE and based on literature, (Berschik et al. Reference Berschik, Schumacher, Laukotka, Krause and Inkermann2023) define four aspects essential for MBSE: the system model and the three modelling pillars modelling method, modelling language and modelling tool as defined by Delligatti (Reference Delligatti2014). The system model can be seen as the connecting element of the described pillars. It integrates different views of the system into one holistic model.

2.3. Initiation of ASE

The so-called ASE is an approach to the development of complex systems. It is defined as integrating technology, people and processes to develop innovative solutions to multi-disciplinary challenges. ASE emerged in response to the growing complexity of technologies and applications in various industries such as aerospace, automotive and information technology (Wegmann, Johnson, & Anderson Reference Wegmann, Johnson and Anderson2020). This complexity required a systematic approach to understand component interactions better and improve system performance (Liu et al. Reference Liu, Smith and Zhang2017). Integrating ASE into methodical product development can better analyse, design and optimise complex systems. By systematically considering interactions and interdependencies between components, efficiency improvements and innovations are enabled, leading to advanced products and solutions.

Therefore, ASE is meant to be a holistic approach that integrates the already mentioned SE and considers AS development and advanced engineering (AE) to cope with these novel and uprising challenges. AS are complex, sophisticated systems that have emerged through advances in science and technology. These systems are characterised by their ability to adapt to changing environments, provide high interactivity, and offer innovative solutions to complicated problems. AS have evolved in many areas, including autonomous vehicles, smart healthcare and Industry 4.0, with advances in microelectronics, sensors, data analytics and artificial intelligence (He, Chen, & Lee Reference He, Chen and Lee2018). The development of AS requires close collaboration between engineers, scientists and other professionals from different disciplines. Methodical product development enables the structured integration of knowledge and expertise to design complex systems (Kim, Park, & Chang Reference Kim, Park and Chang2021). Those challenges in collaboration induce AE. This enhanced way of engineering refers to the application of cutting-edge technologies, methods and materials in the creation of innovative products, systems or processes. AE involves utilising techniques and approaches that surpass traditional engineering practices. The integration of simulation technologies, additive manufacturing, virtual reality and other advancements has paved the way for the development of AE as we know it today (Brown & Smith Reference Brown and Smith2019). With AE, engineers can design intricate and lifelike models of products and systems before physically producing them. These benefits are faster and more cost-effective product development because potential defects can be identified and resolved early (Arora & Raja Reference Arora and Raja2016).

As a more in-depth addition, collaboration in AE is one of the key points in the increased interaction in the development process (Mcharek et al. Reference Mcharek, Azib, Larouci and Hammadi2019). In AE, the focus is on transferring new methods and approaches to engineering (Mertens et al. Reference Mertens, Rennpferdt, Greve, Krause and Meyer2022). As can be seen in Figure 1, the interaction between an exemplary selected set of four disciplines is changing from cooperation to collaboration. On the left side of Figure 1, different participants in the engineering of systems are working parallel and in cooperation on their designs. On the right side, various participants are working, in potential iterative interaction, on a collaborative system design (Schmidt, Weiss, & Paetzold Reference Schmidt, Weiss and Paetzold2018). Those sets of participants of different domains and disciplines will vary from specific system to system. A holistic integration of all relevant domains and disciplines is necessary for overall collaboration consideration. Figure 1 shows only a preselection of possible disciplines to present them more clearly.

Figure 1. Shift from conventional sequential engineering to collaborative advanced engineering (AE).

Due to the goal of PFE as a cross-section methodology, the depicted focus does not include all domains and disciplines integrated into a holistic ASE approach. However, it addresses all relevant core steps for handling internal variety due to collaboration-induced complexity. Collaboration of different domains and development disciplines derives as one essential part of AE. Successful collaboration contributes significantly to the fulfilment of customer requirements and is, therefore, to be regarded as a critical factor for the company’s success (Mertens et al. Reference Mertens, Rennpferdt, Greve, Krause and Meyer2022). Central prerequisites for this are clear communication between all participants and defined goals and requirements of the product families. Relevant information and resources must be available throughout the entire development process to ensure efficient collaboration and targeted SE (Yassine Reference Yassine2021). Furthermore, a common understanding of the product family’s requirements and goals is necessary. Due to continuously increasing requirements and shortened development cycles, as well as the associated complexity of the products, the number of teams and people involved is increasing (Mertens et al. Reference Mertens, Rennpferdt, Greve, Krause and Meyer2022).

2.4. Product family and variety

In the literature, the term PLE is often used in the field of software development. It is an overarching term for developing and managing similar software systems under consideration of software variance (Metzger & Pohl Reference Metzger and Pohl2014). Based on this description, a stronger link to SE was established with the definition of feature-based PLE (ISO/EC/IEEE 2021). Here, different features are used to build up the market view of products as the basis for the resulting configuration of the product set under consideration. The external variety of the systems under consideration is thus described, and the resulting product instances are formed. The analysis of the internal variety within the various product instances is usually not described further. A product is built on predefined domain assets and configured towards the final product asset instance according to the selected features. Hence, already predefined solution patterns can establish different variants (ISO/EC/IEEE 2021). This solution pattern can be used for knowledge management and can therefore provide a basis for the description of variants (Weber & Husung Reference Weber and Husung2016; Anacker et al. Reference Anacker, Dumitrescu, Kharatyan and Lipsmeier2020). The term PLE is sometimes used as a synonym for the term PFE (Hummell & Hause Reference Hummell and Hause2015). Although the terms are occasionally synonymous, they can also mean different things. Also, compare Figure 4 in the later section.

Product lines, as considered in PLE, are clustered products within a product program with similar application areas, functionalities, or production processes. They are grouped in a way that makes sense from a business and strategic point of view. They represent a structured grouping of product families that are often defined on a company-specific basis. Product lines help keep track of product development and management (Rupp Reference Rupp1988; Krause & Gebhardt Reference Krause and Gebhardt2023).

A product family refers to a set of product variants with similar functional principles, technologies and the same areas of application or production processes. The product family comprises all variants that differ in at least one property or element but have the same basic functionality (Rupp Reference Rupp1988; Meyer & Lehnerd Reference Meyer and Lehnerd1997; Krause & Gebhardt Reference Krause and Gebhardt2023). Ideally, these differences are relevant for customer decisions, as they enable the selection of the appropriate product variants (Mortensen Reference Mortensen1999; Harlou Reference Harlou2006).

Another important feature of product families is that they include all the variants of an offered product. This enables synergies between the components used. Although product families are not necessarily modular, they can be designed modularly to increase efficiency in development and production. This approach is similar to platform design, used mainly in the US (Robertson & Ulrich Reference Robertson and Ulrich1998; Simpson, Siddique, & Jiao Reference Simpson, Siddique and Jiao2006; Pirmoradi & Wang Reference Pirmoradi and Wang2011). It is not only about product-side implementation but also about integrating action systems and organisational resources for PFE, as shown in Figure 2.

Figure 2. Product family generations with system elements, including hardware and software layers (left). Evolution of linked relevant organisational resources for product family engineering (PFE) (right). Extended by additional Services in the Product Family (top).

Product families represent a cluster of similar systems that can be developed together. Despite specific distinguishing features, they can exploit synergies and enable a holistic approach to product development. This allows resources to be used more efficiently and development times to be shortened, ultimately leading to more competitive products. Parts of the individual systems can thus be reused in the best possible way in similar systems (Walden et al. Reference Walden, Roedler, Forsberg, Hamelin and Shortell2015).

The consideration of variants has diverse aspects, as each variance in a component induces complexity in the system and the associated processes. This has many effects, such as new work steps, special processes, or a decreasing batch size (Krause & Gebhardt Reference Krause and Gebhardt2023). Thus, variant management is a crucial cross-cutting topic in interdisciplinary PFE. In this, the task is to reduce and avoid internal variance while keeping the external variance of the product family at a maximum.

In the field of modelling variant management, there are already various approaches to depicting variance. In software development, for example, the orthogonal variability model (OVM) exists as a concept for mapping variant information (Pohl, Böckle, & Linden Reference Pohl, Böckle and Linden2005). The OVM is used in software development within diagrams of the Unified Modeling Language (UML) and thus offers a visualisation for differentiating program properties and the associated variation (Metzger & Pohl Reference Metzger and Pohl2014). Furthermore, the common variability language (CVL) of the object management group (Haugen, Wąsowski, & Czarnecki Reference Haugen, Wąsowski and Czarnecki2012) exists as a cross-disciplinary modelling language for variants. In SE, especially MBSE, there are various profiles or modelling methods for the modelling language SysML, such as the variant modelling with SysML (VAMOS) method. VAMOS supports the modeller in modelling different variants using packages and stereotypes in SysML. The expression of the variance is modelled here on the physical level, i.e., in the individual components and variants (Weilkiens Reference Weilkiens2016). Other ways to model the variance are with the help of plugins for the modelling tools. Plugins such as model-based product line engineering (MBPLE) for cameo systems modeler can be used to model the behavioural modelling of variants and their associated configuration (Colletti et al. Reference Colletti, Qamar, Nuesch and Paredis2020).

Product families are suitable for designing modular architectures due to their characteristics in variant creation and management. In this context, modularisation in product families is determined by the properties and characteristics of modularisation, through which product families can adopt different strategic approaches in exploiting different strategies (Mortensen Reference Mortensen1999; Harlou Reference Harlou2006).

Modularity is a gradual property of the product structure. What is essential is the concentration of the couplings of the components within the modules. These have stronger couplings to each other than to other components or modules. Modules combine components with certain common features, which can thus be treated as a logical unit.

The modularity is specifically designed to meet the requirements of all product life phases. Particularly noteworthy are

• ▪ Reusability: Modules are used in different products to enable savings through economies of scale.

• ▪ Combinability: Different product variants can be configured by combining modules.

An essential measure for realisation is interface standardisation and function binding. In the latter, modules fulfil exactly one function or a defined functional scope (Salvador Reference Salvador2007; Krause & Gebhardt Reference Krause and Gebhardt2023). Like modularity, its properties are also considered gradual. In their entirety and considering their interactions, they describe the modularity of a product structure. The goal in the development of modular product families is not necessarily a product structure that is as modular as possible. Instead, the modular properties should be designed to achieve the highest possible company- and product-specific benefit in all life phases of the product family.

4.1. Model-based architecture design of product families

In the following section, the architectural design of product families is looked at from a model-based perspective. Hence, it is focused on the modelling of the architecture and the resulting benefits for further usage of the underlying system model.

The so-called V-Model is often used in the development of mechatronic systems. The technical processes of ISO 15288 are also known as SE (ISO/EC/IEEE 2015). They can be classified in the V-model and form the basis for further description. The technical development process records and defines the stakeholders’ requirements. Based on this, the requirements are analysed. Both process steps of ISO 15288 are considered in Requirements Engineering and are not described further here (Pohl & Rupp Reference Pohl and Rupp2011). Many methods exist for Requirements Engineering that have already been implemented model-based, see Holt, Perry, & Brownsword (Reference Holt, Perry and Brownsword2012) and Japs (Reference Japs2020). Building on the Requirements Engineering, the architecture design follows. A wide variety of models and structures are used in architectural design. One of them is the system architecture. It is used to link the functional structure of the system with the component structure (Ulrich Reference Ulrich1995). In this context, the so-called RFLP-Framework is used to model a system. This approach is used to link the various development data and is based on the interrelationships of the V-Model (Eigner & Gilz Reference Eigner and Gilz2012; Kleiner & Kramer Reference Kleiner, Kramer, Abramovici and Stark2013).

The related development data can be systematically divided and assigned based on the commonly used RFLP-Framework. Building on the left side of the V-Model, all basic development data can be mapped (Eigner & Gilz Reference Eigner and Gilz2012). When describing the architecture, the variety regarding the system context of the individual data elements is often not considered. However, it represents a significant cost driver in developing and maintaining product families. For this reason, it should already be considered in the architecture design (Krause & Gebhardt Reference Krause and Gebhardt2023). For further classification, product families can be seen as subsets of a product line; these describe the internal variety of the products under consideration, whereas the product line focuses more on the market view and the resulting external variety (ISO/EC/IEEE 2021).

Based on the described relationships, a higher-level data structure can be established. This can be mapped in an ontology using the modelling language systems modelling language (SysML). It is used to express the entities of different data elements and their relationships on an understandable and abstract level (Aßmann, Zschaler, & Wagner Reference Aßmann, Zschaler and Wagner2006). Figure 5 shows a simplified architecture ontology for product families that depicts the data relationships and their classification in the RFLP framework. This maps the classic functional development data (VDI/VDE 2019) and supplements it with product strategy aspects (shown in light orange colour), for example, by dividing a system into modules and variants. Hence, the architecture focuses on variety and the resulting complexity for the overall product family. Thus, the internal variety on the different levels, such as functional or logical, is modelled and focused in detail.

Figure 5. Simplified Ontology of the data model for modelling product families.

In contrast to the conventional usage of the RFLP-Framework, PFE uses this framework more extensively to model the allocations between the solution principles and system elements of different domains and disciplines in complex cybertronic systems and services. On a logical level, for example, the RFLP-Framework is extended by the different solution principles of hardware, software and service domains, e.g., electro-technical sequences or sequences and various programmable logic controllers. In addition, the physical level is extended by all elements regarded by the included domains. So, not only hardware, software and service elements can be depicted and addressed, but modules and submodules can also be modelled, integrating all domains.

Product properties are mapped based on requirements starting from the data contexts of the classical development procedures. Product properties describe the characteristics of a product and represent the customer’s perception. They are often not quantifiable and cannot be directly influenced by the developer. Compared to the customer-relevant properties relevant to a customer’s perception of the product, some properties are irrelevant to the customer’s perception. The characteristics of customer-relevant properties can be used as a basis for configuring product variants. Accordingly, only customer-relevant properties should influence the internal variance of the product and hence have a link to business requirements.

Furthermore, internal properties are predetermined by the companies and should not create a variance in the system architecture (Krause & Gebhardt Reference Krause and Gebhardt2023). Several components are combined into product strategic modules or module variants. These, in turn, form the different product variants aggregated into a product family. The modelling implementation was done using the modelling tool Cameo Systems Modeler and based on the modelling language SysML.

In the following, some excerpts of areas are discussed in which a model-based implementation of the architecture of a sheet metal bending machine could benefit the product family’s development and maintenance processes.

Figure 6 shows the sheet metal bending machine product family variants considered in this example. The hierarchical modelling allows the associated modules to be mapped as part properties based on the modelled variants of the product family and the existing components with their variance characteristics to be attached to them.

Figure 6. Modelled modules of the exemplary bending machine product family.

The system under consideration has four variants, each of which is differentiated by the customer-relevant characteristic of the pressing force. The depth of the sheets to be bent is differentiated into long and short processing areas. In addition, the variants have an optional module that includes a monitoring system for the bending process with additional sensors. The modelled generic modules are thus divided into different module variants with different components attached.

Through the resulting continuous modelling with the help of generalisations and compositions, it is possible to draw holistic conclusions about the various components of the product family. As an example, a selection of components of the modules is shown in Figure 7. The components are shown in the table created based on the model sorted according to their variance and the associated customer-relevant properties.

Figure 7. Tabular representation of the modelled components and modules within the individual variants of the bending machine product family.

For example, in the view of the model shown in Figure 7, it is possible to see precisely which components appear in the TruBend 13 LB variant. It is possible to see which components appear in the same design across the entire product family and are thus marked as standard components. At the same time, all variants and optional components of the individual variants are displayed. The distinction can also be seen at first glance via the attached icon. The nomenclature that is also used in other tools of the Integrated PKT-Approach is used for this (Krause & Gebhardt Reference Krause and Gebhardt2023). Furthermore, the data can be exported as Excel or the standardised CSV format for other programs and visualisation tools.

The dependencies on other development data, such as the functions, can also be drawn through holistic linking. In this way, the connections of functions, via operating principles to components, from a system architecture can be referenced over several levels with the help of metachains, even though no direct connection between functions and components has been modelled. By composing the overall system, the different functions can thus also be mapped to variants and be visualised overall. Dependencies and resulting relationships can be documented more easily in this way, as they can be presented more clearly in different diagrams. For example, an engineer wants to determine which function relates to a particular module in the system architecture because of ongoing customer complaints. With the help of the system model, it is easy to find the module’s functions and their derivatives quickly. Due to the consistent model, it is also possible to see in which other module this function is relevant. Consequently, the analysis process can be optimised.

If further connections of the metamodel (Figure 5) are considered, an association of the customer-relevant properties to the variants can also be considered with the overall modelling. This data linking from a sales perspective is a decisive view for a possible configuration in variant management. Here, because of the linkage of the development data of the product family, the indirect reference from properties to variants is traceable without explicitly creating a direct relation. In contrast to classic PLE approaches, the internal variety of the focussed variants and, thus, the establishment of different reused modules is also of interest and is, therefore, modelled. Building on this representation, a feature-based offer catalogue can be established. Figure 8 shows an extract of customer-relevant properties of the bending machines with their characteristics. These can be selected based on a table like a configurator interface. Plausibility rules are stored for all properties depending on the stored stereotype. After a selection, it can be checked whether all properties required for selecting a variant are set. If a selection is missing, it is automatically displayed in yellow. If an error has occurred, for example, due to multiple selections, this is shown in red.

Figure 8. Table for selecting customer-relevant properties to evaluate possible variants.

The variable CRC Input is set in the customer-relevant property by selecting or deselecting the checkbox. This variable is used in the next step to hide unused properties for variant determination.

The linking of the customer-relevant properties with the variants is thus displayed based on the selection and the corresponding hiding of the properties. Like the functions, the customer-relevant properties are also linked to the variants via a meta-chain. Accordingly, changes in the development data directly affect the corresponding link to the variants. Thus, the selection of variants can be implemented directly from the system model without creating another selection model. Figure 9 shows a possible selection of customer-relevant properties. The variant TrueBend 13LB has the most ticks and should be selected. The variant TrueBend 85 SB could also be chosen, but the property of the locating surfaces with the six axes is not fulfilled for this variant. Accordingly, the check mark is not set in the illustration.

Figure 9. Representation of an evaluation of possible variants.

Based on the modelled data connections, many other applications can be set up because of the architecture design. The model is a basis for implementing different views and advantages with little modelling effort. In this context, PFE, with its modelled definition of relations, is essential to consider all variants and their relations. PFE can be seen as a detailed view of the underlying product family regarding its variety and modularity. In this way, the overarching product line, which focuses on the external view of customer properties and their configuration, can be described in detail.

Using modelled system architectures results in further advantages, especially in the early dimensioning phase of development. Through the targeted use of cross-architecture calculation logic with the help of parametric diagrams, static parameters such as the mass of modules or variants can also be calculated, including the internal variety over the whole product family. In addition, state-dependent dynamic parameter calculations can be carried out with the help of simulations. Modelling tools such as the Cameo Systems Modeler have capabilities like the so-called Rollup Patterns, which use states controlled via a state machine for the recursive calculation of parameters. Thus, they can calculate dynamic changes within the system, such as power consumption or other flows (Berschik et al. Reference Berschik, Oidtmann, Laukotka, Brahm, Krause, Koch, Wilke, Dreiseitel and Kaffenberger2022). This information can be used in the design to define margins at an early stage and to take them into account in further development.

By holistically linking several product variants of a product family in a system model, required margins can be verified against existing requirements at an early stage or reviewed during product generation development. Using such calculation tools is a great added value for the continued use of the architecture models. At this point, further research is needed, as the calculation logic must be better implemented in the existing models of the system architecture. This would allow for a better consideration of the variance of individual components in the overall system. The implementation is currently being further investigated.

4.2. Domain-specific models

In AS, collaboration-induced complexity can increase in addition to variant-induced complexity. Due to the increasing number of disciplines and domains involved, it is necessary to synchronise the drafts in the technical processes up to the design and to map them within the framework of a domain-specific model (Mensing & Schaefer Reference Mensing and Schaefer2015; Wu et al. Reference Wu, Zhou, Zheng, Sun and Zhang2022).

In the context of PFE, the processes up to the design stage are carried out multiple times and in parallel. Harmonising the designs between the variants and across the disciplines and domains creates a major action area with much synergy and savings potential (Gauss, Lacerda, & Miguel Reference Gauss, Lacerda and Miguel2022).

To exploit the best possible potential, modularisation helps to reveal the synergies between the variants transparently and to address them in a targeted manner. The characteristics and properties of modularity help here, enabling structured reusability and interchangeability while securing the intended functions. Furthermore, however, the processes and the organisation must be harmonised (Colfer & Baldwin Reference Colfer and Baldwin2016; Yassine Reference Yassine2021). In PFE, this harmonisation is supported by various method modules and tools. The goal is to derive a modular design harmonised for the product or system side, e.g., the Advanced System, and for the process and the organisation, i.e., the AE. This results in clearly defined interfaces, responsibilities, procedures, and processes in the maintenance and design of product families (Helmer, Yassine, & Meier Reference Helmer, Yassine and Meier2010; Krause & Gebhardt Reference Krause and Gebhardt2023).

The process and the organisational collaboration can be represented by a collaboration-process-visualisation (CPV), as shown in Figure 10. The CPV enables different disciplines and domains in a development process to be represented transparently and collaboration to be derived from this. The CPV is based on the method-process-visualisation (MPV; Krause & Gebhardt Reference Krause and Gebhardt2023), extended by collaboration activities and critical indicators for collaboration-induced complexity. As shown in Figure 10, this modelling enables a more detailed analysis of the interaction of all participants in the AE process (Kolfschoten et al. Reference Kolfschoten, Briggs, de Vreede, Jacobs and Appelman2006; Mcharek et al. Reference Mcharek, Azib, Larouci and Hammadi2019).

Figure 10. Extract from collaboration-process-visualisation (CPV) of a development process with three exemplary participants in MS Visio.

In the TruBend product family example, these processes can be set up for, e.g., the systems engineer and the software architect. This results in two process streams containing mono-disciplinary and collaborative activities. The visualised interfaces and common references to peripherally built system models enable a targeted design of a common understanding with corresponding models in systems architecture design (Mensing & Schaefer Reference Mensing and Schaefer2015).

This makes it possible to create a common system model for developing the modular product family and not to promote autarkic domain-specific designs (Zuefle et al. Reference Zuefle, Muschik, Bursac and Krause2022). In the example of the product family, collaborative decisions are thus made at the level of technical realisation and the corresponding functional description of the smart, networked back gauge, in which both the software for any business model and the constructive and electro-technical realisation of the assembly could be coordinated. This results in potential integration and preventive activities for error avoidance of multi-disciplinary structures (Fioriti et al. Reference Fioriti, Boggero, Prakasha, Mirzoyan, Aigner and Anisimov2020; Rennpferdt & Krause Reference Rennpferdt and Krause2020).

Depending on the use case and organisational structure, additional relevant stakeholders can be integrated into the CPV to develop the systems architecture designs. A prominent example of agile working is the product owner (Schmidt, Weiss, & Paetzold Reference Schmidt, Weiss and Paetzold2018).

The structure of the systems architecture designs of an AS and the preparation of the process of AE and its interfaces serve as the basis for multi-disciplinary modularisation in PFE. Here, the designed system components are assigned to the corresponding disciplines or domains and are also expanded by the scope of the domain-specific or discipline-specific components (Helmer, Yassine, & Meier Reference Helmer, Yassine and Meier2010). This way, interactions can be analysed, interpreted and addressed from a process, organisational and product perspective. Tools such as modelling a Domain Harmonisation Chart (DHC) and allocation matrices between domains are used for this (Sosa, Eppinger, & Rowles Reference Sosa, Eppinger and Rowles2004; Zuefle & Krause Reference Zuefle and Krause2023). Currently, the model-based mapping of this methodological tool is a challenge in research, as the linkage must take place across three model domains.

By modelling the interactions and interfaces, suitable harmonised module sections can be derived and evaluated across various domains. To use these module sections for AE, they must be transferred back into the process and organisational domains, in which, for example, design sprints are established according to the harmonised assignment (Grimheden Reference Grimheden2013). Furthermore, the activities in the collaboration process can be adapted to the harmonised module sections, reducing the KPI-based assessment of the collaboration-induced complexity in the PV.

Using the TruBend product family as an example, the Domain Specific Models achieved harmonisation of the modules for the bending process and monitoring the bending angle here. The bending angle can be monitored and measured using various technical and software solutions, but the respective solution affects the implementation in the system architecture design. The identified collaboration between the systems engineer and the software architect in the case of kinematic measurement results in an interface for interaction in the engineering process. The implementation of the harmonisation in the DHC results in two modules, which, on the one hand, enable the bending process via the traversing and monitoring of the press beam, and on the other hand. This module allows for angle measurement using sensor-integrated tools and additional lasers. For both modules, corresponding collaborating module teams were formed, which take care of the subsystem development with defined interfaces.

4.3. Model-based testing and test-specifications

The validation and verification of systems, especially AS, is crucial to their certification. Without testing, the functional integrity of the system cannot be ensured (Walden et al. Reference Walden, Roedler, Forsberg, Hamelin and Shortell2015). The test series is defined in the product-specific test plan. Test specifications are used to prescribe specific tests for subsystems or major components. Typically, test series are set up on the real system for verification and validation. If looking at these process steps from the perspective of model-based support, there are advantages if the test specifications use a model-based architecture design in the form of the system model (Pretschner & Philipps Reference Pretschner, Philipps and Broy2005, Utting & Legeard Reference Utting and Legeard2007, Weißleder Reference Weißleder2010). Since they utilise the system’s already used and modelled data and link relevant test cases to the predefined requirements (Schieferdecker & Hoffmann Reference Schieferdecker and Hoffmann2012), this reduces the documentation effort, as model elements can be standardised for the test procedure.

On the other hand, considering product families offers the possibility of reducing the test effort since modules that occur in several variants need to be tested only once (Krause & Gebhardt Reference Krause and Gebhardt2023). The final goal is to derive semi-automatic test scripts from the model-based test specifications that can holistically reduce the execution and complexity of large-scale test series. For test procedures and evaluations to be created semi-automatically, depending on what tests have already been conducted with similar variants, there is a need for a comprehensive definition and modelling of test requirements, boundary conditions and, of course, the product family itself. Regarding the occurring variance within product families, the presented model-based PFE can lay the ground for further implementations regarding the strategic testing of its variants. Ideally, outcomes for different subsystems or variants are fed back into the system model to allow for an easy overview of already conducted and pending tests when focusing on another variant. The implementation of this approach is part of current research.

4.4. Retrofit and maintenance—challenging processes during the product usage

The previously described aspects and approaches focus on different parts of product creation and can be connected to other phases within the V-Modell (Figure 3). While the main engineering activities are mostly finished at that point, most of the product’s life, its usage phase, begins. Yet, the presented aspects of PFE remain relevant, especially for long-living products and products with rigorous safety and maintenance requirements.

Staying with the example of the TruBend bending machine product family, it is developed as a product family but manufactured as tailored variants for each customer. Even if a single customer orders three identical variants, while being ideally identical at the point of delivery, these three instances of the product will start to deviate from the documented and initial state.

In one instance of the product, a collision of the bending tool may occur due to improper handling. The second instance is being used more heavily or even above its limits and has worn out rails after some time. Because of a fabrication failure in a vendor part, the hydraulic ducts of the third instance start to leak. All product instances are being repaired during regular maintenance, albeit they remain different. The collision damage has impaired the functionality, as even with a replacement part, the machine needs to cope with still warped structural parts. This can be compensated in software but limits the speed of operation. The worn-out rail of the second product instance is being replaced by a more durable one. All three instances have also received a crucial software update.

As a result, deviations between the product instances occur over time, even if they once were identical variants. Defects, wear and tear, or replacements as part of smaller maintenance works cause increasingly more deviations of the specific product instances than the ideal product variant. Thus, the occurring variability is not solely determined by the planned variance within the product family anymore but also by the emerging deviance, the deviation of the actual product from its once ideal state.

In this situation, an upgrade of all machines from four- to six-axe operations is planned in coordination between the customer and the original manufacturer. While the generally possible upgrade solutions are defined by the product family architecture and its possible variants, there may be limitations to the implementation because of individual deviations. However, to identify these limitations, information about the actual state of all instances first needs to be gathered to evaluate the actual upgrade possibilities. This overall situation is visualised in Figure 11.

Figure 11. Variability of products and their respective documents when facing maintenance and retrofit.

Exact knowledge of the product family greatly reduces the challenge of the variability, even in this later phase. The knowledge of the variance allows the reduction of the overall faced variability to the deviance originating from the usage.

Aviation is another application where this variability, combined with variance and deviance, plays an important role. A closer look reveals that the ongoing maintenance works and, notably, the regularly occurring retrofit face a challenging amount of variability within the targeted aircraft. The cabin retrofit can be described as an aircraft modification, during which parts of the passenger cabin are replaced to face wear and tear and to update the cabin to new layouts. Hence, a new cabin is being developed for an already existing aircraft, manufactured and finally installed into the specific airframe (Moenck et al. Reference Moenck, Laukotka, Krause and Schüppstuhl2022). This process requires solid planning data regarding the airframe early on, as each aircraft is unique, and information specific to the very aircraft the cabin is being planned for is required (Laukotka & Krause Reference Laukotka and Krause2023). Fortunately, aviation is actually characterised by product families. The famous A320 family consists of the basis-variants A318, A319, A320 and A321, which are mainly differentiated by their length and, thus, capacity. However, most aspects of these aircraft are the same. This existing variance aligns with the previously described and conventional variability within product families. Each of these product variants is manufactured multiple times, and thus, multiple instances with identical layouts and states are delivered to the airline.

Again, with time, deviations between the once identical instances arise. Despite there being documentation for every planned modification to the aircraft, they are usually limited to the respective area of the aircraft the modification was done to and separated by the different affected domains (electric, structure, water/waste, etcetera). As a result, the available documentation is fragmented and must be manually stitched together to allow for a somewhat realistic insight. This poses a real challenge in determining the aircraft’s actual state, as required for planning and developing the new interior during the cabin retrofit (also see Figure 11). As also within the earlier stages of the product life, solid documentation of the product family will help to cope with this challenge, as it greatly reduces the variability by clearly structuring and defining the variance and, thus, easing the handling of information for the engineers handling the data for the retrofit (Laukotka, Hanna, & Krause Reference Laukotka, Hanna and Krause2021). At this, two typical scenarios must be differentiated: The retrofit performed by the original manufacturer or a third party.

In case the manufacturer performs the retrofit, like the described example of the bending machine, detailed as-planned information about the product and the family structure is available. Tracking the state of the products after their production corresponds to the current concepts of Digital Twins as presented, for example, by Stark et al. (Reference Stark, Anderl, Thoben and Wartzack2020). As the amount of information rises when considering product families, a model-based approach can again assist with handling the data (Laukotka & Krause Reference Laukotka and Krause2023). Because in this scenario, the original manufacturer does the retrofit, ideally, these models already exist from the phase of product creation, as described in earlier sections. Thorough modelling and availability of information enable the switch between variants during the retrofit or even the retrospective implementation of new variants into the product family. Much information about a specific aircraft can be easily obtained by accessing information about another variant or the product family. The available information regarding the product family makes the variance easily handled. However, the deviance, albeit minor, needs to be identified. Based on the documentation described above, this task can be accomplished, especially with the overall insights the manufacturer has generally available.

The information deficit is more significant if a third party performs the retrofit, like specialised maintenance- and retrofit organisations. The as-planned information about the product, especially the product family, is unavailable, and a Digital Twin of the product would have to be initialised mid-life, based on the limited information (Moenck et al. Reference Moenck, Laukotka, Krause and Schüppstuhl2022). Because of the similarity of aircraft and their underlying family structure, besides the top-down approach of the developer and manufacturer, there is a bottom-up approach of iteratively gaining the required information. Some information can be classified as generic and applicable for all aircraft (of the same type or fleet), while others are specific to the aircraft at hand (Laukotka & Krause Reference Laukotka and Krause2023). A thorough modelling of information on these different levels, iteratively gained from generally available data and previous retrofits, allows for compiling enough knowledge to plan and perform the retrofit. Compared to the first scenario, this depicts a much bigger task. The vast number of documents required for the certification of each individual aircraft poses a challenge and a chance at the same time in this regard.

Both examples of products and the depicted scenarios of the retrofit show how the occurring variability can be handled at least partly by considering the underlying product family. Model-based approaches, created top-down during the product creation or bottom-up mid-life can once again help with this aspect of PFE.