Holistic IDE Procedure Model

Abstract

A solution usually emerges in an iterative process between development and evaluation. The development itself is as well an iterative process that takes place between an idea, a suitable concept and the solution derived from the concept. Each solution must be evaluated, whereby each evaluation leads to an improved development, which in turn goes through the cycle of ideas, concept and development, is re-evaluated and so on.

A solution usually emerges in an iterative process between development and evaluation. The development itself is as well an iterative process that takes place between an idea, a suitable concept and the solution derived from the concept. Each solution must be evaluated, whereby each evaluation leads to an improved development, which in turn goes through the cycle of ideas, concept and development, is re-evaluated and so on. This process can be described with the TOTE scheme (Sect. 1.2.3.2). As shown in Sect. 2.2.2 and Fig. 2.4, it is triggered by various forms of customer demand, the general market situation and market opportunities, whereby different conditions, requirements, constraints and standards in different areas have to be considered. The entire iteration loop has the course of an “8”, in which the generation between an idea, the resulting concept and the actual solution development and solution evaluation take place¹. The individual product attributes are successively developed, their fulfilment determined by the attributes Safety, Reliability and Quality safety, Reliability and Quality, and their economic performance measured by the attributes Added Value and Profitability  Added Value and Profitability, Fig. 16.1.

Fig. 16.1

Iterative preparation and evaluation of a solution (using Fig. 2.4)

As shown in Sect. 1.2.3.2, the TOTE scheme is a self-similar process that can be applied to different tasks and thus can serve as a guideline for a high variety of activities. Such a guideline is then called a procedure model when it proposes, (but not necessarily prescribes) a meaningful sequence of organizational, methodical and technically meaningful activities and processes (with the use of the associated methods, procedures and tools) for the development of products.

A procedure model covers all activities involved in processing processes and objects as well as related activities, such as to manage a project. The procedure model defines all relevant activities and (expected) results as well as their logical interdependencies with each other and with the external framework conditions. The procedure model provides a formal framework for processing tasks, for example, to plan the development of a product. It can map the current dynamic state of a process, e.g. that of product development, and realize further steps by applying Dynamic Navigation (Sect. 15.7). The procedure model can also assume the function of a checklist for the timely completion of activities, clarify the expenditure for a task to be solved or already been solved and reflect the results of a completed project [Frei-2001] [PoLi-2011].

16.1 Basics and Structure of the IDE Procedure Model

The loop depicted in Fig. 16.1 can be identified at every level of abstraction and concretization of product development, as has been shown by corresponding research on the Autogenetic Design Theory ([VaKB-2011] and Chap. 1.1.5). It thus forms a self-similar activity pattern within IDE and therefore serves as the basis for the holistic procedure model of Integrated Design Engineering. However, the model shown in Fig. 16.1 is neither comprehensive, nor detailed and diverse enough to

• cover all requirements for structuring, modelling, navigation and completeness of the development within IDE. These requirements result essentially from the interdependent attributes and their fulfilment levels, the necessity for parallel processing of tasks, the numerous integrations within IDE (Fig. 3.2 and Chap. 14) and the restrictions and limitations in project work (Sect. 15.2.3).

• ensure that the procedure model can be applied not only to the creation of arbitrary objects (Sect. 2.1), but also to the creation of their preliminary stages (ideas, concepts, designs, approaches, trials and errors, etc.).

• consider all problems arising from the dynamization of requirements (in the broadest sense) and changes both in the development and application environments (Sect. 15.7).

• enable that the knowledge required for IDE can be made available in a context-sensitive way.

The holistic IDE procedure model picks up the basic idea of the self-similar activity pattern, which can be used at any concretization level of product development, on a large scale as well as in detail, and for any product and application domains as well as application disciplines, Fig. 16.2.

Fig. 16.2

Holistic procedure model of  Integrated Design Engineering

The procedure model with its eleven activities arranged in five groups can be used for all objects that can be handled within IDE, i.e. any ideas, concepts and problem solutions from any disciplines and for any markets, in all possible combinations, development stages and implementation states. The procedure model does not specify a specific processing sequence (completely in accord with Dynamic Navigation, Sect. 15.7), since a subsequent processing step can only result from the results of the current step and the conditions prevailing at this point in time from requirements and the internal and external environment (for restriction options during processing, see Sect. 16.3).

