1 Introduction

The development context of mechatronic systems is subject to increasingly complex requirements that change dynamically [1]. They can be traced back to non-transparent product development processes with a large number of stakeholders that impose inhomogeneous and mostly implicit goals on the developed products. To meet the resulting uncertainties, companies started to implement agile approaches. They allow higher responsiveness to changes in the development context through an iterative and incremental procedure, compared to classic approaches such as the waterfall [2, 3].

Agile approaches such as Scrum according to Schwaber [4] or Design Thinking [5] make agile principles operational for self-organized and cross-functional developer teams through short sprints, continuous review and feedback loops [6]. Through this, developer teams follow an iterative approach to increase the customer value of a product in the best possible way [7]. However, these approaches usually address project management (Scrum) or creative problem-solving (Design Thinking) and do not take into account that products are mostly developed in generations and not "on white paper" [8]. Accordingly, they do not contain any mechanisms to stimulate the technical experience of the developers and do not integrate this experience into the development context. Especially in agile approaches, this is necessary, as physical prototypes are built for decision and validation purposes from the start of the development. The developers need to carry out design activities much earlier than usual. They need to identify technical details in reference elements (for example existing products), which are relevant for function fulfilment. These technical details can be various parameters of the embodiment, like geometric or material characteristics. An example of a technical detail is the stiffness of a bristle in a rotating brush in a mechanical weed removal product. This detail influences the products ability to remove weeds from joints in the pavement.

Tools like Computer-aided Design (CAD) and Computer-aided Engineering (CAE) exist to support developer teams in defining and understanding technical details. However, they usually require high modelling effort and are therefore difficult to use in early development phases. In agile processes, it is often necessary to build up a comprehensive understanding of embodiment function relations (EFRs) early in the projects conceptual stage. There, the product often is not defined to the extent that it is available as a fully parameterized CAE or CAD model. Therefore, functions are often implemented in wizard of oz prototypes [9]. In these prototypes, functions can be evaluated by customers before they are fulfilled through its technical details. However, to implement functions in the embodiment of the product, insights into the technical details are necessary. Modelling approaches exist, that support gain of insight in conceptual phases, but their application in agile processes is not yet supported. From this, the research question for this paper arises:

How can design engineers be supported in modelling relations of embodiment and function for gaining technical knowledge in agile processes according to the respective development situation?

To answer this research question, a guideline is developed that enables the modelling of EFRs in agile product development projects. In this framework, a modelling method for EFRs is integrated into an agile approach by using a problem-solving process. The guideline is derived from an analysis of the respective state of the art in agile development, problem-solving and model building in embodiment design. Development situations are also considered to enable the agile application of the guideline. These basics for the guideline are described in chapter 2. The developed guideline is presented in chapter 3. For evaluation, it is applied in two development projects dealing with a handheld device for weed control and a vacuum piston pump. The study environment is described in chapter 4 and the results of the conducted case studies in this environment are shown in chapter 5.

2 State of the art

An excerpt of existing approaches for agile product development, problem-solving methods and modelling approaches for EFRs in embodiment design is presented in the following chapter. They lay the basis for the development of the guideline.

2.1 Approaches for agile product development

An agile product development approach is needed as a framework for the developed guideline. The essential requirement for the agile approach to be used is a clear technical orientation since the support of developer teams in the handling of EFRs is the goal of this research. A number of different agile approaches has already been established in various branches and development projects. They are described in the overview and evaluated regarding their technical orientation.

The basics of agile development can be found in the Kanban method. With the goal of just-in-time realization of tasks, it aims at a harmonized flow of task processing [10]. With a Kanban board, tasks can be visualized transparently for a developer team. In addition to the overall view, the individual developer can concentrate on the processing of one task at a time [11].

This idea was taken up by Scrum. Scrum is a project management method established in the software industry [12], which aims to strengthen the values of transparency, inspection and adaptation in the development process [4]. Short cyclical iterations (sprints) are run through to continuously deliver and review functional partial results -so-called increments [13]. When using Scrum, the development team does not use long-term planning. Instead, planning efforts are made continuously and the planning of the next development step is always based on the results of review meetings [7].

Design Thinking can be seen as a collaborative agile process that supports developer teams in the development of creative solutions. The dimensions technological feasibility, economic viability and human desirability are the focus of the development [5]. Design Thinking is particularly suitable in early project phases, where the focus can be placed on the developer and not on compliance with technical constraints [5, 14]. This process is also based on an iterative implementation of product development activities and continuous adjustments [5].

Since the focus of established agile methods lies in the areas of project management or creative problem solving, they are only partially suitable for supporting the technical development of physical systems. On one hand, the integration of tools that support the systematic use of existing technical knowledge and experiences is missing. On the other hand, a multitude of organizational constraints or the integration of necessary release processes at prescribed maturity levels is not taken into account in the development process [14, 15].

