Keywords

1 Introduction

The overall goal of agile product development is to enable a radical reduction of lead-times while at the same time exceeding customer and user satisfaction. In order to achieve this goal, procedural and structural elements of the conventional and plan-driven product development approach need to be questioned and adapted. The work stream CRD-C.I of the Internet of Production focuses its research on necessary processes, methods, and structures in terms of market development, data and engineering, production of prototypes, and organization. Thus, the following research questions structure the work stream: How should agile processes and methods be designed to support market development, data and engineering, and production of prototypes? How should agile organizational structures be designed and how can an agile culture be implemented? What are the data structures needed to eliminate semantical conflicts and latencies?

The Internet of Production differentiates between the three areas of market development, engineering, and production of prototypes. Accordingly, underlying procedure models are derived considering multi-perspective and persistent datasets. In this context, the systematic transmission of the advantages of agile software methods on cyber-physical products is addressed. The respective organizational structures in combination with an agile culture enable the realization of advantages. Finally, the processes are enhanced as the transparent exchange of data along the process erases latencies and semantical conflicts.

In the course of the first 3 years of the Cluster of Excellence Internet of Production, answers to the relevant research questions of agile product development were developed within and between the research areas of market development, organization, data and engineering, and production of prototypes of the work stream CRD-C.I. Research results were elaborated in short-term cycles and presented on a cross-research-areas basis. The following sub-chapters present highlights from the results of these research areas. The chapter closes with a conclusion.

2 Market Development

Product development is increasingly characterized by high volatility, uncertainty, complexity, and ambiguity of customer and market requirements – especially at the beginning of the development process. The optimal product concept is impeded by constantly changing customer requirements and technological evolution. In this dynamic environment, a lack of customer integration can be a reason why companies fail to achieve user acceptance. The research area market development addresses this by providing data-based tools and methods that help explore and assess requirements based on usage data or explorative studies and transform them into product innovations. Early stakeholder integration in the agile development process allows requirements to be met more precisely, reducing uncertainty, leap time, and unnecessary product iterations. In order to achieve this, the research area market development investigates the following research questions:

  • What is the process to perform a non-hypothesis-based requirement assessment?

  • Which data, methods, and tools must be located in the process to identify and validate the requirements?

Figure 19.1 shows the sequence of such an agile development process with its stages, incremental outcomes, and iterative steps. The process is exemplary. Hence, stages and outcomes may be adapted according to the actual needs, and each stage may be implemented with its own agile development method.

Fig. 19.1
figure 1

Agile Process from virtual to physical state with iterations and development stages with feedback loops

Full size image

The process starts with the recognition of potential demands. Focusing on the transition from a hypothesis-based to a data-driven requirement assessment, demands should be identified from the available data. The data is stored in a data lake, a collection of databases containing Digital Shadows for the product and the customer. Once a Digital Shadow has been generated, results and procedures can be reused for subsequent tasks. Thereby, Digital Shadows continuously improve with their usage since the underlying models are validated and extended with each additional experiment.

The Digital Shadow of the Product can be seen as more than solely a digital counterpart to a physical object, but also a virtual product with a particular set of properties that may further evolve into a physical product at later stages of development iterations. The Digital Shadow of the Customer, on the other hand, is the digital representation of the customers, whose usage data relates to the usage of a product and whose profile data provides insights about their preferences and behaviors.

After recognizing potential demands, each stage goes through its iterative development sub-process with a respective focus, resulting in an outcome. This outcome can be, for example, a concept, a prototype, or eventually the actual product. Results and insights from each stage flow back as new information into the previous stage as well as the data lake, indicated by the feedback arrows in Fig. 19.1. With that, the generation of feedback to the Digital Shadow of the Customer and the Digital Shadow of the Product at each development step is implemented as a mechanism in the process itself. Thus, creating an overall loop, integrating the Production Cycle and User Cycle into the Development Cycle.

At the early stages of the process, a product or demand may be handled entirely virtually. That means the intended improvement or new product is designed as a virtual prototype, which is meant to be tested and entirely deployed in a virtual environment. Developing in a virtual environment allows for preserving scarce (physical) resources. The strategic decision on what opportunity (i.e., demand) to follow postpones to a later point when more knowledge about the later potential products exists. Hence, reducing the uncertainty and complexity beforehand. With the progression of the process, each development stage enables a more and more physical implementation of the newly developed concept, thus gradually transforming the virtual prototype into a physical prototype.

2.1 Focus Area I – Data Types in Product Development

