1. Introduction
The future of product development will be challenged by the development of “advanced systems [− the] goods and services of tomorrow” (Dumitrescu et al., Reference Dumitrescu, Albers, Riedel, Stark and Gausemeier2021). These advanced systems can be described from four perspectives. First, these systems are characterized by an increasing degree of autonomy. Second, as product-service systems, the role of digital services and business models is highly important. Third and fourth, advanced systems are themselves or are part of a system of systems. Thus, they are systems that dynamically interact with other systems and have an interface with humans in the sense of socio-technical systems (Dumitrescu et al., Reference Dumitrescu, Albers, Riedel, Stark and Gausemeier2021). To handle the complexity of these advanced systems in product engineering, the efficient reuse of already existing knowledge and technologies, as well as existing/known (sub-)systems, is inevitable and a major competitive factor. Besides, the reduction of development time and cost, as well as the development risk of product development projects, are general goals and requirements of product engineering that can be addressed by efficient reuse.
Recent publications state that Systems Engineering will, in the future, largely be model-based (International Council on Systems Engineering (INCOSE), 2021). While traditional document-centric development approaches create a large number of independent, unlinked documents (e.g., specifications, test plans, etc.), Model-Based Systems Engineering (MBSE) aims to use a central system model as a central source of information (Walden et al., Reference Walden, Roedler, Forsberg, Hamelin and Shortell2015). The intended benefits of introducing MBSE include improved interdisciplinary communication and better storage and reuse of knowledge. Therefore, modeled information can be stored in a central model repository but displayed in various views (e.g., different diagrams, matrices, etc.). Following Dumitrescu et al. (Reference Dumitrescu, Albers, Riedel, Stark and Gausemeier2021), MBSE approaches are vital to developing advanced systems successfully. Thus, they can support the reuse and management of design and product knowledge across various generations and variants of a system, which can be in development simultaneously (Albers et al., Reference Albers, Dumitrescu, Gausemeier, Lindow, Riedel and Stark2022).
To reach a continuous and consistent development process over multiple generations and to enable the reuse of already created models in addition to further internal or external references, their structured modeling is a prerequisite. Albers et al. provide the theoretical backbone with the reference system (Albers et al., Reference Albers, Rapp, Spadinger, Richter, Birk, Marthaler, Heimicke, Kurtz and Wessels2019b). The subject of this contribution is the investigation and definition of this system’s internal structure and organization as the basis for its thorough modeling.
As the basis, in Section 1.1, we will first present the state of research in knowledge and technology reuse, focusing on the model of PGE and the reference system. Second, Section 1.2 introduces established process models of product engineering and the system triple of product engineering (system of objectives, operation system, system of objects) as the fundamental underlying model. The system triple of product engineering will be used as the basis for structuring the reference system in this contribution.
1.1. Reuse of knowledge, technologies, and other subsystems in product engineering
In classical product engineering, a basic distinction is made between three types of design. The first type, original design, solves new engineering tasks and problems by incorporating new combinations of known solution principles or newly developed solution principles. The second type is the adaptive design. In adaptive design, known and established solution principles are maintained, but the embodiment is adjusted according to new requirements. Third, variant design describes rearranging and resizing already existing parts and subsystems within predefined limits while maintaining the solution principle. However, a specific distinction is hardly possible for specific system designs (Pahl et al., Reference Pahl, Beitz, Feldhusen and Grote2007; Ehrlenspiel, Reference Ehrlenspiel2009; Feldhusen and Grote, Reference Feldhusen and Grote2013). Furthermore, purely original design projects are a rarity in actual corporate product engineering. Ehrlenspiel talks about 10% of design tasks being original design tasks (Ehrlenspiel, Reference Ehrlenspiel2009). In their study, Iyer et al. concluded that 80% of subsystems that were planned to be original designs could be developed by adjusting or even carrying over already existing designs (Iyer et al., Reference Iyer, Jayanti, Lou, Kalyanaraman and Ramani2005). Albers et al. confirm these results with their study showing that only 7% of the engineering activities of the participants (corporate product engineers) focus on pure new development while the rest is reusing already existing elements (Albers et al., Reference Albers, Bursac and Wintergerst2015). The benefits of reusing already existing solution principles or designs are the reduction of technical and economic risk (Deubzer and Lindemann, Reference Deubzer and Lindemann2009; Eckert et al., Reference Eckert, Alink and Albers2010), as well as the reduction of development time and increase of design flexibility (Sivaloganathan and Shahin, Reference Sivaloganathan and Shahin1999; Eckert et al., Reference Eckert, Clarkson and Zanker2004; Iyer et al., Reference Iyer, Jayanti, Lou, Kalyanaraman and Ramani2005; Ulrich and Eppinger, Reference Ulrich and Eppinger2016).
The role of (internal and external) knowledge and design reuse is widely accepted as vital in product development (cf., e.g., Pahl et al., Reference Pahl, Beitz, Feldhusen and Grote2007; Ehrlenspiel, Reference Ehrlenspiel2009; Ulrich and Eppinger, Reference Ulrich and Eppinger2016), and various approaches exist to describe the design process based on already existing knowledge and designs such as case-based reasoning (Maher and de Silva Garza, Reference Maher and de Silva Garza1997), C-K Theory (Hatchuel and Weil, Reference Hatchuel and Weil2003), or the model of product generation engineering (PGE) (Albers et al., Reference Albers, Bursac and Wintergerst2015). However, the literature does not provide detailed information on how the existing knowledge and designs can be modeled to serve as input for the development of a new product or system.
Setting up on the literature and empirical studies, Albers et al. designed the model of PGE with the claim to enable the description and modeling of any product development. Thereby, they provide a solid basis for design research. The basic assumption of the PGE model is that the development of a new product generation is always based on references, already existing designs, technologies, or knowledge (Albers et al., Reference Albers, Bursac and Wintergerst2015). All these references are modeled as reference system elements within the reference system and form the starting point of every product development. Albers defines the reference system as follows:
Definition of the reference system
The reference system for the development of a new product generation is a system whose elements originate from already existing or already planned socio-technical systems and the associated documentation and are the basis and starting point for the development of the new product generation (Albers et al., Reference Albers, Rapp, Spadinger, Richter, Birk, Marthaler, Heimicke, Kurtz and Wessels2019b, p. 1699).
As illustrated in Figure 1, Albers models the development of a new product generation (Gn) based on the corresponding reference system Rn through three types of variation. Reference system elements are either carried over or developed newly. During carryover variation (CV), only the interfaces are adjusted during system integration if necessary. In the new development of subsystems, reference system elements are either adjusted by attribute variation (AV) or principle variation (PV). While the solution principle is maintained and only the attributes such as embodiment are altered during attribute variation, the solution principle is modified during principle variation. Here, a principle variation always requires attribute variation, too (Albers et al., Reference Albers, Bursac and Wintergerst2015, Reference Albers, Rapp, Spadinger, Richter, Birk, Marthaler, Heimicke, Kurtz and Wessels2019b, Reference Albers, Rapp, Fahl, Hirschter, Revfi, Schulz, Stürmlinger and Spadinger2020).
Figure 1. The reference system within the model of PGE - Product generation engineering. Every new product generation is developed based on its reference system through carryover variation (CV), attribute variation (AV), and principle variation (PV) (Albers et al., Reference Albers, Rapp, Spadinger, Richter, Birk, Marthaler, Heimicke, Kurtz and Wessels2019b).
The reference system elements can originate from various sources. While the most intuitive source is the predecessor (Gn-1) of the new product generation and the associated documentation, e.g., competitor products or research projects can be analyzed to collect additional reference system elements (Albers et al., Reference Albers, Rapp, Spadinger, Richter, Birk, Marthaler, Heimicke, Kurtz and Wessels2019b). Specifically, as visualized in Figure 2, reference system elements can originate from different knowledge spaces. Kempf et al. distinguish 12 knowledge and technology spaces. Reference system elements can originate from the same branch (1), an other branch (2), (university) research (3), or society or nature (4). All knowledge and technology elements within these areas can either be part of the corporate knowledge already (a), be part of a knowledge space accessible knowledge space (e.g., competitor products or standards) (b), or be part of a knowledge space not accessible for the company (e.g., the know-how of competitor, classified (military) research projects) (c). Figure 2 also shows a collection of methods and tools to identify and collect reference system elements from the various knowledge spaces (Kempf et al., Reference Kempf, Rapp, Behdinan and Albers2023).
Figure 2. The reference system elements identification atlas depicts 12 knowledge spaces that offer possible reference system elements and a collection of methods and tools to harvest these knowledge spaces. Reference system elements can originate in the same branch (1), another branch (2), research (3), or in society/nature (4). At the same time, elements of these different areas can already be part of the corporate knowledge (internal knowledge) (a), part of the total accessible knowledge (b), or part of the globally existing knowledge (c), spanning the 12 knowledge spaces (Kempf et al., Reference Kempf, Rapp, Behdinan and Albers2023).
Especially research is a valuable source for additional reference system elements as it provides cutting-edge knowledge and technology (EFI – Commission of Experts for Research and Innovation, 2022; Guerrero et al., Reference Guerrero, Urbano and Herrera2019). However, barriers and challenges in searching for reference system elements in research, as well as applying and using these in a corporate setting, complicate the usage (Kempf et al., Reference Kempf, Thapak, Rapp, Behdinan and Albers2023).
1.2. Agile product engineering
Besides the technological side of developing new product generations, an efficient product engineering process is vital for successfully developing innovations. To establish a reactive and future-oriented process development process, engineering companies increasingly apply agile elements to their processes (Atzberger et al., Reference Atzberger, Nicklas, Schrof, Weiss and Paetzold2020). Agile elements such as SCRUM are already well-established in software development (Gloger, Reference Gloger2016). However, transferring these agile approaches into non-software environments is still challenging (Albers et al., Reference Albers, Heimicke, Müller and Spadinger2019a; Ahmad, Reference Ahmad, Tian and Chang2020).
Process models common in product engineering are presented and compared in Figure 3 based on (Wynn and Clarkson, Reference Wynn and Clarkson2018). Prominent representatives of these models are the reference model of strategic planning and integrative development of market services (Gausemeier et al., Reference Gausemeier, Dumitrescu, Echterfeld, Pfänder, Steffen and Thielemann2019) based on the three-cycle model of product creation (Figure 3, 1) (Gausemeier et al., Reference Gausemeier, Ebbesmeyer and Kallmeyer2001), or the munich procedural model (Figure 3, 2) (Lindemann, Reference Lindemann2009). These aim at a holistic approach. The V-model of the VDI 2206 standard represents a more branch-specific process model for mechatronic systems with a higher degree of formalization (Figure 3, 3) (VDI Verein Deutscher Ingenieure e.V., 2004). Elements of the stage gate process (Figure 3, 4) (Cooper, Reference Cooper1994) are carried over to many other process models.
Figure 3. Overview of process models in product engineering (Verein Deutscher Ingenieure, 2019).
Figure 4. The integrated product engineering model (iPeM) in the context of product generation engineering (PGE) (Albers et al., Reference Albers, Reiss, Bursac and Richter2016).
With the integrated product engineering model (iPeM) (Figure 3, 5), Albers et al. offer an integrated approach that considers both the engineering design process and process management. As a meta-model, the iPeM is a generic process model that includes all relevant structures and elements to enable agile product engineering processes (Albers et al., Reference Albers, Reiss, Bursac and Richter2016).
Figure 5. Extended system triple of product engineering (Albers et al., Reference Albers, Lohmeyer and Ebel2011).
The advantage of product engineering models with a lower degree of formalization is the higher flexibility as they are adaptable to different types of engineering projects (e.g., regarding the engineering domain or field of application). On the other hand, a high degree of detail provides the user of the process model with a detailed orientation within the process by describing the steps within the engineering activities. Using the iPeM, a meta-model with a high degree of detail but a low degree of formalization, as the foundation for our further work enables a domain and application independent consideration of the reference system.
As depicted in Figure 4, the iPeM integrates the development of the validation system, production system, and strategy, as well as further product generations, in addition to the development of the product generation Gn into one model.
Here, Gn is the product generation currently under development, which will be introduced to the market next. Depending on the field and company, usually the successor product generations Gn+1 or even Gn+2, etc., are already under development in parallel with Gn. Setting up on the system theory and system triple of (Ropohl, Reference Ropohl1975), the iPeM describes product engineering as the continuous interaction of the system of objectives, operation system, and system of objects (cf. Figure 5). In this sense, product engineering is a socio-technical system. The core focus is the operation system. This system contains all relevant resources (including, e.g., the product developers) necessary to realize the product. The operation system synthesizes and concretizes the system of objectives based on its time-dependent knowledge base. Consequently, the system of objectives contains all objectives, boundary conditions, and requirements, including their interrelations regarding the product engineering project. Based on the analysis of the system of objectives, the solution space is limited, and the operation system synthesizes the system of objectives. Here, the system of objects contains all intermediate and final results of the engineering process. Finally, the system of objects is analyzed (validated against the system of objectives) by the operation system to enlarge the knowledge base. The systems of objectives and objects are developed in coevolution in multiple iterations, as illustrated in Figure 5 (Albers et al., Reference Albers, Lohmeyer and Ebel2011).
The definitions of these systems are given in the following (Meboldt, Reference Meboldt2008) based on (Albers and Meboldt, Reference Albers and Meboldt2007):
1.3. Definition of the system of objectives
The system of objectives describes all relevant objectives, their boundary conditions, dependencies, and interactions. The system of objectives contains the explicit documentation of the information required for realization. The elements in the system of objectives must be comprehensible and justified. It contains only information and no physical objects and is thus the repository of the confirmed knowledge and planning of product development. The system of objectives evolves throughout the engineering project.
1.4. Definition of the operation system
Operation systems are socio-technical systems that perform structured and interconnected activities for transformations between the systems of objectives and objects. Operation systems are composed of activities, executing resources, resources to be used, and temporal dependencies. The systems of objectives and objects are created by the operation system and are mutually interrelated only through the operation system.
1.5. Definition of the system of objects
Systems of objects are artifacts, i.e., tangible and intangible results of the operation system. The purpose of a system of objects is described in the corresponding system of objectives. In product engineering, a corresponding system of objectives must exist for each system of objects. The system of objects evolves throughout the engineering project.
In the iPeM, the operation system is structured by the activities of product engineering and problem-solving (SPALTEN) that form the matrix of product engineering and the phase model. The phase model is used to plan and control the engineering process (Albers et al., Reference Albers, Reiss, Bursac and Richter2016).
As presented before, the development of a new product generation is based on a reference system. Thus, reference system elements form the basis and starting point for the development and setup of all systems of the system triple of product engineering. Accordingly, Albers et al. propose to apply the structure of the system triple on the reference system to further structure the reference system as illustrated in Figure 6 (Albers et al., Reference Albers, Hirschter, Fahl, Woehrle, Reinemann and Rapp2020). Thus, it becomes obvious that not only elements for the development of the system of objects of the Gn serve as reference system elements. The development of the system of objectives and the operation system of the Gn is based on reference system elements, too. Examples of reference system elements for the operation system could be creativity methods for creative problem solving, standards or guidelines to follow in the engineering process, and so forth. Similarly, for example, performance data of competitor products could serve as reference system elements of the system of objectives. The reference system of objectives, reference operation system, and system of objects are connected with the development of the Gn through the operation system of Gn and are used to create the system of objectives and objects. However, no further definition of the reference systems of objectives and objects and reference operation systems are provided.
Figure 6. Applying the structure of the system triple to organize the reference system Rn and illustrating its relation with the system triple of the current product generation under development Gn (Albers et al., Reference Albers, Hirschter, Fahl, Woehrle, Reinemann and Rapp2020).
2. Research profile – aims and methodology
2.1. Research aim and research questions
As we presented in the introduction, product engineering is always based on reference system elements. With their work on the model of PGE (Albers et al., Reference Albers, Bursac and Wintergerst2015) and the reference system (Albers et al., Reference Albers, Rapp, Spadinger, Richter, Birk, Marthaler, Heimicke, Kurtz and Wessels2019b), Albers and his team already provide a formalized description and model of the interrelations of the system in development of the product engineering project and its reference system elements. However, due to the high complexity and individualism of product engineering projects and the products to be developed themselves, a great variety of elements serve as reference system elements, too. To better handle these diverse reference system elements and to be able to model them beneficially, we identified a need to concretize the general definition of the reference system and its elements. This is necessary to consistently model and support the engineering processes of multiple sequential and parallel product generations. Thus, our primary goal of this paper is to define the different types of reference system elements that are used in product engineering projects and provide a meta-model of the reference system. To achieve this goal, we formulated the following research questions, which we will answer in this paper:
-
1. What elements can serve as reference system elements in product engineering projects?
-
2. How can the different types of elements be modeled within the reference system to enable the continuous and consistent development of multiple product generations using model-based engineering approaches?
Answering these questions will enable the modeling and support of the design of specific reference systems in product engineering projects. Furthermore, the formalization of the reference system will make it accessible for research and the development of supportive design methods and tools in advanced engineering, for example, based on model-based system engineering.
2.2. Research approach
To answer the research questions and achieve the formulated aim, we followed a case study-based approach, as illustrated in Figure 7, which we structured according to the design research methodology (DRM) (Blessing and Chakrabarti, Reference Blessing and Chakrabarti2009).
Figure 7. Research approach following the design research methodology (DRM) (Blessing and Chakrabarti, Reference Blessing and Chakrabarti2009).
In the first step (descriptive study I [DS I]), we retrospectively analyzed three case studies to identify and collect the reference system elements used in different types of product engineering projects or activities. These case studies describe product engineering projects or activities in different settings, as described in Table 1. Thereby, we answered the first research question.
Table 1. Case studies used in the different DRM stages
In the second step (prescriptive study [PS]), we analyzed and clustered the identified reference system elements by comparing them and their usage in the engineering project to the concept of the system triple of product engineering. Consecutively, we derived definitions for the identified clusters. To ensure consistency with the model of PGE and the definition of the reference system, we used this definition as the basis for this step.
In the third step (descriptive study II [DS II]), we analyzed three more case studies (compare Table 1) to initially validate our model of the reference system and the definitions of the reference system’s subsystems. Therefore, we used the definitions derived in the second step to categorize the reference system elements of these product engineering projects. Thus, we answered the second research question in the second and third steps.
In all cases, the authors of this paper have direct access to the projects.
We are aware that the individuality and complexity of product engineering projects and the developed products themselves will not allow us to cover all possible reference system elements. However, we believe that the first three used case studies provide a sufficient range of reference system elements to enable us to derive definitions of all relevant subsystems of the reference system. We initially validate this assumption in the third described step by analyzing three more case studies.
3. Reference system elements used in practice – Case studies
In the following, we present three case studies of engineering projects. We briefly present the projects with a focus on reused elements (knowledge, technologies, or other subsystems) and collect these reference system elements.
3.1. Case study a – Engineering contractor: Development of a light source
In the first case study, we analyzed the development of a new generation of a light source and its related cooling system for diagnostic applications in medicine/pharma at an engineering contractor. As an engineering contractor, the company provides engineering services such as designing different products or subsystems for its customers.
In this case, the task was to develop a new generation of a light source that reduces acoustical noise. The starting point of the development project is the current generation of the light source with its documentation. Here, drawings, calculations, and simulation documents were included in the documentation. These documents served as the basis for deriving the requirements for the new generation of the light source. Additional requirements were derived based on the development goal of reducing the noise. These requirements had to be derived within the project. In the first step, the participating engineers called on their experience to evaluate the current system together with the development goal and requirements to draw conclusions. Using creativity methods, the engineers first developed possible concepts with the corresponding requirements in an abstract form. Following the internal development process, the engineers executed specific dimensioning steps such as calculations and simulations to turn the abstract concepts into prototypes finally. These prototypes served to validate the fulfillment of the requirements.
Since this engineering process did not include a requirements management tool, these were documented in the contractor’s wiki tool using the notebook function. The engineering contractor stores other, more static, files and documents, such as standards or engineering guidelines, in a central repository. After finalizing the engineering project, the engineering contractor transfers all documents necessary for the approval status to the customer.
Analyzing this case study makes it obvious that the engineering team used reference system elements from outside the development project. However, during the project, they came up with intermediate solutions, such as abstract concepts, which can be considered reference system elements in the subsequent development step (e.g., producing a prototype) of the same project. In the end, the engineering contractor handed over the documentation of the new generation of the light source to their customer. Accordingly, all the handed-over documentation served as reference system elements for the customer. The identified reference system elements are summarized in Table 2.
Table 2. Reference system elements used in case study a
3.2. Case study b – Automotive OEM: Requirements management and development of the system of objectives of a new product generation
In this case study, we analyzed the engineering activities of requirements management and the development of the system of objectives for a planned new product generation (Gn+1) at an automotive OEM.
The requirements specification is based on the product objectives of the Gn+1 derived from the stakeholder needs. Depending on the needs and objectives, the product developers partially carried over requirements from the previous product generation (Gn-1) and from topic-specific requirement bundles that apply across projects (e.g., requirements for the transportability of a vehicle). To leverage further efficiencies, the product developers reused the formulation of requirements from the reference system depending on the needs and objectives. Thus, only the attributes of the requirements had to be varied (e.g., 0–100 acceleration, range, etc.). Furthermore, the product developers used reconstructed requirements from competitor vehicles to quantify the requirements.
In addition to the pure reuse of the requirement sets, the linked attributes (e.g., the person responsible for implementation, source of requirement, etc.), as well as additional in-depth information for detailing the requirements (e.g., explanation of a particular driving cycle (WLTP)), were carried over in some cases, too. Furthermore, the product developers carried over the chapter structure of the requirements specification from the previous product generation to additionally support and structure the reuse of requirements from the reference system.
The product developers used method descriptions that are valid across projects, such as guidelines and training documents, as methodological support for their requirements management activities. In addition, expert knowledge regarding the partially implicit specification procedure was used. The identified reference system elements are summarized in Table 3. Since we do not consider the development of the system of objectives of the product generation, which will be introduced next (Gn) but the following generation (Gn+1), the reference system elements are also of the reference system Rn+1.
Table 3. Reference system elements used in case study b
3.3. Case study c – University Institute: MBSE for knowledge reuse in test environment development
In the third case study, we analyzed research on an MBSE methodology developed at a university research institute (Mandel et al., Reference Mandel, Wolter, Bause, Behrendt, Hanf and Albers2020). This methodology aims at supporting knowledge reuse in the development of validation environments. Thereby, developers shall be supported in building or selecting appropriate validation environments based on a given validation objective. The methodology encompasses an MBSE method for creating a model-based library for structuring and storing knowledge about (sub-)systems and components of test environments. To develop and apply the MBSE methodology, the development of a new generation of a test environment for testing brakes has been analyzed. This case is described in the following.
A given validation objective was to understand better the adhesion-sliding behavior of the friction pairing in the brake and to characterize its influencing parameters so that reliable evaluation criteria and recommendations for test procedures could be derived. To set up and design the test environment, the researchers modeled the tribology system of the brake in depth as well as influencing parameters from the residual system (i.e., the car) and its environment (e.g., humidity or temperature).
In a first generation (G1) of the validation environment, difficulties with the measurement of the twist angle of the brake have been identified. When torques were applied to the system, a slight rotation of the brake was measured even though there was no rotation on the actual components. This prevents a reliable measurement of brake slipping with increasing torque. Analyzing all components located in the measurement chain between the brake and the angle measurement, the torsional stiffness of the downstream shafts was identified as the cause. The effect of this torsional stiffness was underestimated or not taken into account for the first generation of the test environment.
To correct those measurement errors in the second generation (G2) of the test environment, the experience of the researchers involved was used. The validation objective remained the same for the new generation. The researchers implemented (virtual) compensation measures in the torsion measurement. For this purpose, the researchers used the known torsional stiffness from the previous generation to calculate a virtual torsion for a known torque. In addition, the researchers optimized the arrangement and implementation of the axial force measurement in the force flow based on expert knowledge. Finally, expert knowledge was used to optimize the operating principle for the brake actuator. The hydraulic actuator, which prevents dynamic adjustments of axial forces during the braking process, was questioned, and a mechatronic actuator was proposed as a more suitable solution. The identified reference system elements are summarized in Table 4.
Table 4. Reference system elements used in case study c
4. Three Subsystems within the Reference System
In the following step, we clustered all reference system elements identified in the case studies a, b, and c (cf. Tables 2, 3, and 4) into different groups according to their type in Table 5.
Table 5. Three types of reference system elements clustered regarding their intended use in the current project
The manifestation of the characteristics of reference system elements depends on the point of view as well as the goal of the specific project. The system triple of product engineering is a model. Thus, following Stachowiak (Stachowiak, Reference Stachowiak1973), this model and its manifestation depend on the point of view of the modelers and addressees as well as the aim of the model. Clustering the reference system elements, we followed the point of view of the specific project. These considerations became particularly important when we were clustering the reference system elements of case study b (cf. Figure 8). While elements such as
$ {RSE}_{n+1}^{b,1} $
: Requirements of the previous vehicle generation (
$ {G}_{n-1} $
) have been taken from the system of objectives of the previous product generation of vehicles (
$ {G}_{n-1}^{Vehicle} $
) (cf. Figure 8, top), they form the basis for the targeted result of the project of case study b. The goal of case study b is the derivation of the requirements specification. In that sense, the requirements specification will be part of the system of objects in this specific engineering project (
$ {G}_{n+1}^{Vehicle, Requirements\ Spec.} $
) (cf. Figure 8, bottom). Subsequently, if we consider case study b as a subproject of the development project of the planned subsequent vehicle generation
$ {G}_{n+1}^{Vehicle} $
, these elements will form the basis for the system of objectives of this development project of the planned subsequent vehicle generation
$ {G}_{n+1}^{Vehicle} $
(cf. Figure 8, middle).
Figure 8. Using reference system elements across product generations depending on the point of view of the project. In case study b, the subproject
$ {G}_{n+1}^{Vehicle, Requirements\ Spec.} $
, elements from the system of objectives of
$ {G}_{n-1}^{Vehicle} $
are used as reference system elements for the development of the system of objects due to the nature and target of
$ {G}_{n+1}^{Vehicle, Requirements\ Spec.} $
. On the
$ {G}_{n+1}^{Vehicle} $
-level point of view, these elements are used for the development of the system of objectives.
Even though we did not discover it by analyzing the case studies a, b, and c, the same issue can arise for the other systems of the system triple of product engineering (e.g., if the goal of a project is the definition of an engineering process or methods to follow/use in other projects such as MBSE methods).
In that sense, we used the intended use of the elements in the project under consideration rather than the origin of the elements to sort the elements into the three clusters shown in Table 5. In the first cluster, we collected all reference system elements that were used as a basis for the development of the system of objectives (cf. the definition in Section 1.2) of the project of the respective case study. In analogy, we collected reference system elements that were used as the starting points of the development of the operation system and system of objects (cf. the definition in Section 1.2) of the projects in clusters two and three, respectively.
For example, in case study a,
$ {RSE}_n^{a,9} $
: Creativity methods (i.e., the description of specific creativity methods) served as input to develop the operation system within the current engineering project Gn. Using the creativity methods, the engineers (also part of the operation system of Gn) developed concepts of the product generation in development (part of the system of objects of Gn). Another example is
$ {RSE}_n^{a,7} $
: Expert knowledge and experience of the engineering team. Without further context, this RSE could serve as the basis for the development of any of the three systems within the system triple of product engineering. However, in case study a, in this specific case, it was used to draw conclusions on the design of the product generation in development (G1). Thus, we categorized
$ {RSE}_n^{a,7} $
within the third column as an RSE for the system of objects of G1.
As is the case in
$ {RSE}_{n+1}^{b,5} $
: Reconstructed requirements of competitor vehicles, not all elements within the reference system can be carried over directly. Some of them are reconstructed by the engineers based on other reference system elements.
In the following, we used the presented understanding to define three subsystems of the reference system – the reference system of objectives, reference operation system, and reference system of objects – based on the three clusters:
4.1. Definition of the reference system of objectives
The reference system of objectives is a subsystem of the reference system containing elements of the character of the system of objectives’ elements. It is the basis and starting point for the development of the system of objectives of the new product generation Gn.
The elements of the reference system of objectives are
-
• carried over from existing or planned socio-technical systems and the associated documentation directly, or
-
• reconstructed (via the operation system of the Gn) from the reference operation system’s elements or reference system of objects’ elements.
4.2. Definition of the reference operation system
The reference operation system is a subsystem of the reference system containing elements of the character of the operation system’s elements. It is the basis and starting point for the planning and definition of the operation system of the new product generation Gn.
The elements of the reference operation systems are
-
• carried over from existing or planned socio-technical systems and the associated documentation directly, or
-
• reconstructed (via the operation system of the Gn) from the reference system of objectives’ elements or reference system of objects’ elements.
4.3. Definition of the reference system of objects
The reference system of objects is a subsystem of the reference system containing elements of the character of the system of objects’ elements. It is the basis and starting point for the development of the system of objects of the new product generation Gn.
The elements of the reference system of objects are
-
• carried over from existing or planned socio-technical systems and the associated documentation directly, or
-
• reconstructed (via the operation system of the Gn) from the reference system of objectives’ elements or reference operation system’s elements.
As illustrated in Figure 9, elements from the respective subsystem of the reference system are used to form the basis and starting point to set up the corresponding systems of the system triple of the Gn by the operation system of the Gn. The engineers, managers, strategists, and so forth make use of these elements by applying the variation operators CV, AV, and PV according to the model of PGE on the elements.
Figure 9. Subsystems of the reference system and their corresponding systems of the system triple of product engineering.
5. Validation: Challenging the reference system of objectives, reference operation system, and reference system of objects
To initially validate the modeling of the reference system as the combination of the three subsystems, reference system of objectives, reference operation system, and reference system of objects, we used three more case studies. Here, we once again collected the reference system elements used in the different case studies and used the definitions we presented in the previous chapter to sort the reference system elements.
5.1. Case study d – Machinery: Development of a picking robot in a student innovation project in collaboration with a machinery OEM
In the first case study for validation of the definition of the subsystems of the reference system, we analyzed an innovation project that was conducted in collaboration with student development teams, an industrial partner, and a university institute. Here, the student team developed a picking robot for the industrial partner while being coached and led by researchers of the university institute.
In the project kick-off, the industrial partner presented the development task and the company’s product portfolio to the development teams. Here, the development task served as the basis for the development team to derive the general objectives of their project. In the ongoing project, the developers used various reference system elements to specify and further develop their system of objectives. For example, they used the performance specifications of previous generations of picking robots already working in the field to derive the performance requirements, or safety requirements descriptions from food processing and handling to derive material and lubrication requirements. They defined other objectives based on the experience of experts of the industrial partner. Based on the validation results of their prototypes, the developers concretized their requirements even further.
The development team developed the picking robot as an advanced variant of an existing picking robot of the industrial partner. Thus, they used the existing picking robot to specify the requirements and the design of the intersections of the main robot unit and the new picking unit. Furthermore, they used principles and mechanisms from 3D printers as reference system elements to design the motion system of the picking unit. For the calculation of the movements and picking speed, they relied on their own expertise and lecture notes from the engineering mechanics lecture.
During the development project, the researchers of the institute introduced and taught the developers various creativity and product development methods (e.g., scenario technology, persona method, rapid prototyping, MBSE). Furthermore, the researchers provided templates for intermediate results (e.g., product profile, use-value analysis) and their presentations. The developers relied on the experience of the researchers for the product development process, too. The identified reference system elements are listed and allocated to subsystems of the reference system in Table 6.
Table 6. Reference system elements of case study d allocated to the respective subsystems of the reference system
5.2. Case study e – University Institute: Development of a computational optimization method for ribbed long fiber reinforced thermoplast structures
In the second case study, we analyzed the development of a computational optimization method at a university research institute. The optimization method supports developers in finding optimized designs for ribbed, long fiber-reinforced thermoplast structures.
Building on a previously developed optimization method for beaded long fiber reinforced thermoset structures, parts of the requirements were carried over from the previous optimization method. Furthermore, the developers used design catalogs and basic experiences from literature to derive, first, requirements regarding the geometries of ribs that needed to be considered and, second, related functions to be implemented in the optimization method. Since the manufacturing process of long fiber reinforced polymers is crucial for the mechanical properties of the component, the developers adopted requirements delivered by manufacturing engineers and research projects, for example, minimum rib thickness or height. Finally, the developers used requirements from software developers to ensure the implementation of a coupling of several software tools necessary for the optimization process.
Apart from the knowledge gained from the previous optimization method, saved in documentation and a dissertation, the developers could reuse the foundation of several components of the developed code for the optimization method. The dissertation also delivered insights on how to couple different tools and parts of the optimization method. To validate single aspects of the optimization method, for example, the manufacturing process simulation, the developers used results from tests and experiments carried out within other research projects based on a joined demonstrator geometry from a previous research project. To set up and validate the optimization method, the developers reused software tools already available at the research institute, which were used in the development of the previous generation of optimization method. The identified reference system elements are listed and allocated to subsystems of the reference system in Table 7.
Table 7. Reference system elements of case study e allocated to the respective subsystems of the reference system
5.3. Case study f – Machinery OEM: Development of an automation solution for sheet metal handling
The third example is the development of a new automation solution for the automated loading and unloading of laser-cutting machines for sheet metal. A new product generation was developed based on the characteristics of the previous generation of the system and the findings from the analysis of the usage of the previous system generation on the customer’s shop floor.
A particular challenge in the development project was the transfer of the architecture of the previous product generation into a modular architecture. Consequently, the transferability of modules in the automation solution for laser cutting machines to automation solutions for different types of machine tools had to be taken into account during the development process. The definition of the module scopes and the physical design of the modules, therefore, required an extensive analysis of reference system elements of the machine tools to be automated as well as of reference system elements of the corresponding automation solutions already developed.
Sensible options for standardization in the sense of modularization included the gripper unit, as well as the kinematics and structure of the machine setup. The analysis of various reference system elements carried out as part of the development process showed great potential for the standardization of components, particularly in these parts of the automation solutions. For the further development of the system of objectives of the new automation solution, the preceding gripping units for the machine tools in the area of laser flatbed and punching were fundamentally analyzed. Through a better understanding of the customer’s usage of the technical systems by analyzing machine data, requirements could be validated. In addition, machine data was increasingly used to analyze the usage of reference system elements, for example, to validate functions or to define the functional scopes in modules based on the usage profiles of functions. Information from the described validation enhanced the system of objectives. Furthermore, knowledge about frequently occurring defects and the majority of manufactured geometries of parts in terms of descriptive parameter combinations of, for example, sheet thickness, edge lengths, and internal cutouts were used to add, modify, or delete requirements.
Furthermore, machine data analyses of previous product generations could be used to show comparisons concerning history, thus extending the system of objects. In addition, the adoption of existing kinematics and structure of the Gn-1 represented a direct evolution of the system of objects.
The need to include various machine variants created a high degree of complexity in the development project. Through the systematic application of model-based systems engineering, functional interrelationships in the sense of functional modeling and physically connected elements in the sense of physical modeling were mapped. The initial system model was created based on the architecture of the previous automation solution and is adapted in parallel to the development progress over the iterations. The identified reference system elements are listed and allocated to subsystems of the reference system in Table 8.
Table 8. Reference system elements of case study f allocated to the respective subsystems of the reference system
During the analysis of the case studies, the definitions of the reference systems of objectives and objects and the reference operation system proved to be good guidelines for structuring the elements used in the development projects as a basis for consistent modeling.
As already expected after the case studies a, b, and c and considered in the definitions, reference system elements cannot always be allocated to only exactly one subsystem of the reference system.
$ {RSE}_n^{e,2} $
of case study e was used to develop elements of the Gn’s systems of objectives and objects.
6. Conclusions and outlook
Analyzing the case studies in Chapter 3, we showed that three different types of elements are used as reference system elements in product engineering. The elements of these three subsystems are related to the three systems of the system triple of product engineering (cf. Figure 5). One subsystem of reference system elements is used to develop the system of objectives and the other subsystems of reference system elements are used to develop the operation system and system of objects, respectively. Thus, the characteristics of the systems of the system triple of product engineering are well suited to structure the reference system internally. We introduced the three subsystems, the reference system of objectives, reference operation system, and reference system of objects, to structure the reference system. Here, describing and modeling the reference system elements as individual and unique elements is essential. Thus, it is possible to allocate them to exactly one subsystem of the reference system. For example, suppose a specific standard describes requirements that a new system has to meet and design features. In that case, this has to be modeled as two separate reference system elements within the two respective subsystems of the reference system (e.g., the DIN 743–2 provides input for requirements of using and designing shafts and design alternatives). Furthermore, reference system elements within one of the subsystems of the reference system and of different subsystems can be related to one another and dependent on each other. For example, the battery system of a battery-electric driven competitor car can be used as part of the reference system of objects to derive the system of objects of the own Gn. At the same time, the reference system element battery system can be analyzed to estimate the targeted range of the competitor car. This reconstructed target value can serve as part of the reference system of objectives to derive the system of objectives of the own Gn.
We are well aware that the selection of three individual case studies as the basis for developing our results and three more case studies to validate these results are not representative of product engineering in its entirety. However, we still believe in providing solid findings since three completely different case studies could validate our model of structuring the reference system. This explorative nature of our research suggests that our model is abstract enough to span the range of product engineering projects. Ultimately, “every engineering process is unique and individual” (Albers, Reference Albers2010, p. 4) somehow, and our model must be flexible enough to adjust to this uniqueness. By reusing and applying the concept of the system triple of product engineering, we can also benefit from its applicability in every product engineering project. However, we still need to validate our model continuously when dealing with other engineering projects.
Nevertheless, we believe that our findings provide a strong basis, especially for further research and the development of engineering support. The structuring of the reference system is the necessary prerequisite for the consistent modeling of engineering processes across generations and, thereby, enables an efficient engineering process. Thus, our results provide the basis for the development of MBSE approaches and tools that support product engineering. Due to the complexity of advanced systems, we believe that the MBSE-supported development of new systems or products in generations will form the basis of advanced systems engineering (cf. Albers et al., Reference Albers, Dumitrescu, Gausemeier, Lindow, Riedel and Stark2022; Dumitrescu et al., Reference Dumitrescu, Albers, Riedel, Stark and Gausemeier2021). The findings presented and condensed in the definitions of the subsystems of the reference system form the basis for introducing cross-generational engineering approaches using MBSE.
The synthesis of the reference system is a core aspect of the engineering process within this approach that requires creativity and skills in scouting. In the next steps, we intend to continue our research by exploring how the identification and selection of suitable reference system elements can be supported situation-specifically to support corporate product engineers develop their reference systems. Here, our goal is to methodological support the process of identification, formalization, and structuring of reference system elements for the synthesis of new product generations in any engineering process. Furthermore, we will conduct further research on the continuous modeling of the reference system and its evolvement across multiple product generations and product variants. In the long run, we believe our results will lead to model-based tool support for corporate product engineers and enable a consistent and efficient engineering process.
Financial support
The research documented in this manuscript/presentation has been funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation), project number 255730231, within the International Research Training Group “Integrated engineering of continuous-discontinuous long fiber reinforced polymer structures” (GRK 2078). The support by the German Research Foundation (DFG) is gratefully acknowledged.
Open access