Taking the necessity of using technical knowledge in development projects into account, this contribution uses the approach of ASD-Agile Systems Design [16]. ASD-Agile Systems Design is a "holistic, structuring approach for the agile development of mechatronic systems, the associated product strategy, validation systems and production systems, consisting of principles, methods and processes of PGE-Product Generation Engineering" [17]. This approach includes nine basic principles for the agile development of mechatronic systems [16]:

  1. 1.

    The developer is the center of product development.

  2. 2.

    Each product development process is unique and individual.

  3. 3.

    Agile, situation- and demand-oriented combination of structuring and flexible elements.

  4. 4.

    Each process element can be located in the system triple and each activity is based on the fundamental operators analysis and synthesis.

  5. 5.

    All activities in product engineering are to be understood as a problem-solving process.

  6. 6.

    Each product is developed on the basis of references.

  7. 7.

    Product profiles, invention and business model form the necessary components of the innovation process.

  8. 8.

    Early and continuous validation serves the purpose of continuous comparison between the problem and its solution.

  9. 9.

    For a situation- and demand-oriented support in every development project, methods and processes must be scalable, fractal and adaptable.

Further, it contains a model for implementing the appropriate degree of agility at different process levels in line with the situation and demand. In this model, various development methods that are recommended to the developer team according to the respective development situation [16]. ASD-Agile Systems Design is based on the explanatory model of PGE-Product Generation Engineering. Accordingly, products are always developed in generations, whereby the development of each product generation is always based on a reference system. This applies in particular to development projects, in which new products are developed. Even these products are based on technical solutions from reference elements that form a reference system. The reference system includes various reference elements. These can be sub-solutions of the own company of predecessor generations, related series or variants, but also from products of other companies or findings in research. They are integrated into the next product generation through the activities of carryover variation and new development of their subsystems through embodiment and principle variation. A corresponding reference system has to be defined depending on the target or approved new development share [18].

The resulting product and related process knowledge can be used in development projects to assess risks, uncertainties and the respective planning stability for downstream processes on different process levels. Depending on the planning stability of the development process, developer teams can flexibly choose between classic, plan-driven approaches for simple or complicated development situations or an agile, iterative approach for complex development situations.

In Fig. 1, an overview of the ASD-Agile Systems Design is given. At the general project level, a choice between classical stage-gate approaches, a hybrid approach of agile and stage-gate, or an agile approach is made. At the phase-level, development activities can be planned and carried out sequentially or iterative. Sequential tasks are suitable, when the process is plannable, such as specifying requirements from legal guidelines. Iterative tasks are suitable when high uncertainties require a small-step approach, such as specifying individual customer requirements. On the activity level, problem-solving activities are in turn supported by the single or multiple executions of a problem-solving process. An example here is the SPALTEN process. SPALTEN means “to split” in German and is used as an acronym for the activities conducted in this process (see also chapter 2.2). At the method execution level, developer teams can use design methods like TRIZ (a Russian acronym for the theory of inventive problem solving), which in turn can be carried out in sequences or iterations. Thus, ASD-Agile Systems Design enables the implementation of a situation- and demand-oriented degree of agility at different process levels, depending on the respective planning stability. This forces a resource-efficient procedure in development [16].

Fig. 1
figure 1

Systematic for the implementation of a situation- and demand-oriented degree of agility at different process levels depending on planning stability according to [16]

Full size image

A core element in the process of ASD-Agile Systems Design is the product profile that is generated and validated early in the process and is continuously extended and concretized as the project progresses. A product profile can be seen as a model that explicitly specifies the solution space for the design of a product generation [17]. It describes a demand situation on the market, not the solution itself. This approach prevents the developer team from developing solutions early in the process without having understood the real problem situation. In the following phases or sprints, the product profile is continuously converted into technical (sub-) solutions by continuously concretizing the system of objectives (problem) and system of objects (solution) of the product generation. This allows the early generation of prototypes-virtual, physical and mixed physical-virtual-for the continuous validation of developed solutions from the customer, user and provider perspective [16].

2.2 Product development as a problem-solving process

The process of product development can be understood as a problem-solving process based on dörners problem definition [19]. Accordingly, a problem is characterized by an undesired initial state and a barrier that prevents the transformation from initial to the desired final state at the moment [19, 20]. Problem-solving is a process of knowledge generation and the identification of solution approaches [21]. For this process, a multitude of problem-solving methods exist. They can be distinguished in terms of their focus (universal vs. technical) and the degree of detail of their description (low to high) [22]. For example, the REFAFootnote 1 method [23] and the problem-solving process described in VDIFootnote 2 2221 [24] focus on technical problem solving, providing a detailed description of the process flow. They are difficult to apply in agile development. Here developer teams need to switch between technical details and other aspects of the development project that are not supported by these methods. On the other hand, the TOTEFootnote 3 scheme [25] with a low degree of detail, the test solution process of Kepner and Tregoe [26] with a medium degree of detail and the Pahl and Beitz general problem-solving process [27] with a high degree of detail are examples of universally applicable problem-solving processes [22]. A low degree of detail means here a broad application area and reduced effort in learning and applying the method. However, detailed support is only possible with the more sophisticated methods with a high degree of detail. These methods are extensive, but difficult to learn and apply. A solution for this conflict of objectives is a fractal method character, where the degree of detail can be adjusted according to the development situation.

A fractal problem-solving process is the SPALTEN process [16]. SPALTEN can be applied universally with varying degree of detail and enables engaging a large number of different problems with the same method [28]. In addition, SPALTEN supports developer teams in breaking down complex problems into manageable sub-problems, thereby following the goal of agile approaches [6]. The SPALTEN problem-solving process is used in this paper, therefore its essential elements are visualized in Fig. 2 and described in the following.