The main research questions of the research area market development establish a definite goal: the transition from a hypothesis-based to data-driven decision-making in product development in order to enhance decision quality and decrease decision latency. This section focuses on the foundation for this goal – data. Successful products are based on customer needs, actively expressed or latent. It is the task of the company to identify those needs and translate them into technical product requirements (Brettel et al. 2014).

In production, the analysis of process data has a long history due to structured data from sensors and clear targets (e.g., failure or no failure). For product development, however, a variety of data sources is useful, which makes automation of data processing and data analysis harder. This requires a standardized description of the heterogeneous data. This work for the Internet of Production focuses on a bottom-up approach to describe and structure data types and its implications on the digital shadow (Briele et al. 2022, Schuh et al. 2020).

Product development not only uses customer-centered data but also product-centered data, e.g., Social Media data, usage data, sales data and quality data, measurement data. The data types differ not only in their sources but also in their properties. Six main properties show the difference between those data types: subjectivity, degree of structure, degree of specificity, number of data points, update frequency, and cost (initial and running). This standardized structure helps to identify similarities and differences and to select the right data for the application.

One trend is the use of big data. With the use of embedded sensors in everyday objects like fridges, a high amount of data is recorded from a large population. Also, natural language processing enables the automated recording of text-based data like social media data. Both offer unfiltered and unbiased information about the usage of products and latent needs in the best case but require advanced data science methods and bear the inherent risk of unspecific data. Another trend is to join multiple data types to multiply customer insights. For example, joint use of both, customer- and product-centered data, offers an end-to-end description from customer needs to technical requirement that singular data types cannot.

The implications toward the digital shadow are manifold: Firstly, the gathering and storing of the data need to be tailored to each data type, and the access is determined by development cycles in product development. Secondly, the high number of decisions in product development prevents an easy automation of the data analysis. While at the beginning, the most important product features must be identified and ranked, they later must be specified exactly. Thus, every digital shadow is tailored to a specific decision in product development.

2.2 Focus Area II – Integrating the Digital Shadow into the Fuzzy Frontend of Innovation

One of the biggest challenges in product development is the question of which development activities the company should invest in. Since identifying and exploring the most promising development paths are usually highly complex and uncertain, they are also called the fuzzy front end of innovation (Harraf et al. 2015).

In the past, various methods and tools have been developed to generate knowledge and systematize the decision to manage the complexity and reduce the uncertainty. However, due to their contextual and time-related constraints, those methods and tools might not be fully applicable in the context of the IoP. This raises questions about how the Digital Shadow can be applied using existing tools or how these tools can be adapted to make the Digital Shadow applicable. On the other hand, each method and tool are based on underlying assumptions, which raises the question of whether data integration and automation are even desirable goals (Harsch et al. 2020).

Multiple methods and tools have been selected and structured, and each step has been analyzed for its constraints and underlying assumptions. Based on that, a potential level of digitalization has been assessed. Further, some methods have been empirically tested (e.g., Lead User identification using social and usage data) or have been already implemented as a digital tool (e.g., Outcome-Driven Innovation).

Moreover, several constraints influence the choice of appropriate methods and tools, forcing organizations to decide what method or tool to use and adapt them to each purpose. E.g., SMEs often do not have the capacity or prerequisites to acquire or analyze the necessary data, let alone build their own IoP. Such constraints limit the applicability of the theoretical Digital Shadow. Decision support is needed, which considers the respective goal of the endeavor and the available resources of the company. The insights gained from the analysis of the methods and tools are the basis for such a decision support tool.

In addition to the purely functional aspects, other hurdles can hinder the effective integration of the Digital Shadow – for example, the paradox of openness at the strategic level (Laursen and Salter 2014). While the commercialization of innovation requires protection, the creation of innovation often requires openness, or in this context, the release of one’s own data into the data lake. That often leads to the consequence that many companies participate in open platforms but are not willing to share their data. As a result, any data-driven concepts such as digital shadows come to a standstill.

Another example would be the aversion to algorithms on the psychological or human level (Castelo et al. 2019). Data-driven concepts such as the digital shadow include automatic analyzes and artificial intelligence. However, the best artificial intelligence in the world does not bring benefits if there is internal resistance to accepting possible decisions or outcomes.

Therefore, by analyzing innovation methods and tools for the systematic identification and exploration of the most promising development paths, taking possible constraints and hurdles into account, theoretical and practical solutions for effectively integrating the Digital Shadow can be derived and developed.

2.3 Focus Area III – Human Systems Exploration with Tangible XR