The IDE procedure model consists (from left to right) of the activity groups Research; Develop | Design | Integrate; Evaluate | Compare | Select; Model | Configure | Synthesize; and Complete, all of which are accompanied by ongoing documentation of (intermediate) results. Conception, selection and configuration of these activities and their respective groupings are based on the work of Freisleben [Frei-2001], on the results of industrial development projects in the IDE Master’s study course IDE at the Otto von Guericke University Magdeburg² [IDEP-2019] and on the work of Neutschel [Neut-2017].

• Research with its various measures enables the procurement of required information and knowledge for the other activities in the procedure model in the required quantity and quality at the respective points in time. It can be carried out as a rough or a fine search.

• Develop encompasses a wide range and variety of the emergence of an object, but predominantly in small or rudimentary stages of concretization. Design serves to successively work out the geometric-material totality of the object in the sense of solving the aesthetic design problem according to the product requirements formulated via the attributes in the respective environment (design thinking). Integration complements, completes and merges, where appropriate, the solutions that have been developed so far (including fragmentary solutions), so that the essential characteristics and features of the later product can be identified.

• For the evaluation of the current work status as well as for both comparison and selection of alternative objects according to arbitrary criteria, various procedures are used for the evaluation, calculation, simulation, animation and testing of objects as well as the determination of economic aspects, all at arbitrary times.

• Both for the easier evaluation of the object and its preliminary stages, as well as for development and interpretation, it is helpful to work with a growing numerical representation (model) of the object, in which the essential characteristics of this object, its components, its behaviour and its interaction, which all contribute to the object performance, can be modelled in the respective current development stage. The modelling also includes the representation of the object in different forms of illustration. Such a representation can be a more or less complete product model (a so-called digital twin³). According to the stage of development, it can be a digital prototype (digital mock-up), a technical drawing and a more pictorial representation, which aims, for example, at the shape, impression and surface quality of an object. Configure basically contains the same activities as Develop, but prefers to use these for the concretization and dimensioning of (emerging) objects. It does not matter whether it is a new or an adaptation development of an object or a variant design. With synthesizing, the emergence of a superior solution (synthesis) in the sense of Hegel’s philosophy is promoted from previously competing and/or contradictory solutions (thesis and antithesis). At the same time, a meaningful reduction of the variety of solutions without loss of solution quality is achieved.

• Complete ensures that all necessary activities are done in order to complete the current development step.

• Continuous documentation of each activity takes place until the product documentation is complete.

The abbreviations BAD, PAD and MAD (adapted after [Otto-2013], see also Sect. 1.4) as well as EAD, RJE, VQC and CAx summarize suitable support and linking measures for the activities in the IDE procedure model at the points of contact of the circles in Fig. 16.2.

• Within IDE, brain-aided design (BAD) comprises such procedures and methods that take place on abstract levels and serve to round off possible solutions at an early stage, for example, the most varied thinking and creativity techniques as well as their appropriate application. BAD promotes thinking on abstract levels in order to be able to better grasp the contexts in a task. Thus, it serves the collection of requirements, the compilation of the required knowledge, the definition of the required support and last but not least the preparation and execution of the development work.

• Pencil-aided design (PAD) comprises the fast creation, visualization and fixing of solution variants with their essential characteristics as sketches on paper (also called the “language of the product developer”, see also Sect. 6.2), without having to carry out a complex modelling at an early time. This allows an initial check to be carried out on the fulfilment of specifications and the feasibility of a solution. In addition, a continuously growing repository with solution ideas is created, with which a fast identification of the currently best possible solution can be achieved with little effort.

• Model-aided design (MAD) is preferably used for “thinking with the hand,” as a first impression of form, impression and dimensions of the resulting product can be gained from a physical model of any complexity. This allows not only the haptics of the object to be tested and optimized, but also its shape. At an advanced stage of development, MAD also includes virtual models in suitable CAx systems and virtual reality systems as well as the rapid creation of prototypes with classical materials (light metals, plastics, wood) and by additive manufacturing (e.g. with photopolymers or sintered materials; Sect. 9.2).

• Evaluation-aided design (EAD) summarizes all measures for verification and evaluation of (interim) results.

• RJE (Rate, judge, estimate) is used to classify search results in terms of usefulness, plausibility, consistency and coherence.

• VCQ (Verify, quantify, check) is applied to check and evaluate the results and solutions that have been achieved so far before the documentation is completed.

• Computer-aided everything (CAx) is the generic term for any type of computer-aided system support for the most realistic modelling and simulation of product alternatives possible (see also Chap. 18).