Fig. 2
figure 2

The SPALTEN problem solving process according to [22]

Full size image

SPALTEN describes the solution of a problem in seven steps, which form the acronym “to split” in the German language and thus are easy to remember for developer teams. The aim of the first step—Situation Analysis—is to obtain a comprehensive understanding of the present context. For this purpose, all information relevant to the respective situation is collected, structured and documented. These form the basis for the further process, which is continued with the activity of Problem Containment. In this step, the aim is to describe and understand the problem presented accurately. In addition, the respective cause and effect relationships that lead to this problem are described. This step is central in the SPALTEN process, as, in case of an error in this activity, the wrong problem is solved in the next steps. This leads to a solution, which does not solve the actually existing problem. If the problem is described sufficiently, the developer team starts the generation of a large number of solutions—usually with the help of creativity techniques—that might be used to solve the problem in the step Alternative Solutions. In order to efficiently fill the solution space, it is desirable to generate a large number of solutions in order to increase the probability of generating a suitable solution. In the subsequent step Selection of Solutions, the generated solutions are evaluated with regard to previously defined criteria. This evaluation leads to the selection of at least one of the solution alternatives. This solution is then evaluated in the step Consequences Analysis with regard to the opportunities and risks associated with its implementation. If the solution does not have to be optimized after this step, it is implemented in the step Decide and Implement, whereby mechanisms of project management can support. The last step of the SPALTEN process—Recapitulate/Learn—serves the purpose of continuous improvement of problem-solving. Here the entire process of problem solving is analyzed retrospectively with regard to optimization potentials and best practices in order to learn for future problem-solving. This step distinguishes SPALTEN from other problem-solving techniques, in which no similar step is found. Another element of the SPALTEN problem-solving process is the continuous questioning and adaptation of the problem-solving team before each activity (Fig. 2, bottom). SPALTEN activities require analytical and creative competences in alternation. Thus, for example, analytical competencies are required for problem definition and creative competencies for the generation of alternative solutions. In addition to these elements, SPALTEN also contains the Continuous Idea Repository (CIR), so that ideas arising during problem definition can be documented and stored. This supports the focus on the essential goal in the respective step. SPALTEN also includes the Information Check (IC). Here it is checked, whether all necessary information is available for carrying out the next step. Its fractal character is shown in Fig. 2 (bottom), at the example of the Decide and Implement step. This step can be modelled as a whole SPALTEN process if necessary [22].

Concluding, SPALTEN can aid agile development through its ability to structure a time-boxed, iterative development approach, regardless of when iterations appear during the problem-solving process. From each step of SPALTEN it is possible to jump back if necessary.

2.3 Model building in embodiment design

Various methods with different focus exist for modelling the product’s embodiment. Their applicability depends on the development situation and its boundary conditions (e.g. whether the products design parameters have been defined or not). The Axiomatic Design [29] considers the process of design and supports modelling of EFRs through a matrix model. The Characteristics-Properties-Modelling (CPM) [30] distinguishes properties as directly controllable variables from characteristics that result from the properties and can only be influenced indirectly. Similar to the Axiomatic Design, CPM focuses on the parameter-based representation of EFRs. Due to the missing visualization, it is difficult to use in early product development or for the analysis of unknown EFRs [31]. The Domain Theory [32] uses visualization possibilities and its Organ Domain Models can be used early in product development. However, it contains no formalized elements, which makes it difficult to transfer results into later phases. The Contact and Channel Approach (C&C2-Approach) uses visualizations of the system on different levels of detail [33, 34]. It also contains formalized elements and is therefore able to support in early and late phases. “It consists of three key elements and three basic hypotheses for their application. The key elements are the Working Surface Pair (WSP), the Channel and Support Structure (CSS) and the Connector (C). A WSP describes the interface, where parts of the system connect while it fulfills its function. The CSS runs through system parts and connects the WSP. A CSS can include parts of components or whole subsystems, according to the modeling purpose” [31]. The C represents a model of the environment of the investigated technical system and transfers effects from outside the boundary into the system [31, 35]. These key elements are used to build C&C2-Models, in which EFRs are modelled using a visualization of the system’s embodiment [31]. In Fig. 3, the C&C2-Approach is presented in an overview.

Fig. 3
figure 3

Overview of the C&C2-Approach according to [31] extended with a model of [34]

Full size image

In the center, two examples of C&C2-Models are shown. These are created from the key elements (left side) under consideration of the basic hypotheses (right side). To build up C&C2-Models, a seven-step method is presented in the chapter on embodiment design in Pahl and Beitz [36]. This method is described in the following:

  1. (a)

    Notate modelling purpose: Each C&C2-Model is created according to its purpose. The purpose describes the objective of the model builder and should be noted in the model to ensure the comprehensibility of its scope and boundary conditions of model validity.

  2. (b)

    Define boundary conditions: Each model represents only a part of reality. In building up C&C2-Models this part is defined in the dimensions of space and time.

  3. (c)

    Visualize the system during function fulfilment: A suitable image of the system in which interactions of its components in the fulfilment of its function can be recognized will be identified.

  4. (d)

    Follow the energy flow: In the analyzed system, the function relevant energy, material and information flows run through the key elements of the C&C2-Approach. This step is conducted mentally and creates the basis for modelling the key elements.

  5. (e)

    Depict key elements in the visualization: The core elements are identified and integrated into the image of the system created in c) under consideration of the basic hypotheses.

  6. (f)

    The design parameters (characteristics and properties) in the key elements are identified by making assumptions about their relevance for the function fulfilment.

  7. (g)

    The EFRs depicted in the C&C2-Model are initially mostly assumed and therefore not verified. A comparison with reality is necessary to check whether the model correctly depicts EFRs. In this step, findings on ERFs are generated from the modelled assumptions by deriving hypotheses.