The early involvement of users, usability experts, and other relevant stakeholders in the development process can help to reduce the uncertainty of customer requirements at an early stage. However, this can be difficult because the product is not in a usable state. One solution to explore and evaluate possible interaction concepts of a product before it is physically developed is the tangible mixed reality (Tangible XR) (Ays et al. 2018; Flemisch et al. 2020; Meyer et al. 2021).

In the IoP, this is investigated for the multimodal prototyping of a car door opening mechanism. The prototype contains both physical and virtual components. The physical mock-up consists of a frame made of aluminum profiles, which are assembled into a doorframe. This doorframe is connected to a virtual simulation environment via a force feedback device. The user feels the forces of the device as passive resistance when opening the door. The parameters of the device, e.g., forces or damping, can be adapted in real-time. In addition to the real haptic impression, the user perceives the visual impression of the door in a virtual environment (Schuh et al. 2021).

Through this approach, Tangible XR addresses the tension field between virtual and physical development, shown in Fig. 19.1. The goal is to integrate physical components into the virtual prototype at an early stage. By doing this, more detailed feedback, e.g., on haptic product properties, can be obtained at an earlier stage. The possibility to modify parameters of the product prosperities in real-time also allows exploring new interaction concepts with users and other stakeholders. Thus, exploration is a method that cannot only be used for human systems design, but also for non-hypothesis-based requirements assessment (e.g., Flemisch et al. 2021). The data obtained can be used to identify customer requirements and thus reduce uncertainties in the agile development process.

3 Organization

The overall goal of agile product development is to enable a radical reduction of lead-time while at the same time exceeding customer and user satisfaction. To achieve this goal, procedural and structural elements of the conventional and plan-driven product development approach need to be questioned and adapted. In order to drive agile product development comprehensively, several research areas need to be addressed. The research areas of market development, engineering, and production of prototypes address the derivation of the underlying procedure models that need to be defined and maintained to drive agility. However, an overarching perspective with a strategic focus on how to implement agile structures and values within the entire organization is essential to drive an “agile transformation.”

The research area organization focuses its research on agile working structures and teams as well as the implementation of agile culture to provide a holistic and strategic view on how to effectively implement organizational agility. First and foremost, the necessary members within an agile development team must be defined. As an example, the so-called “Voice of the Product” exists in terms of a group of project managers, who hold the overall responsibility. As another example, cross-functional team members participate depending on the sprint target, process type, and targeted viability of the sprint outcome. In conclusion, the combination of hierarchical organization with lateral working structures can be a solution, as it supports direct communication (lateral structure) as well as instant decision-making (hierarchical organization). Next to the agile working structure, culture and acceptance are important for the transformation towards an agile company. Management principles, values, and working environment present three main factors whose adaption becomes necessary to implement agile processes. Basic mechanisms within this context exist within several management theories (e.g., team theory, lean management, flexible organization, system-oriented management). After the mechanism abstraction, their connection to a theory for the transformation towards an agile company is possible. Furthermore, the analysis of behavior patterns gives further insight into an agile culture. In this context, acceptance profiles, which are derived in CRD-D, allow further organization design.

The research field organization has derived several best practices and recommended actions to effectively establish organizational agility. Selective key insights, which could be organized into the focus areas of (1) Culture & Mindset, (2) Organization and Team composition, and (3) Strategy and Leadership, are presented in the following. The overall framework is illustrated in Fig. 19.2.

Fig. 19.2
figure 2

Organizational agility framework: Selective key focus

Full size image

3.1 Focus Area I – Culture and Mindset

Agile cultures require a new understanding of leadership. This new form of leadership is based on the separation of technical and disciplinary leadership and responsibility. Separating technical and disciplinary responsibility allows managers to concentrate on individual strengths and simultaneously focus on actual task requirements. This way, both the development of individual employees and teams as well as the development of the product can be driven most effectively, allowing to increase employee satisfaction while fostering motivation, efficiency, and creativity. Managers that focus on agility understand the need to replace a culture of “command & control” with a focus on personal responsibility, commitment, and feedback. This also allows key decision-makers to regularly exchange ideas with their teams and to inspire, encourage, challenge, and learn from their employees. Agility requires a corporate culture that enables a balanced and equal focus on the development of its products as well as its employees.

