Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

6.1 Introduction

Talking about a or the “model of design” requires some basic discussions. Design may address different aspects such as the product as a result of a design process done within a design organization (Fig. 6.1).

Fig. 6.1
figure 1

Model of design

Full size image

Another model of design may be a Black Box with some input information (requirements, need,…) and some output information (BOM, CAD-models, computation, …) and, in addition, resources and management information. This abstract model represents the process of design. The important discussion will be about the benefit supplied by a model like this.

The design of a product including its shape, color, surface, and user interface represents another perspective on “design.”

Due to different views, the concepts of “design” and “models” have to be discussed.

6.2 Design

Design of financial products, fast food products, children’s playgrounds, software, games, etc.; there are no limits to our imagination and in all areas people talk about design. There have been a number of attempts to build a common understanding of design. For example in 1998, a group of scientists discussed the possibilities to develop a “Universal Design Theory” [3] across all disciplines.

The understanding of the word and the concept of “design” may differ widely, depending on the situation and the group of people involved. The design of a Diesel engine may be seen from different perspectives: there is the engineer, the industrial designer, the software engineer—they all have different models and goals in mind when talking about “design.” Even within engineering design one has to consider the role of the mechanical engineer, who usually thinks about stress and meshing of parts; the engineer in thermodynamics has a different idea of design as a problem of heat transfer; the production engineer may see the design of a shaft as a matter of handling and logistics. And there are many more aspects and perspectives.

There is a differentiation between the process of designing products and the design of a product. A product should be understood as an artifact we may be able to sell; it may be just a simple mechanical part, a piece of software, a mechatronic product, a solution for a customer including services, or large and complex systems. Regardless of the area of application we need to have a clear perception, if we discuss the matter of processes of design or the design of a product.

6.3 Design Process

Looking at the process of design we may state that there are several actions, executed in a sequential and/or parallel way. We can often observe small or large iterations. When we look at the results of these actions we can observe successful and unsuccessful actions and the whole range in-between. Quite often it takes a number of subsequent actions and a certain time gap before an action may be judged to be successful. And there is the question about the degree of details in the process we are looking at. We may look at the overall process of designing a complex system or at the “micro”-steps of thinking during design. We may (first) look at only one involved discipline like mechanical engineering or (second) as an intermediate stage at a set of disciplines involved in the design of a mechatronic product or (third) at all importance aspects like engineering, finances, marketing, legal issues, and others. Based on this short discussion about the process point of view it seems that there is a variety of models merely for the processes of design.

Two examples may underline the discussion.

The Munich Procedural Model (MPM) (Fig. 6.2) is a generic model based on other preceding procedural models known in engineering design and in systems engineering. The model contains seven elements that represent tasks to be fulfilled during problem-solving processes. These elements are interlinked in different ways to indicate iterations and other “jumps” depending on the given situation. It focusses on the phases of understanding the problem and clarifying the task. The final stage of ensuring to achieve the goal is added; generating solution ideas builds the center. In the end, it is a generic type of a model supporting problem solving on all the different levels of abstraction and in the whole range of complexity. The main purpose of this model is strengthening the analysis of a given problem and supporting navigation through a set of actions, especially under stress.

Fig. 6.2
figure 2

Munich procedural model [7]

Full size image

The second example is the overall product development process model “FORFLOW,” which has been developed within a team of researchers [11]. Figure 6.3 shows the upper level of the model with six major steps and indicates further levels of details and the overall model in the background. Even though there are several detailed steps it is still a generic model that has to be applied to given situations and be completed by iterations and additional parallel actions. A standard workflow is suggested indicating all activities in a general way. It has to be adapted to the actual project. This model was created to support process planning in product development projects for mechatronic products. It delivers guidelines for the initial planning but also for a detailed navigation during the project including continuous detail planning.

Fig. 6.3
figure 3

FORFLOW process model [9 ]

Full size image

Another concept is the product as a design.

6.4 Product Design