The model building is completed when the EFRs are understood sufficiently. Based on the created model, synthesis activities become possible. In these activities, the identified EFRs are used to develop an embodiment that is able to fulfil the function [36].

Concluding, the C&C2-Approach can support agile development through modelling of technical knowledge from the first sketch to sophisticated EFRs emerging in late design stages. This technical knowledge is gained through iterative cycles of analysis (supported by model building) and syntheses. Through the sketch-based building of C&C2-Models and their validation using rapid prototyping, a continuous and targeted gain of knowledge is achieved. Thereby, technical challenges and solutions are developed in co-evolution analogous to agile development.

2.4 Development situations

In development projects, a large number of different development situations occur, some of which differ greatly from each other in terms of different aspects. Since the developed methodology is to be applied depending on the situation and demand, an understanding of development situations is essential. A development situation can be described as a time in the development process that requires adapted actions and decisions by developers that are influenced by a variety of factors [37]. Development situations can be very diverse, complex and dynamic [38]. Numerous influencing factors exist for the description of the development situation (see Fig. 4).

Fig. 4
figure 4

Influences on the design process according to Dylla [39]

Full size image

The description of the development situation through the characterization of the influencing factors forms the decision basis for the further procedure in order to prevent iterations, expenditures and additional expenditure in the product development process. The complete description of a development situation is very time-consuming and not always expedient, since not all influencing factors are always relevant [40].

For the situation- and demand-oriented modelling of EFRs, the following influencing factors are derived based on the design process described by Dylla [39]:

  • Time that is available until a certain development result must be realized.

  • Maximum costs that may be incurred in order to realize a certain development result.

  • Maturity level of the embodiment to be examined.

  • Number of employees helping to achieve a specific development result.

  • Experience that employees have in dealing with methods for modelling EFRs.

  • Resources all material and infrastructural resources that are available for the realization of a certain development result.

  • Enterprise organization that affects the duration of decision making, approvals, ordering processes, etc.

The divergence of factor characteristics in different development situations is very high [41], therefore the development of a universal guideline covering each of these situations is nearly impossible. The approach chosen in this paper follows a situation-dependent evaluation of influencing factors and the application of suitable methods and models.

Summarizing, the developed guideline consists of ASD-Agile Systems Design as a process framework for agile development focusing on technical details. For structuring, the problem-solving process SPALTEN is used as it can be applied universally in the process and its fractal character makes it predestined for support of agile development. For modelling EFRs, the C&C2-Approach is used as its visualization possibilities of EFRs supports fractal and lean modelling of EFRs in system analysis.

3 The guideline for functional modelling in agile development

The guideline supports developer teams through a structured and partly prefilled process with situation- and demand-oriented selection of methods for gain of technical knowledge. From the ASD-Agile Systems Design, agile principles, the iterative approach and situation-dependent activities are used to define when and how to use the guideline. The SPALTEN problem-solving process ensures that the model building activities follow the needs of agile development. The C&C2-Approach provides the model for EFRs as well as analysis techniques and design principles to support the gain of technical knowledge. How these approaches are integrated into the guideline is shown in Fig. 5. The ASD-Agile Systems Design is used as an overarching frame for the guideline (symbolized process on top). The SPALTEN process defines the internal structure (vertical blue elements, mid) and the C&C2-Approach provides elements for the detailed activities in the guideline (gray boxes, mid).

Fig. 5
figure 5

Development of the guideline through the integration of the ASD-Agile Systems Design, SPALTEN and C&C2-Approach

Full size image

In addition to the structure derived from these approaches, the guideline is characterized by a change between guiding questions and a stored catalogue of modelling techniques, whereby the method selection takes place systematically. Figure 6 shows an overview of the guideline. Here, the activities in the steps of the SPALTEN process are described. In the following, a detailed description of the core aspects of the guideline is given.

Fig. 6
figure 6

Overview of the developed guideline

Full size image

3.1 Situation analysis

The starting point for the application of the guideline is a question, which makes it necessary to analyze EFRs, like the comparison of different working principles to fulfil certain functions. If a corresponding question arises in a project, the objective of the question is defined and the development situation is characterized by situation-specific influencing factors. For example, the time frame is set to 3 days until the question has to be answered. In addition, the reference elements relevant to the question are identified. For example, a preceding product is present that can be used for the analysis of a working principle. Result of this step is a defined question and boundary conditions for the gain of technical knowledge.

3.2 Problem containment

In this step, an evaluation takes place, whether it is actually necessary to investigate EFRs in detail. It might be that the problem can be resolved without modelling EFRs, e.g. when structuring of requirements is necessary, which can be done without investigating the details of the embodiment. In this case, it is recommended to apply other design methods and exit the guideline.