Furthermore, agile companies create corporate cultures that allow them to overcome “completeness paranoia” and rigorously facilitate output-oriented work methods. Embedding an agile mindset within the company requires the departure from previous premises and the need to let go of old structures and pieces of wisdom. Especially in the early phases of product development, agile organizational cultures foster approaches of proactive trial and error, the permission to make and learn from mistakes, and an appreciation of “work in progress” that allows for iterative and quick adoption along the way. Development teams should be able to focus on essential features in the early stages of development and present interim results that do not have to be perfectly detailed and complete. Managers that try to implement agile cultures need to focus on building trust and cooperation among team members and need to act as role models when it comes to exchanging that allows for mistakes, failures, and mutual learning. This way, companies can establish a results-oriented working and product development style that allows for quick initialization and adaption, leading to shorter time-to-market and better and quicker fulfillment of changing customer requirements.

3.2 Focus Area II – Organization and Team Composition

To ensure that companies can benefit sustainably from an agile culture and an agile mindset, this must be embedded within the organizational structure of the company. Thus, organizing processes and frameworks can be set up and established in particular. For this, training on agile fundamentals in form of agile concepts, methods, and processes is indispensable. However, these should not only be made available to multipliers who are to disseminate them within the company but should also be made available to as many employees as possible at the operational working level. In addition to relying on a bottom-up strategy, it is important to teach management how to exercise agile leadership. In this way, a top-down approach can also be implemented and the commitment of management to an increased establishment of agility in the company can be manifested at an early stage. Management support is one of the most frequently mentioned success factors for kick-starting the agile transformation to this end. Since the introduction of agile product development involves a great deal of effort, it must not be an end in itself. To be able to fully realize the potential of agile development, holistic implementation is required in all relevant divisions of the company.

In addition to the organizational embedding and the training of the employees, the team composition is particularly important to establish agility in the company. The composition of the team is one of the most important decisions to be made in the course of a project, as a suitable mix of experience, competencies in product development, creativity, and marketing competencies must be found. Therefore, a cross-functional team is required for mastering all challenges within the team and being responsible for the project from the beginning to the end. Especially, cross-functional teams can be enabled organizationally to identify and communicate problems. To ensure the development of solutions to the identified problems within the team in a targeted manner, a dedicated transfer of responsibility to the team and a suitable process for solving problems are required in addition to the successful cross-functional team composition. Both are part of the agile transformation and therefore part of the previously mentioned training. In order to keep the performance of the team on a constant and high level over the project duration, a long-term team composition is to be strived for and the composition is not to be changed, if possible, thus the work mode and the communication culture can be maintained. Since this process may take some time, a dedicated responsibility assigned to the team and its results is necessary to increase the commitment within the team to achieve good results.

3.3 Focus Area III – Strategy and Leadership

To ensure a sustainable and long-term establishment of the agile culture in the company, it must also be embedded in the corporate strategy. Even though the approaches of agile product development and classic plan-driven development are often perceived as incompatible, the integration of agile culture into corporate strategy is not a binary decision. Companies therefore often decide to combine approaches of agile and plan-driven product development and thus benefit from the advantages of both perspectives. In particular, the systematic processes of plan-driven development and the more reactive working method of agile development are to be mentioned here. There are different levels of integration for the combination of agile and plan-driven approaches in product development, from the integration of selected agile methods to the agile working between project parts or at the beginning of a project in the early development phase. The extent to which the agile culture is embedded in the company’s strategy must therefore be decided by the management and is dependent on the company-specific boundary conditions. Regardless of the specific form of the agile transformation, embedding it in the corporate strategy helps to increase visibility and commitment within the company. This is particularly advantageous for a longer transformation process in which numerous challenges have to be mastered at the beginning. Nevertheless, the support of the top management is essential to overcome these situations. As already mentioned in the Sect. 19.3.2, the commitment of the company’s management is important in the implementation of an agile culture.

To foster top management support, it is advisable to promote institutionalization with a board member. To this end, a more intensive commitment of the board to the agile strategy is achieved and experienced. Furthermore, clear reporting and decision-making paths must be established to avoid uncertainties in decision-making within the agile team, which should make everyday decisions as independently as possible so that bureaucratic and hierarchical hurdles can be avoided. To strengthen the idea of leadership in an agile organization, the technical and disciplinary management should be separated, as can be successfully implemented by means of a product owner and agile manager. Regular exchange between the managers and the operational teams is thus becoming increasingly important. Overall, embedding agile thinking in strategy and management can enable the company to allow both managers and employees to concentrate on the essential tasks and prevent micromanagement. This can only be achieved by breaking up previous structures and transferring responsibility for decisions to the agile teams.

4 Data and Engineering

The research area data and engineering addresses the research questions “How should agile processes and methods be designed to support market development, data and engineering and production of prototypes?” and “What are the data structures needed to eliminate semantical conflicts and latencies?”