The Munich Model of Product Concretization (Fig. 6.4) shows an example of a product model composed of four partial models. It is based on a number of former models like the framework proposed by Grabowski [3]. There is a set of requirements collected, structured, and documented in a kind of requirement model. This model will be completed step by step during the whole process of design. The solution orientation is supplied by the functional model on an abstract level. The next level of concretization is the working model (usually including physics), which may also be interpreted as a behavioral model. Finally, the component model has to be defined and documented, which may also be named the structural model. Depending on the point of view there are structures on all levels and within all partial models.

Fig. 6.4
figure 4

Munich model of product concretization [8]

Full size image

This model should not be compared with a process model. It may help to think about a sequence of process steps but it is independent of processes.

This is only one example of a large set of models used to describe or analyze products. CAD- models are used to document design-oriented details for production, usage, and recycling; the bill of material supports the material planning and cost calculation; finite element models allow numerical calculation of stress, deformation, heat flow, etc.

Lauer [6] identified a large number of different documents in product development in practice. The major part of these documents may be interpreted as partial model of the overall product model as described by the STEP standards [4]. And there are of course further categories like organizational or psychological models.

Only a few examples for models of design objects (products) and design activities (processes) have been discussed. These models are based on research and experience of the author and his team.

To underline the difficulty of the correct interpretation of models of other author’s one short example will be discussed. This example is part of a publication Umeda et al. [15] about the FBS framework. They discuss (among other points) the purpose of Rodenacker’s model of function and state that his intention was the support of novices in design. Looking at this statement one should consider that this interpretation is based on Rodenacker’s teaching book published in 1971 [10], the origin of his model goes back to his dissertation in 1936 [9]. In the context of his book out of 1971 to be used primarily by students the purpose was the support for novices in new product development. The original purpose was about building some basic ways of abstract description of machines. On the other hand, Umeda et al. [15] looked in 1990 at computable (etc.) models, which up to a certain amount is a different set of purposes at another point of time and for a different group of people/users.

Some of the important points mentioned in this example like the purpose of the model or the users of the model (actors) will be addressed within the following section; here the general nature of “model” is discussed.

6.5 Model

There are numerous different definitions of the term “model”; a few will be discussed in this chapter.

The Oxford Dictionary [14], extract notes:

  • three-dimensional representation of a person or thing or of a proposed structure, typically on a smaller scale than the original

  • thing used as an example to follow or imitate

  • simplified description, especially a mathematical one, of a system or process, to assist calculations and predictions

  • person employed to display clothes by wearing them

  • particular design or version of a product.

Shannon [12] wrote: “A model is a representation of an object, system or idea in some other form than itself”. The definition by DIN 19226, [2] (German standard, translated by the author) is as follows: “A model is the image of a system or a process within another conceptual or representational system.” VDI 3633, [16] (translated by the author) is suggesting: “A model is the simplified reproduction of a planned or an existing system including its processes within another conceptual or representational system.”

All these definitions leave room for interpretation.

Stachowiak [13] wrote a book about model theory and pointed out that there are three important characteristics of a model: transformation, reduction, and pragmatism (Fig. 6.5).

Fig. 6.5
figure 5

Characteristics of modeling [according to 13]

Full size image

Modeling is always based on an original. It may be an existing product, the idea of a new product, a CAD-model, a process, or an organization. The original owns a (large) set of attributes describing it. When building a model, some of these attributes are selected and transformed to define the model. Thus, the model contains a subset of the attributes of the original which may have been modified by the transformation process. Model specific attributes (such as a coordinate system in CAD) may additionally be added.

Looking especially at pragmatism there are three aspects of high importance. The purpose, the users (actors), and the time frame of usage. This may be stated as why, for whom, and when. These characteristics serve to define the boundary of the system, its elements and the interdependencies.

Building a model has always a specific purpose. Based on this purpose the reduction of used attributes and the way of transformation has to be adapted. As there is a specific purpose guiding the process of modeling, there are of course limits of the validity of a model. This is why there has to be a clear statement about the purpose of a model. Some examples are shown in Fig. 6.6.

Fig. 6.6
figure 6

Purpose of a model

Full size image