Problems that require investigation of EFRs are for example unclear causes for system behavior, lack of knowledge about the functionality of a product or influences of parameters on system behavior. When the problem contains these aspects, the guideline is used to support the modelling of EFRs. The degree of complexity of the EFRs is then allocated to the four categories simple, complicated, complex and chaotic according to the Cynefin-framework [42]. If the EFRs are allocated in the category simple, there is no need for support by the guideline, since all EFRs are known and the solution is mostly trivial. This is the case when causal relations between embodiment parameters and function are known, e.g. how the diameter relation of cogwheels influences the transmission ratio of a gearbox. If the degree of complexity is not simple, the guideline supports the situation- and demand-oriented recommendation and implementation of suitable modelling techniques to model EFRs. EFRs are complicated when their causal relations can be identified with corresponding effort, e.g. the contribution of the many different elements in a twin-clutch system to its moment of inertia. For complex EFRs, only statistical correlations can be made, as unknown influencing factors exist that hinder identification of causal relations. In embodiment design, it is aimed at shifting complex EFRs into complicated EFRs. This often requires the development of new analysis methods, e.g. in the behavior of wood in a wood screw connection, where EFRs are not observable and no insights are present in the state of the art. When unknown EFRs become observable, they can be identified with corresponding effort. EFRs are chaotic when neither explanations nor analysis methods exist for them. In mechanical engineering, they are seldom, as expert designers mostly have theories about why and how their system behaves in a certain way. When they occur, a shift towards complex and complicated EFRs is necessary, as unaccountable behavior hinders further development. With the assumption of the degree of complexity, the transition to the next step is made.

3.3 Alternative solutions

This step provides an overview of techniques and analysis methods for modelling the EFRs, which can be used depending on the respective problem and degree of complexity. The suitability of the methods and techniques varies depending on the problem to be solved, whereby this aspect is the focus of the step of Selection of Solution. Techniques describe superordinate procedures that can be carried out independently of concrete analysis. There are four techniques and various analysis methods, whereby both techniques and analysis methods differ greatly in their implementation effort and possible gain of technical knowledge. Arbitrary combinations of the four techniques with analysis methods are possible. The four techniques are taken from Pahl/Beitz [36] and described in short in the following.

  1. 1.

    Zoom-in and Zoom-out: These techniques can support, when the system has to be observed on a more or less detailed level, following initial identified EFRs in search for design parameters that influence them.

  2. 2

    Shift: This technique moves the focus of the system observation following the net of the key elements of the C&C2-Approach. The neighboring subsystems are analyzed in order to draw conclusions about the behavior in the originally considered subsystem.

  3. 3

    C&C2-Sequence modelling: This technique enables investigation of state-dependent EFRs. It consists of several C&C2-Models in different states that are connected to support following EFRs through changes in technical systems.

  4. 4.

    Change of perspective: This technique is suitable for identifying EFRs through a change of the observation direction of the system. It provides support in overcoming observation barriers, in which EFRs are not visible by using the other techniques.

As a plethora of analysis methods exist, recommendations are given for literature describing them, e.g. Thau [43] or Hoels et al. [44]. Examples of analysis methods are also described in chapter 5.1, where sketching and high-speed camera analysis are used. Additional analysis methods may be added if required. This methodological knowledge can be continuously extended in the sense of product generation engineering over different applications of the guideline.

3.4 Selection of solutions and consequence analysis

These steps of the SPALTEN process cannot be taken separately in the guideline, as selection and evaluation have to be conducted iteratively. The techniques and analysis methods from the step Alternative Solutions are considered, evaluated and selected based on the defined problem and identified influencing factors from the Situation Analysis and Problem Containment. This way, a tailored model of the respective situation and the corresponding requirements can be built up. These steps are guided by predefined questions described in the following:

  1. 1.

    Are function-relevant design parameters assumed but not identifiable due to the detail level of observation? select Zoom-in technique.

  2. 2

    Is an interaction suspected? select Shift or Zoom-Out technique.

  3. 3

    Does the system state change? select C&C2-Sequence modelling.

  4. 4.

    Does the system’s behavior remain unclear even when all other techniques are applied? select change perspective technique.

If one or more analysis methods are chosen, a SWOT analysis is carried out for each analysis method selected. This enables the developer team to compare the effort needed for the selected analysis method with the benefit associated with the expected result. The SWOT analysis is based on the influencing factors of the development situation and enables trade-off decisions between necessary effort and resource efficiency. In case no suitable analysis method is identified, the selection matrix of Hölz et al. [44] can be used to derive new analysis methods.

3.5 Decide and implement

With the selected techniques and analysis methods, a C&C2-model is created that provides the necessary knowledge about EFRs in the respective development situation. Here, the steps of modelling according to the chapter on embodiment design in Pahl and Beitz [36], as described in chapter 2.3, are applied. First, the modelling purpose is derived from the Situation Analysis. Then, suitable system boundaries are defined and a visualization of the systems embodiment during function fulfilment is created using the selected methods from the Selection of Solutions and Consequence Analysis. In this visualization, the key elements of the C&C2-Approach are integrated and parameters are defined in the now built-up C&C2-Model.

3.6 Recapitulate/learn