The holistic nature of the procedure model results first of all from the IDE attributes, which originate from all phases of the product life (except product development) and thus enable the holistic consideration of all influencing variables. In addition, the currently reached fulfilment levels of each attribute control the flow through the procedure model. In conjunction with the Dynamic Navigation procedures (Sect. 15.7), it is ensured that none of the activities required for a project can be omitted.

Equal goals are the achievement of the specified or required product quality during the processing of all activities and the fulfilment of customer demands. Therefore, the IDE procedure model uses diverse knowledge, methods, tools, procedures, information and solution archives, etc. to work with the activity groups. The procedure model is subject to the influences of the environment, consisting of the application environment in which the product is used, boundary, initial and mandatory conditions as well as constraints, laws and society, etc. The adaptation to a concrete problem is carried out exclusively by the information used and the knowledge applied. All activities also make use of the existing explicit and implicit knowledge of employees and the company, consisting of knowledge and experience, methodologies, best practices, information, solution archives, etc. (see also Chap. 17).

Three structures can be identified in the holistic IDE procedure model, Fig. 16.3:

Fig. 16.3

Structures in the holistic IDE procedure model

• Based on the customer demand and the possibilities in the market as well as the consideration of possible limitations, the Research activity, the activity group Develop | Design | Integrate as well as the activity group Evaluate | Compare | Select provide the continuous development of the application scenario of the resulting product take place.

• In the activity group Develop | Design | Integrate, the activity group Modelling | Configure | Synthesize as well as in the activity group Evaluate | Compare | Select the essential activities of IDE take place within the genesis of the product and its preliminary stages. The genesis can also be supported very effectively with the methods of the Autogenetic Design Theory (Sect. 1.7). For this purpose, the specifications for the fulfilment levels of the individual attributes are integrated to form a common target function. The genesis then proceeds analogously to the procedures described in Sect. 1.7.1 and shown in Fig. 1.32.

• In the activity group Modelling | Configure | Synthesize, in the activity group Evaluate | Compare | Select and in the activity Complete, the essential steps for consolidating all possible quality aspects (e.g. usage, production and re-utilization quality) are carried out before the product is released for production.

The three structures are sufficiently interlinked to ensure that they cooperate and do not compete against each other and that a product can be developed that meets the requirements and is continuously adapted to new influences.

In the IDE procedure model, each activity is basically connected to all others (forming a mesh). However, a connection is only activated when required and becomes inactive again after the end of the respective requirement. The procedure model does not contain a time axis, because when processing in a dynamic environment, there is neither a previously definable time sequence nor a preferred direction for the activities. Only when editing a concrete project does a sequence emerge step by step from the current editing and its progress in comparison to the current fulfilment levels of the attributes. Further effects result from current knowledge, internal and external influences and the resulting work progress. The concrete chronological order in a project can therefore only be determined afterwards.

• Internal influences arise from problems with project resources or missing or incomplete input from the extended or external teams (Sect. 15.6.3).

• External influences essentially include changes in customer requirements and expectations as well as changes in the environment of the IDE, in particular from the application scenario and environment, as well as the boundary, initial and mandatory conditions.

As mentioned above, the TOTE scheme is the basic structure for describing possible patterns of individual activities. In the procedure model, the activity group Evaluation | Compare | Select corresponds to the TOTE function “Test”, while the other activity groups implement the TOTE function “Operate”, Fig. 16.4.

Fig. 16.4

TOTE scheme as basic pattern for the holistic IDE procedure model (grey areas: Realization of the function “Test”, white areas: Function “Operate”; after [Neut-2017])

16.2 Application of the IDE Procedure Model

Due to its self-similarity, the IDE procedure model can be used for modelling purposes at the top level of the product development process as well as at any level of detail below. It also supports the development of any objects from any disciplines (Chap. 2), mechanically oriented products as well as those with an emphasis on electronics or software (Mechatronics: Chap. 23). The activities contained in the procedure model always remain the same. Therefore, the procedure model can be used just as well to develop a concept as, for example, to develop detailed solutions for a specific product.