The ever-increasing demand for variant creation and engineering change requests (ECRs) results in the need for flexible product development and production. This entails agile development and manufacturing of products down to batch size one while simultaneously dealing with the growing complexity of the fabricated systems. An agile process includes the automation of tasks, which in turn means that engineering artifacts must be available in machine-processable form. In this regard, the approach of model-based systems engineering (MBSE) can be applied, where formalized and structured models represent the central development artifacts. A central element in many MBSE approaches is the so-called system model, which describes the overall structure and behavior of the system. It serves as single-source-of-truth in the development process and is often established using the systems modeling language (SysML).

The ability to perform ECRs adaptively while maintaining data consistency and avoiding media disruption is central to an agile yet stable production line. However, MBSE is basically characterized by a strong frontloading. Thus, the challenge is to synchronize agile development and model-based development. Overall, MBSE is a promising opportunity for agile product development and production. It offers various opportunities, such as virtual prototyping or digital twins. The integration of MBSE into agile product development is illustrated in Fig. 19.3 and represents the objective of the research area data and engineering.

Fig. 19.3
figure 3

General framework of the research area data and engineering

Full size image

The target is the synchronization between agile development and MBSE via the systematic construction of system models, including the consistent connection of domain-specific development tools. In the following, three focus areas are explained, focusing on the necessary processes, methods, and infrastructure to introduce an agile development through MBSE.

4.1 Focus Area I – Synchronization of Agile Development Processes and System Engineering Processes

To build a system model at the beginning of the development process, an initial time investment is substantial as the modeling is a complex procedure. Furthermore, there are numerous uncertainties about the relevant requirements and artifacts to be implemented. Therefore, an iterative approach should be applied to transfer agile principles to system modeling. Within the research area data and engineering, an approach for iterative system modeling in agile product development was developed. It focuses on defining the relevant design parameters, which need to be considered in a sprint (Riesener et al. 2019). Furthermore, the methodology developed enables the determination of a specific selection of development tools that are required to answer the questions arising from agile development and considers the previously identified design parameters (Riesener et al. 2021).

In an agile product development process, the development proceeds in defined sprints in which specified increments are realized. The evaluable increments provide the answer for the development questions to be clarified within the development process. They are composed of various product-oriented design parameters such as height, length, weight, and material. Thus, it is necessary to evaluate to what extent the design parameters contribute to the resolution of uncertainties and identify the design parameters that fit together into a validatable increment due to their technical relations. Based on this, sprint-specific prioritizations and selection of technical design parameters can be conducted. These product-oriented design parameters need to be transformed into system-model-oriented design parameters to build up the corresponding system model. The structure of the system model is discussed in detail in the following focus area.

As the system model can only provide information to answer the development questions, it is relevant to integrate development tools, which are able to process the information to support answering the development question of a specific sprint. Different domain-specific tools can be used for this purpose. Within the developed methodology, the focus initially lay on the integration of computer-aided development tools (CAx). A developed tool description framework can be used to formally describe input and output information of the respective development tools, and therefore, it provides the basis for the evaluation of question-specific toolsets. By linking the framework to the design parameters, which provide the respective input information, it is possible to evaluate which development tools are best suited to elaborate the respective inputs (design parameters) and generate corresponding outputs. As a result, an optimized set of development tools for each sprint can be derived in order to answer specific development questions. The first focus area presents an approach for synchronizing agile development processes and system engineering processes, especially to use CAx development tools iteratively in the context of system modeling. In the following focus area, the structure of system models, as well as the opportunity of handling ECRs, are specified.

4.2 Focus Area II – The System Model as an Enabler for Rapid Engineering Change Requests

A successful implementation of MBSE approaches requires a function-oriented and model-based system architecture, the classification of domain expert models, and the linkage of the system architecture and expert models and calculation workflows (see Fig. 19.4) (Jacobs et al. 2022). The system architecture is represented by a SysML system model and consists of requirements, functional architecture, principle solution models, and solution elements (containing principle solution and domain models). The presented methodology allows linking all system elements on a parameter level with each other. Similarly, the domain models (e.g., MBS, FEM) can be linked to the solution elements of the architecture model. This generates a high level of data consistency from requirements over functions to solutions.

Fig. 19.4
figure 4

Overview of the SysML system model architecture and linkage to domain specific models shown for the example of an electric motor (Jacobs et al. 2022)

Full size image