It is checked whether the problem has been solved and which insights about the application of the guideline can be derived for future modelling. If the problem has not been solved and the necessary EFRs were not identified, the guideline can be applied again with adaption to the gained knowledge in the preceding iteration.

4 Study environment AIL-Agile Innovation Lab

To evaluate this theoretical concept of the guideline, a suitable investigation environment is necessary. In this environment, real development conditions, such as a continuously changing development context can be investigated [45]. The development and initial validation of the guideline are carried out in the Live-Lab AIL-Agile Innovation Lab as a development and validation environment. The aim of this Live Lab is to develop products through a team of student developers with methodological support from product development researchers and contextual support from a company. For this reason, the planning stability at the general project level is rather low. The development goal is first concretized in the phases Analyze and Identifying Potential. These phases are followed by four sprints (Conception, Specification, Realization, Release) in which physical prototypes and in-depth identification of customer requirements are in focus. Within the chronologically recurring elements (phases and sprints), activities for the continuous co-evolution [46] of the demand situation (product profile) and its solution (technical implementation) are carried out iteratively. They are supported by methods according to the situation and demand. Results are converted into prototypes at an early stage and continuously validated with the project partner. In this way, development goals can be secured at an early stage and further concretized [16].

The developer team consists of 4–7 students, who convert the development task of a company from industrial practice into functional prototypes with high innovation potential. In the first phase (Analyze) they develop a structured knowledge base and generate the initial reference system. In the second phase (Identifying Potentials) a product profile is derived from market analyses as well as customer and user analyses. This profile is converted into a functional prototype in the following four sprints by continuously concretizing the solution space and identifying suitable reference elements as possible solutions. A delegation of the partner company acts as decision-maker at the milestones and review events. Here, they validate the results from the developer team and provide input for further development. This small-step approach increases the planning stability of downstream development activities [47].

5 Case-study in two development projects

In the following section, the application of the guideline is described in two development projects in the Live-Lab AIL-Agile Innovation Lab. In the first project, an innovative solution for hand-held devices for weed control has to be developed. Here the guideline is used with a focus on designing prototypes for identified working principles. In the second project, optimization potentials for vacuum pumps in the food industry have to be derived. Here the focus of the guideline lies in identifying EFRs in reference elements as a basis for further development.

5.1 Usage of the guideline in the development project of a hand-held device for weed control

The overall task of the first development project is the development of a hand-held device for weed control. In the Analyze Phase of the ASD process, three main methods of weed control are identified: thermic, chemical and mechanical regulation. Thermal processes are frequently used in the commercial sector and require specialist knowledge for their correct application. Chemical weed control, which has been used widespread up to now, is losing acceptance among the population as a result of increased environmental awareness. Mechanical processes exist in many different forms for both the DIY (do it yourself) and the commercial sector. Based on knowledge about existing working principles, a new product is to be developed with increased customer benefits in comparison to previous products.

The guideline is applied first in the Analyze Phase of the development project. The Situation Analysis shows that an understanding of existing competition products is necessary for the further course of the project. The working principles of competing products have to be understood in principle to be able to evaluate and compare their design.

In the Problem Containment, EFRs are relevant to understand the problem, so the degree of complexity is investigated. Many products and their overall working principles have to be investigated, however, a deep understanding of the details of these products is not necessary. The degree of complexity of the question is therefore classified as complicated. This means, that no sophisticated analysis methods need to be applied and the modelling can be done with relatively few resources.

In the Selection of Solution, the Zoom-Out technique from Alternative Solutions is chosen in order to gain an overview of the overall system and possible interactions with the environment. The analysis method sketch/image of the embodiment is chosen as the only method, as the focus lies on gaining an overview and no more sophisticated methods are needed.

In the Consequence Analysis, a SWOT analysis for the analysis method sketch/image of the embodiment shows that the strength of this method is its low resources needed to build up the necessary model. It is optimal for the quick overview that is aimed. Its weakness of limited precision and low information content is not critical in this phase. Therefore, the method is suitable to reach the objective of the application.

In the step Decide and Implement, C&C2-Models based on sketches of the real products are built up that provide an overview of competitor products and their working principles. A selection of these models is shown in Fig. 7. On the left, the thermic principle is shown, where heat is used to remove the weed. Central, the chemical working principle is shown, where a fluid is transmitted from the tool to the weed. On the right, a mechanical working principle is shown, where a string is rotated at high angular speed to cut the weed. In these models, the connectors that model interactions of the modelled system with its environment show similarities in their purpose, but contain different parameters. For example, the Connector C1 contains a model of the user and transmits their influences onto the tool and vice versa. In the thermic and chemical working principle, the mass forces of the tool affect the user and the user influences the position of the tool with one hand. In the mechanical working principle, the tools mass forces are transmitted via a belt (C1c) while the hands of the user (C1a and C1b) influence the position. Vibrations of the tool are also transmitted via C1a and C1b and have to be considered.

Fig. 7
figure 7

Examples of working principles of competitor products based on simple sketches

Full size image

In the last step Recapitulate/Learn two different questions were answered in order to improve the usage of the guideline for future applications and evaluate the quality of the gained result. With the built-up models, it was possible to communicate different working principles of competitive products and decide, how to proceed in the upcoming stages. Here, the visualization of the C&C2-Models was helpful in the development team as well as in interaction with the company. The rapid gain of an overview of technical knowledge could be structured by using the standardized core elements of the C&C2-Approach and the steps of SPALTEN. However, in the early stage of this project, the guideline was quite elaborate to use due to its many steps and activities.