In the sense of Dynamic Navigation (Sect. 15.7), each of the activities listed in Fig. 16.2 can be regarded as a process element with a corresponding set of methods and tools, suitable procedural patterns (e.g. from [EhMe-2017] or [HaGo-2004]) and structuring rules for the structure of the network of activities. During the modelling of the process by configuring and combining process elements, these are adapted to the current conditions. Depending on the situation of a company, sub-processes from several process elements can also be applied instead of individual process elements, for example, in the activity Compare, since these are usually reproducible activities. Figure 16.5 shows further possible decompositions of the process elements at the top level of the IDE procedure model, as they can be used in an IDE project to form the activity pattern⁴.

Fig. 16.5

Selection of the stored methods, procedures and procedures for each activity group in the holistic—IDE procedure model (Selection)

Although the IDE procedure model does not fix a specific processing sequence, one can define a neutral basic pattern for the activities with which, for example, an (as yet) inexperienced product developer can work with the procedure model. In addition to the processing of all activity groups and the seven support and connection measures, the essential elements of this basic pattern are the on-going comparisons of the results of each processing step and its progress compared to the respective required fulfilment levels in the respective specifications, Fig. 16.6. Processing starts with the step “Comparison of specifications of ⇔ current fulfilment status” (top left in Fig. 16.6). It ends when all specifications and their fulfilment levels have been reached and the product thus exhibits the required performance capability with the corresponding performance behaviour.

Fig. 16.6

Basic pattern for processing all activity groups within the IDE procedure model (dashed line: Positive result of a query “Y”. Solid line: Negative result of a query “N”)

If the actual sequence of activities is to be recorded in a concrete IDE project (e.g. because of product liability), this can be done using the documentation options of Dynamic Navigation (Sect. 15.7). During the processing of the project, the network of activities forms and changes successively. Using the project example presented in Fig. 15.27, the resulting network is shown in Fig. 16.7. The small white circles represent individual activities or groups of activities, which are connected with each other according to the respective context.

Fig. 16.7

Network of activities in the concrete project processing within IDE procedure model

The network in Fig. 16.7 shows (as expected) an accumulation of activities in the three activity groups of the product genesis (Fig. 16.3), but also the fact that the customer changed the requirements twice (circles below the arrows above). The circles in the “on-going documentation” field only show the consolidations of the product documentation carried out for certain events, for example when a certain development status (or milestone) has been reached.

Because during the processing of all activities both the respective start and end dates as well as the results of each activity are documented with regard to the achieved fulfilment levels of the attributes, the activity network from Fig. 16.7 can be related to the time axis. Each activity group of the procedure model becomes a strand running in parallel to the other strands. All strands are framed, on the one hand by activities to secure and update the current projects, on the other hand by the creation and updating of the documentation. Figure 16.8 shows this transition for the project from Fig. 15.27 and the resulting network of activities.

Fig. 16.8

Network of activities of the concrete project along the time axis

The small white circles in Fig. 16.8 show (as in Fig. 16.7) individual activities from a certain activity group in a certain chronological order, beginning with the project launch and depending on the task as well as on changes in the requirements (there were two changes in this project). Usually the last activity before the transfer of the project result is the documentation of the last achieved results.

Indeed, Fig. 16.8 shows the individual interconnected activity groups, but not how these activities were distributed over the genesis of the six product attributes. The attributes must be developed with a view to predefined degrees of fulfilment and economic specifications. Since they influence each other, a processing order cannot be specified here either. If one now, in analogy to the documentation of the activities, wants to represent the sequence of the genesis of the six product attributes in retrospect, then the logged results of the respective activity and their respective time window of the treatment (see above) can be used for this. Figure 16.9 shows this process for the project from Fig. 15.27 in a spider diagram which was rotated by 30° compared to Fig. 3.11 for better representation. As pointed out in Fig. 3.11, the individual fulfilment heights increase from the inside out. Consequently, the processing starts in the middle of the spider diagram, where at the beginning of the processing there are no fulfilments. The genesis of the product attributes forms a comparable network to that of the activities in Fig. 16.7. They end as soon as the specifications of each attribute have been reached, with the preparation for market launch. Accordingly, this node is associated with the highest fulfilment of each attribute.

Fig. 16.9

Networked activities in the genesis of product attributes

As with the network of activities in Fig. 16.7, the activities in Fig. 16.9 can be projected onto the time axis. Figure 16.10 shows for the same project the network of activities for the genesis of product attributes over time.

Fig. 16.10

Genesis of product attributes over the time axis

Provided no changes occur during product development, it can also be assumed that the fulfilment levels of an attribute increase from left to right. If, however, changes occur that are reflected in a change in the requirements, then it is quite possible that the fulfilment level of an attribute is “thrown back” and must be redeveloped and concretized again.