The ability to perform rapid ECRs is a major premise to be able to increase agility in future development processes. MBSE approaches as described above promise to provide an engineering environment in which rapid ECRs can be enabled. A first approach on how a SysML system model can enable rapid ECRs was developed (Meißner et al. 2021). The focus of this approach lies on the linkage of requirements, system parameters, and domain models. First, the system parameters, which are needed to verify the requirement satisfaction, are identified and linked to the respective requirements. Then suitable domain models determining the identified system parameters have to be linked to these system parameters in the SysML system model. This allows an automatic check of whether a requirement is satisfied or not. In case of unmet requirements, the system parameters responsible as well as system parameters relevant to be changed can be identified. For specific test cases that consider multiple system elements and require different models to be executed, model workflows can be implemented within the system model to automatically check these scenarios. Therefore, feedback loops can be drastically shortened.

In focus area II, the general structure of the system model (Jacobs et al. 2022), as well as an approach to use a SysML-based system model for the execution of rapid ECRs (Meißner et al. 2021), was presented. The following focus area elaborates on flexible parameter extraction from such models to enable this linkage.

4.3 Focus Area III – Information Distribution and Change Propagation over Heterogeneous Engineering Artifacts

To harness the benefits of integrated system modeling, the different domain-specific models have to be interconnected. This requires extracting relevant parameters from models and synchronizing these with parameters of other incorporated models. As systems engineering is highly interdisciplinary, this poses a challenge as terminology, and thus, the distinct domain-specific models are highly heterogeneous. Standardization and exchange formats help to bridge this gap but only provide a mere foundation for data distribution. Connecting parameters of relevant models enables tracing information across the heterogeneous tooling landscape (Dalibor et al. 2019a) and validating domain-specific configurations in the context of the overall system under development. To support rapid ECRs while simultaneously ensuring product quality, automation of this process is essential. Whenever a developer makes a contribution to the system, a continuous integration pipeline is triggered to check whether the changes are feasible with respect to the existing artifacts.

The general notion of automation and continuous integration, thus, perfectly matches the problem of agile MBSE by integrating engineering models of various domains. Here, these concepts are applied to the broader field of systems engineering, resulting in a huge challenge of connecting models and distributing information in a semantically sound way. Furthermore, in contrast to software engineering, the engineering models in MBSE generally do not appear as plain text artifacts but are often encoded in a carrier language (such as XML), making it harder (for humans and machines) to detect the impacts of a change. In the worst case, the engineering model is only available as a binary file, requiring an application programming interface (API) for proper access to parameters.

Thus, information distribution and change propagation require the underlying continuous integration platform to handle the different artifact types, being able to extract parameters independent of the encoding. As new models and model types can constantly be incorporated during development, when synchronizing agile development processes and MBSE, an underlying framework that handles parameter extraction must be equally extensible. In a respective approach, models must be parsed (in the case of textual formats) or (for binary artifacts) accessed via an API. For each model type, an associated module can be defined in the framework that can read and reintegrate parameters from the models, enabling standardized information interchange. These modules serve as a communication interface between the domain-specific syntax of the models and the general exchange of data (Dalibor et al. 2019b). To enable this information distribution, the control flow of included tools and the data flow between the models must be specified. In software engineering, this is handled by building scripts, such as Makefiles or Gradle. While additional, specially tailored solutions for systems engineering exist, which provide more accessible user interfaces (especially for non-programmers), the basic concept remains the same. However, these frameworks need to be able to run in batch mode, operating without manual input, to ensure automation in the overall data exchange and validation process. Combining these approaches of a continuous integration platform for MBSE with seamless integration of interdisciplinary engineering models enables continuous data transfer and facilitates agile development.

5 Production of Prototypes

The rapid change of product requirements (Engineering Change Request ECR) in the agile development process poses new challenges for technology planning in the design of manufacturing systems for series production. In particular, the interface between engineering and technology planning is significant due to the need for rapid and efficient analysis of technological and economic effects of ECRs on manufacturing. In addition to ECRs, the increased dynamics and agility of the product development process result in new challenges for the design and dimensioning of manufacturing systems. However, there are also numerous opportunities to meet the existing challenges as well as the increasing cost and time pressure through the production of prototypes for information acquisition and validation of planning. To exploit the potential of increased agility as well as the generated knowledge, it is necessary to understand the cause-effect relationships at the interfaces of engineering, technology planning, and the design of individual processes. Prototypes are a particularly valuable source of information in this context, as they are exposed to the actual environmental influences of physical production and thus provide valuable information for process design in addition to validating simulation and planning results. The research area production of prototypes aims to use the information generated by prototype tests to develop models and methods for optimizing and increasing the efficiency of product development processes and to analyze the cause-effect relationships at the interfaces of engineering, technology planning, and process design. For this purpose, four focus areas were defined, which attack the different interfaces to analyze and model the interactions. In the following, the focus areas and the current research results are described.