As a result of the Analyze Phase, the mechanical working principle was chosen. The usage of the guideline in building the needed models is shown in Fig. 8. Here the green highlighted elements show which parts of the guideline are used along the SPALTEN process in the Analyze Phase.

Fig. 8
figure 8

Usage of the guideline in the Analyze Phase of the weed control project

Full size image

The first potentials for further development were derived from the overview of the reference system, which includes competitors’ products in the Analyze Phase. The insights gained were transferred into product profiles as technical potentials in the phase Identifying Potentials following the Analysis Phase. The aim of the question was to generate product profiles that describe demand situations on the market. Activities in this phase included the determination of requirements and boundary conditions for the product profiles. Here, customer groups were asked about the identified demand situations and a market research institute was involved. In this phase, no C&C2-Models were developed, as no questions arose on the EFRs and the guideline then advises other methods.

The product profiles were used to derive concepts for mechanical processes to solve the identified demand situations technically. The aim was to identify function-relevant parameters for each individual concept in order to make the concepts comparable. In using the guideline, the Zoom-In technique was recommended as the function-relevant design parameters were unknown. At the beginning of the Conception Phase, the C&C2-Model of a competing mechanical product was refined. Four C&C2-Models are derived and implemented as prototypes for validation of the modelled EFRs. After a SWOT analysis, a sketch and illustrations of competitor products were chosen as methods. Figure 9 shows an example of these models. Here the interaction of plant and brush is analyzed and the influences from the connectors are considered. Here, an evolutionary approach is supported by using the fractal modelling of the C&C2-Approach. The concepts are modelled in overview as well as their technical details, where first optimizations could be identified in the discussion of chosen solutions in the team. These optimizations were implemented directly using rapid prototyping technologies.

Fig. 9
figure 9

C&C2-Model of EFRs of a reference element

Full size image

In the Specification Phase, the project partner selected a working principle to be further specified and for this purpose, the existing prototype concepts were tested more intensively and improved iteratively. The aim then was to quantify the parameters and to identify further function-relevant parameters. It was important to find out the influence of the individual parameters; as these were still unknown at that time, the zoom-in technique was recommended. Since the selected mode of action was dynamic, a C&C2-Sequence model was suitable. Sketches and recordings of the various system conditions using a high-speed camera were suitable as analysis methods, as the project team had a high-speed camera at their disposal at a reasonable price. With the help of the guideline, function-relevant parameters were identified, verified and quantified, using three “wizard of oz” prototypes. Two examples of these prototypes are shown in Fig. 10.

Fig. 10
figure 10

Example prototypes for mechanical brush weed control

Full size image

In the Specification Phase, one of the three prototype concepts presented was selected and various variants of this concept were tested and iteratively improved. Due to the higher degree of design maturity, the analysis methods used were the analysis of wear marks and the methods from the previous phase. Here, many iterations took place, as little was known about the EFRs in the prototype. The modelling using the C&C2-Approach supported here in the documentation of gained knowledge about EFRs in a quick and visual way. This made it easy for the team to follow the cyclic gain of knowledge from the conducted tests.

In the Realization Phase, the final variant of the prototype concept with the optimal parameter settings was selected. The aim of the guideline usage was to build a near-series prototype, including a simple protection device for the prototype test. Here, the focus lay in increasing the robustness of the prototype through the elimination of its weak points. The C&C2-Approach was used in the same way as in the Specification Phase. No new EFRs had to be understood for this, so the guideline advised against modelling using the C&C2-Approach.

5.2 Usage of the guideline in the development project of a vacuum piston pump

The aim of the second development project is to improve an oil-free vacuum piston with focus on pump performance and minimal working pressure. This pump is used for example, in food processing, where contamination by lubricating oil must be ruled out. This project differs from the first project, as there is a much sharper focus on technological detail here. Figure 11 shows an overview and intersection of a competitor’s pump that is an element of the reference system. The pump consists of two cylinders driven by a central engine. In the cylinder head, valves are implemented to remove air from the low-pressure area (suction stroke) and pump it into the environment (compression stroke).

Fig. 11
figure 11

An element of the reference system: oil-free piston pump from a competitor

Full size image

In the Analyze Phase of the development project for the oil-free piston pump, the guideline has been used to support the functional analysis of elements from the reference system. The aim of the Situation Analysis was to understand markets in the vacuum pump sector in order to identify the relevant competitive products. For this purpose, the EFRs of the elements of the reference system had to be understood in general, as well as other functional principles of the competitor products. Here, much more detailed technical knowledge had to be gained. However, this was no problem for the development team as the guideline provided elements for sophisticated analyses using the C&C2-Approach in step A. In the Problem Containment, EFRs have to be understood in the complicated system environment of the oil-free piston pump. In order to understand the functional principle, a sketch was recommended after a short SWOT analysis, as this had the advantages that modelling was possible quickly and easily and was sufficient for the intended purpose (see Fig. 12). The influencing factors showed that it was helpful to buy competitor products in order to investigate them more closely in the course of a benchmarking. Here the C&C2-Approach enabled the reduction of the complicated system environment to a simple CAD-based model of the EFRs used to communicate identified challenges of the design in the team.