During processing, both the documentation of the respective start and end dates (Fig. 16.8) as well as the documentation of the results of the respective activity with regard to the resulting fulfilment levels for each attribute (Fig. 16.10) are carried out for all activities. Thus, with the help of the activities, the current processing status of the product development can be determined at any time. Should deviations from the project specifications occur, these can be corrected and compensated using the Dynamic Navigation procedures (Sect. 15.7).

16.3 Adaptability of the IDE Procedure Model

As already mentioned, the actual processing sequence in the IDE procedure model can only be determined after completion of a project. If, however, a company develops, a number of similar products, the quintessence of the stored networks of activities can be derived as so-called pattern networks (i.e. best practices), which can be used as possible initial configurations for similar development tasks. In order to represent such a sample network in the form of a bar chart for a project, the time windows⁵ intended for editing are used. The determination of a time window is based on a network of activities selected as a pattern. The duration of a time window is basically determined by the time interval between the first and the last activity from the same activity group. In Fig. 16.11, this is executed using the concrete example from Fig. 16.8.

Fig. 16.11

Fixed time windows and content properties in the IDE procedure model as well as transfer to a time bar chart (white bars: Time windows for the respective activity groups. Black filled circles: Milestones)

• In the time bar chart, the project is divided into the processing tasks initialization, concept phase, detailing phase and realization phase ([HaGo-2004], see also Sect. 1.1.2).

• The beginning of the initialization is scheduled with a time lead in which the project can be conceptualized, structured and planned through with regard to project members, tasks, resources, budget and processing times (see Sect. 15.2.3).

• With project start (kick-off), a larger time window is assumed for the Research activity based on project experience than can be derived from the individual activities in the concrete example. Further Research time windows arise when there are changes in requirements or conditions of the environment (in the broadest sense).

• Milestones (Sect. 15.3.2) take place at the beginning of each editing phase and at the end of the project (see also Sect. 22.2.2).

From the time windows, a time bar chart (Gantt diagram⁶) is created, which can be edited with the known methods of project management (for example [Hahn-2001] [Neut-2017]), whereby of course the dynamics and flexibility inherent in the IDE procedure model can no longer be used.

16.4 Summary

The holistic IDE procedure model provides such activities, with which most different products (material and non-material as well as combinations from it, Chap. 2) can be developed. It applies the findings of the Dynamic Navigation of processes and projects to the development of a product. It gives the product developer (or the IDE team) at any time the necessary freedom to develop the product as it appears best at the time of processing. It dynamically maps the current status of product development and thus provides an up-to-date overview of the processing status at all times. From a successful project, the activity network (or parts of it) can be used as a model for further projects.

The eleven activities of the process model, their grouping as well as the procedures, methods and tools associated with each activity (Fig. 16.5) as well as the resulting possibilities of predictive engineering and reverse engineering ensure that in the case of a development task the maximum possible number of work and decisions can be moved forward to the area of product development (Fig. 16.1). If one works with the IDE procedure model and plots the expenditure for the product development against the time, then the front-loading of activities within the product development becomes visible, Fig. 16.12.

Fig. 16.12

Changed procedures in product development using the IDE procedure model. Source This illustration uses research results that were kindly provided by Dipl.-Ing. B. Jörg, Vibracoustic KG

In order to develop viable solution concepts, four of the five activity groups in the IDE procedure model are applied from the phase of Shaping and formation to the phase of Engineering Design. Only when viable solution concepts have been developed can the final details be detailed and completed.

If there are changes during project processing, then the Dynamic Navigation methods (Sect. 15.7, Fig. 15.30) must be used to achieve these changes primarily by changing the configuration and combination of the process elements. If this is not or only partly possible, additional effort (agreed in advance with the client) is required to achieve the changed project objective in order to achieve the changed specifications. This is highlighted and marked in light grey in Fig. 16.12. It is also possible that changes made shortly before the end of the project may result in further expenditure in the form of a final spurt (marked in dark grey), which can be realized, for example, in the form of a sprint (Sect. 15.3.3.2).

By specifying logical and temporal restrictions of the IDE procedure model, it can be converted into a static procedure model if required. Although this can be used to specify a target procedure (which may also be necessary for certain types of process, such as stage-gate processes, Sect. 15.3.1), it no longer makes it possible to permanently monitor and evaluate the stage of development.