Further examples may help to understand the situation, communication, or documentation in general.

Another important aspect is that the modeling is done for a subject. A model may be built:

  • to explain the function of an original to customers.

  • to simulate the stress in a bolt by a computational engineer.

  • to analyze the production cost by a person in the financial department.

  • …

There is always a limiting time frame when the model is built. The limitation of capacity to be invested in building the model and the situation at the point of time when the model has been generated are important facts that should be known when using or discussing a model.

6.6 Quality of a Model

Starting with the purpose and the subject of the model, a number of different perspectives have to be kept in mind.

There is a set of different conventions (Fig. 6.7) that have to be considered during modeling. The interpretation of these conventions depends on the purpose (why), the subject (for whom), and the time frame (when).

Fig. 6.7
figure 7

Modeling conventions [1]

Full size image

The accuracy required is highly dependent on the purpose and the time frame and it represents the correspondence between original and model. In early phases of design, the cost calculation model will be good enough to estimate the range of future cost, in later phases the accuracy of the model has to be improved.

The clearness of the model is relevant for the subject, i.e., the user of the model. It is important to know the limits of a model and of course its purpose.

In a similar way, comparability, relevance, profitability, and systematic settings can be discussed.

These conventions provide a first set of requirements for a model. The list has to be completed by following a set of questions.

6.7 Requirements

Table 6.1 contains a systematic overview of the main questions to be aware of during collecting requirements in a generic way. The main focus has to be placed on the purpose of the model including the aspects of the subject and the time frame.

Table 6.1 Requirements [according to 5]
Full size table

6.8 Process of Modeling

The generation and use of a model may follow the procedure shown in Fig. 6.8. Based on the discussion of purpose and requirements there are four major steps when working with models: Start with the definition of the intention (pragmatism including why, for whom, when), then build the model (reproduction and reduction based on pragmatism), then verify and validate the model and finally use the model. In addition, there are iterations especially after validation.

Fig. 6.8
figure 8

Process of modeling

Full size image

The intention includes the purpose, the definition of the system boundaries, the original, and the specific requirements.

In a second major step, the type of the model, the modeling language to be used, the modeling tool, the required resources, and the acquisition of necessary information have to be defined. The type of the model depends on the content, the purpose, and other characteristics. In processes, this may be the model of information flow, the structure of responsibilities, activities, and others. As for the product, this may be a list of requirements, the structure of functions, the use of a 3D-CAD-model, a video-sequence of a simulation tool, or several different forms of models. All possibilities require decisions about the language of modeling and the adequate tool. Data acquisition and achieving high data quality is often challenging.

During verification and validation the quality of the model has to be satisfactorily shown with regard to the given intention. Validation is important for quality assurance. Verification has to guarantee that all requirements are fulfilled in a correct way and validation has to show that the purpose of the model will be fulfilled. Usability checks should ensure that the subject (the user of the model) will be able to use the model in a correct way.

Based on the short discussion about modeling and design, findings and points of view about models of design will be pointed out as a conclusion.

6.9 Models of Design

A small number of models of design have been mentioned before. The general discussion about modeling has shown that models have to follow their purpose; a specific subject (user of the model) and that they are related to the given time frame. Due to these aspects we always have to accept that there will be a large number of models of design.

There are driving forces for an expansion of the family of models, as products are moving to a more complex level via mechatronic/adaptronic products toward PSS (Product Service Systems). The processes become more complex, too, due to trends such as globalization, a number of diversity issues in our societies, legislation, etc.

The large or even increasing number of models has to be accepted. But recognizing this and the above-discussed issues, all authors of new or modified models should clearly note what their model was made for. In the literature we can find a lot of models without a clear statement of their purpose, their subject, and the time frame. It should be a rule that authors not only present a model explaining design (or a process or a product …) but indicate the reasons for this specific kind of a model. This kind of additional specification will help to recognize the limits of its validity.

There are several problems to be solved in design research. The number of different types of models and the number of different modeling languages are some of the key problems that have to be addressed. The modeling types and different languages have to meet the requirements of usability and purpose orientation.