5.1 Focus Area I – Engineering Change Requests in the Product Development Process

Engineering Change Requests (ECR) in the product development process repeatedly present manufacturing companies with economic and technological challenges, as they lead to time-consuming and cost-intensive change measures, especially in the late phases of the development process. To meet this challenge, a software prototype was developed that analyzes the impact of design changes in terms of technological feasibility and forecasts the economic impact based on a volumetric cost calculation. This enables the engineering department to get direct feedback on design changes, thus achieving significant time and cost advantages in the development process and increasing the competitiveness of companies. Furthermore, the tool offers the possibility to derive corresponding prototype tests by comparing the technological feasibility and the deviating product requirement profile to generate missing information.

5.2 Focus Area II – Agile Ramp-Up Production

Due to the shortened product life cycles and the increased time and cost pressure of efficient production, the pressure on manufacturing companies to carry out more ramp-up productions in ever shorter periods of time has increased (Rey et al. 2019). Currently, however, the time and cost targets for ramp-up productions are not achieved, which results in competitive disadvantages for manufacturing companies. The failure to achieve these targets is due, for example, to production-related engineering and manufacturing changes (E/MCRs), which lead to time-consuming and cost-intensive changes during the ramp-up production (Kukulies and Schmitt 2018). The idea of current research work is to transfer the methodology of agile product development to the ramp-up production and to integrate it into product development in accordance with the hypothesis that E/MCRs in the ramp-up production correspond to the same problems as the changing customer requirements in the product development process. This is referred to in the following as agile ramp-up production (Bergs et al. 2021). The aim is to use the increased agility and the knowledge generated from the prototype tests to identify E/MCRs at an early stage and to stabilize the ramp-up production in a targeted manner. Due to the uncertainty that thus prevails during the ramp-up production, it is necessary to know exactly where which uncertainties exist and what effects they have. Various models and methods have been developed for this purpose as part of the research work in the Cluster of Excellence IoP. Based on the modeling of uncertainties, a prognosis model was developed, which enables the prognosis, evaluation, and prioritization of E/MCRs based on the modeled uncertainties. Expanding on the results, another model was developed that enables the optimal derivation of prototypes to be manufactured for early reduction and validation of E/MCRs. Based on these models, a methodology was then developed that supports companies in technology-specific decision-making, considering product and process maturity as well as the probability of use of manufacturing technologies in the series manufacturing system in agile ramp-up production.

Furthermore, research was also conducted into how the manufacturing process sequences to be designed in the agile ramp-up production can be optimized economically (late ramp-up phase). The aim here is to design the manufacturing processes (definition of process parameters) according to the available information basis so that a cross-process, economical optimum is achieved and at the same time the required component characteristics for the final component (quality) are met. For this purpose, however, both economic and technological interdependencies between the different manufacturing processes have to be modeled. The concept developed for this purpose provides for the individual processes to be represented by meta-models, which approximate known system states, and are linked to corresponding transfer variables (intermediate component state characteristics). The advantage of meta-modeling is that these models can be quickly extended and detailed by further data from the ramp-up production (e.g., from prototypes or analogy tests). The linked meta-models make it possible to evaluate the effects of individual process parameters on final component characteristics and to predict component characteristics for different designs of the process sequence. Parallel to this, an economical evaluation of the manufacturing process sequence is carried out, in which the costs of the individual processes are determined as a function of the respective process design and transferred to a higher-level evaluation model. These two variables (predicted component characteristics and economical result) then form the input variables for a metaheuristic optimization approach (selection due to non-linear correlations and binary variables) to identify the most suitable process parameter combination. This result is then evaluated according to the information basis so that the meta-models are increasingly validated and improved by prototype tests within the agile ramp-up production.

5.3 Focus Area III – First Part Quick, Right, and Productive

The importance of detailed process simulations as a basis for quick and correct process design of manufacturing processes is undisputed. Extending existing simulation approaches through increasing networking and data availability can overcome the barrier to flexible, cost-efficient prediction of manufacturing processes caused by data-driven models with higher accuracy. For a quick and correct design of milling processes, knowledge about expected process forces is of great importance. The calibration of existing simulation approaches is time-consuming and transferable only to a limited extent due to the complexity of manufacturing situations (Altintaş et al. 2014; Grossi et al. 2015). The Internet of Production creates the possibility of a worldwide laboratory approach through cross-domain, continuous data availability down to the machine level: Every production situation is recorded and documented by measurements. On this basis, the target is to quickly adapt known physical relationships to the current situation as well as to extract and quantify previously unknown relationships as new knowledge from the data. This hybrid combination enables manufacturing simulations to be used broadly and validly in the long term, so that processes can be designed quickly, correctly, and productively up to prototype production.