Fig. 12
figure 12

Fractal modelling with the C&C2-Approach at the piston sealing

Full size image

In the Identifying Potentials Phase, product profiles for various markets and applications of oil-free piston pumps are created. The product profiles determine an application which cannot be achieved with the current competitor products. In this phase, similar to the first project, no modelling of EFRs took place, as the aim of the question was not directed towards them and so the guideline was not used.

In the subsequent phase of Conception, the aim was to create concepts based on the selected product profile and to build initial functional prototypes on this basis. For this, it was necessary to map relevant system states for function fulfillment. Since the system is dynamic the guideline recommends a C&C2-Sequence Model as a suitable technique. This model is depicted in Fig. 13. Here the changing pressure in the WSP between the piston seal and cylinder wall is shown that is caused by the tilting piston while moving through the top dead center point.

Fig. 13
figure 13

C&C2-Sequence Model of the piston movement

Full size image

In the phases Specification and Realization, the aim was to determine function-relevant parameters from the sequence model and to draw up hypotheses for these, which will be tested with prototypes. Initially, no new models were necessary, since the required information from the existing C&C2-Sequence model could be used to gain insights for prototyping. After the first prototype generation, new models were created based on the prototypes and the newly gained knowledge during testing. Here, many iterations were necessary. The integration of new C&C2-Models into the C&C2-Sequence model enabled documentation and communication of gained insights as a basis for decisions in the incremental improvement of the prototype.

In the release phase, the various market potentials for the selected concept were prepared and the final prototype was built with the findings from the previous phases. Here, similar to the first project, no new EFRs had to be understood, so the guideline advised against modelling using the C&C2-Approach.

6 Discussion

The developed guideline was used and refined in two development projects. It enabled to follow an agile approach during embodiment design, which was difficult up to now. Using the guideline, resources could be used in an efficient way through an evaluation of which modelling depth was necessary to achieve the situation-specific objective.

Based on these two case studies, the research question of how design engineers can be supported in situation-specific modelling of EFRs can be answered as follows:

  • Evolutionary development: Different stages in agile development using ASD-Agile Systems Design require different levels of details for modelling EFRs. The C&C2-Approach enabled the lean modelling of these EFRs on a qualitative base. This enables agile modelling of the necessary EFRs with minimal resources, especially in the phases Analyze and Conception. The development based on the built-up C&C2-Models was supported by the SPALTEN process as a structure of the model building.

  • Iterative gain of technical knowledge: In the early phases of product development, where the two case studies are allocated, the qualitative modelling was sufficient to gain the necessary insights about EFRs. A highly iterative approach was supported in the specification phase by the guideline by suggesting analysis techniques to investigate the system’s behavior of the developed prototypes.

  • Incremental cycles: Communication was often the key to target-oriented development in the stages of the development project. Here, the visualization of the C&C2-Models enabled the fast communication of technical knowledge in the development team and also to staff from the involved companies.

In the phase of identifying potential, no EFRs were necessary. This could also be considered in the guideline and can save resources for the project teams applying it in future projects.

The application of the guideline and the consistent use of technical knowledge showed that it is also possible to follow an agile approach in project phases in which technical design parameters have to be defined in detail. While many established agile approaches do not integrate technical development methods, ASD-Agile Systems Design now enables design engineers to focus on the technical details such as design parameters of systems in agile development. With modelling of EFRs using the C&C2-Approach, developer teams are enabled to plan and conduct their iterations in an objective-oriented manner.

Here, a limitation emerged as up to now only qualitative modelling of EFRs is possible. No further models considering higher levels of detail of EFRs like multibody simulations or regression models from experiments have been applied even though they are mostly essential in embodiment design. This remains as a potential for further research.

Other qualitative modelling methods for EFRs were not tested, so no statement about their suitability could be made. As the visualization was a core element for successful communication, this element can be seen as necessary for a qualitative modelling method that should support the agile development of physical systems. The organ domain model also contains a visualization and might therefore also be useful in modelling EFRs in agile approaches. This bears the potential for further research. Here also the influence of the standardized core elements can be investigated, as the organ domain model does not contain them.

The SPALTEN process has been chosen due to its fractal character. This has proven very useful in the two projects, as problem-solving was necessary on different levels of detail and scope. However, the importance of fractality is still a hypothesis. Therefore it might be possible, that other problem solving processes are also be suitable for the guideline.

Another limitation is the application of the developed guideline in the pre-development phase. Therefore no statements regarding other phases of product development can be made.

7 Conclusion and outlook

In agile approaches, up to now, technical knowledge is only integrated through choosing experienced team members. A systematic approach to gain and explicate this knowledge is missing, making it difficult to develop products needing deep technical knowledge through agile approaches.

To close this gap, a guideline for the integration of modelling EFRs into an agile approach was developed and initially validated in two development projects. It was possible to create a suitable depth of modelling of EFRs as a basis for the subsequent development activities by using the guideline. This enabled technical aspects to be examined in prototype validation early in the development process, thus supporting an iterative approach in the sense of agile development.

Based on the present research work, later development phases such as series development will be examined with regard to the application of the guideline. In addition, the simplicity of the application can be checked by continuous further development of the guideline and, if necessary, increased by adjustments in the procedure description.