Three elementary steps are derived to achieve the target: In the first step, all cross-domain data along the product creation chain (CAD, CAM, manufacturing, and quality data) are automatically contextualized based on a digital shadow of the manufacturing object (Brecher et al. 2021). The basis is a material removal model in the area of manufacturing simulation, which, based on the designed or driven NC path, compares the material to be removed with the data measured at this time contextualized (live data: positions, torque-forming currents of the spindle and axis, spindle speed, process forces from a spindle-integrated force sensor; meta information: tool, NC block, workpiece and tool geometry, manufacturing feature, required quality features from the design). As a result, the data plane is transferred from the time domain to a location domain, which forms the basis for the digital shadow.

In the second step, the digital shadow is combined with known physical cause-effect relationships. Thereby it is possible to define each manufacturing situation as a so-called behavior cluster based on the cross-domain data. A behavior cluster forms a delimited multivariable data domain. Within this behavior cluster, manufacturing conditions are similarly based on the contextualized multivariable data. Physical effect relationships such as the parameterization of known, empirical force models as the Kienzle model, shown in Brecher et al. (2021), can be quickly parameterized due to the contextualized availability of the data within the current behavior cluster. In Brecher et al. (2022), the authors show the results of a cluster-based calibration process of empirical force models. If this behavior pattern is recognized via the available data exchange from planning to production within the manufacturing design, the stored parameterized empirical process force model can be used to estimate valid forces. Over time, as more manufacturing situations become available based on the data, a cluster space will be achieved that can predict potential impacts from ECR on the overall manufacturing process based on valid relationships.

In the third and final step, the target is to extract the knowledge implicit in the data with respect to manufacturing behavior using AI-based methods, to quantify it. The key advantage of the global laboratory approach through networking and the associated continuous data availability captures complex situations representing behavior that is not represented by conventional physical contexts. Based on the new insights extracted by data-based approaches, the previous process simulation can be further improved. For this purpose, the previous cluster-based modeling of physical contexts will be extended to a holistic hybrid model structure. As soon as the prediction of the process forces deviates via the cluster-based approach in the second step, this deviation is intercepted via an artificial neural network (ANN), which searches for correlations from the deviations in the data as a basis for quantifying unknown correlations. The authors show in Brecher et al. (2021) the impact of unknown correlations on process force during tool breakage. The deviations in prediction and measured force have been continuously processed by the network structure. This processing shows the potential of the ANN structure to represent other influences, such as here the vibration influence of the machine structure and its influence on the process force, in addition to the valid models in the cluster. As a result, such a network structure provides the basis to determine quantitative relationships in the long term. Current and future work uses AI-based algorithms such as LIME to quantify these new findings and make them available to process simulation.

6 Conclusion

In the first 3 years of the Cluster of Excellence Internet of Production, answers to relevant research questions of agile product development were developed in the research areas of the work stream CRD-C.I. Focus areas of these research areas and central results were presented in this chapter.

The research area of market development dealt with several questions on an abstract theoretical level as well as on a practical level. By making adequate use of the digital shadow within product development and by enabling design and deployment in a virtual environment, different ideas and concepts can be tested quickly. The research area intends to create at least a semi-automated, continuous, and iterative process of requirements elicitation while conserving resources. The research area of organization identified agile values in corporate culture, employees, organization, structures as well as strategy and leadership as the basis for success in dynamic and uncertain environments. Disruptive market changes, technological changes, and environmental shocks require companies to constantly rethink, react, and reinvent. The research area of data and engineering showed that systems engineering is a promising enabler for agile product development. Within the research area, a function-oriented and model-based system architecture as well as an approach to select relevant design parameters and development tools are presented. Furthermore, the integration of models in a fully automated continuous integration platform is described. The research area of production of prototypes provided a methodological and technical overview of the procedure for exploiting the potential of data-driven approaches to increase flexibility in prototype production due to agile product development. Due to the availability and exchange of data from product development to technology planning, detailed production planning, and manufacturing, new relationships can be extracted that have the potential to boost an agile and fast technology and process ramp-up in terms of expected effects, quality, productivity, and costs. Further research results will be the content of future publications of the Cluster of Excellence Internet of Production.