IPA - Concepts and Applications in Engineering

00 25/7/03 09:53 Page i

Decision Engineering

Springer London Berlin Heidelberg New York Hong Kong Milan Paris Tokyo

00 25/7/03 09:53 Page ii

Series Editor Dr. Rajkumar Roy Department of Enterprise Integration School of Industrial and Manufacturing Science Cranfield University Cranfield Bedford MK43 0AL UK Other titles published in this series Multiobjective Optimisation Yann Collette and Patrick Siarry Using the Analytic Hierarchy Process Navneet Bhushan and Kanwal Rai Publication due October 2003 From Product Description to Cost Pierre Foussier Publication due September 2004

00 25/7/03 09:53 Page iii

Jerzy Pokojski

IPA – Concepts and Applications in Engineering

1

Springer

00 25/7/03 09:53 Page iv

Jerzy Pokojski, PhD Institute of Machine Design Fundamentals, Warsaw University of Technology, Narbutta 84, 02-524 Warsaw, Poland

British Library Cataloguing in Publication Data Pokojski, Jerzy IPA: concepts and applications in engineering. – (Decision engineering) 1. Engineering design – Data processing 2. Decision support systems I. Title 620' .0042'0285 ISBN 1852337419 Library of Congress Cataloging-in-Publication Data Pokojski, Jerzy. IPA—concepts and applications in engineering / Jerzy Pokojski. p. cm. — (Decision engineering) Includes index. ISBN 1-85233-741-9 (alk. paper) 1. Engineering design. 2. Expert systems (Computer science). 3. Multiple criteria decision making. I. Title. II. Series TA174.P635 2003 620'.0042—dc21 2003050550 Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms of licences issued by the Copyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers. ISSN 1619-5736 ISBN 1-85233-741-9 Springer-Verlag London Berlin Heidelberg a member of BertelsmannSpringer Science+Business Media GmbH http://www.springer.co.uk © Springer-Verlag London Limited 2004 CLIPS is a rule-based language that was developed by NASA’s Johnson Space Center. GBB is the product of Knowledge Technologies, International Inc., Flexible Service Center, 211 West State Street, Suite 203, Media, PA 19063, USA. http://www.ktiworld.com/GBB/ Goldworks III is the product of GoldHill, 36 Arlington Road, Chestnut Hill, MA 02467, USA. http://www.goldhill-inc.com/goldworks.htm The use of registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use. The publisher makes no representation, express or implied, with regard to the accuracy of the information contained in this book and cannot accept any legal responsibility or liability for any errors or omissions that may be made. Typeset by Gray Publishing, Tunbridge Wells, Kent, UK Printed and bound by in the United States of America 69/3830-543210 Printed on acid-free paper SPIN 10876500

00 25/7/03 09:53 Page v

Preface

This book presents the results of extensive research in computer-supported decision processes in engineering, carried out over many years by the author and his collaborators. The author has cooperated with designers in Poland and in Germany. Very often there was university–industry cooperation for the building of specific software for certain engineering tasks. The majority of the concepts, for example “the designer’s personal assistant” and the decomposition and coordination of multicriteria decision problems, evolved through cooperation with designers in this field. The author, while working together with them, understood that this group of people is characterised by a strong individualism and that the range of applied approaches and methods is wide. The most significant influences on the author’s opinions through contact with the designers were the lectures he delivered for more than 12 years for post-graduate studies on computer-aided design in machinery. The lectures included seminars which required the creation of concepts for an individual computer support system for decision processes, generally well known to the designers who participated in the lectures. In the theoretical part the characteristics of the actual computer-aided design and engineering (CAD and CAE) tools were depicted, whereas in the practical part the students created concepts of computer environments for the realisation of design projects in their own professional work. The task was confined to the expression of the design process. This was followed by the development of a concept for the implementation of different computer technologies in the next stages of their processes. The lectures were attended annually by 15 to 25 participants, allowing the teacher the opportunity to cover quite a wide spectrum of real industrial design processes. The majority of students worked in machine industries with different production outputs and product ranges: from aircraft components to a production line for the spraying of car bodies, and from the development of mobile aerial systems to the production of lightbulbs. Several concepts worked out during the seminars were later realised in practice. It remains to be added that the lectures were conducted flexibly and openly and did not aim at systematic design according to a certain design theory.Although elements of different schools were taught, it was left entirely to the students to choose. Many of the problems that were subjects of the lectures were later picked up and further developed by ordinary students and research students. Looking at the multitude of solutions of the design processes, the author drew the conclusion that the designers’ individualism and internal personal factors play an essential role. Because of that it became important to notice the permanent development of individual engineering knowledge, its richness in facets and its constant evolution. Another observation is the omnipresent re-using of previous processes, their forms of description and the adjustment of the modelling. In spite of certain limitations, often creative v

00 25/7/03 09:53 Page vi

vi

Preface

elements with the freedom to create new processes could be observed. This mostly worked by using well-known tools, that is, existing and reliable sub-processes. Interesting was the relationship between designing and the multicriteria optimisation methods. It became obvious that the multicriteria optimisation methods presented as decision-making theory were widely accepted in connection with everyday decision problems. All of this brought forth a palette of applications based on production realities, which existed at least as prototypes. Some found application in real life, some were implemented within larger projects, and others became the beginnings of a product that is still being developed. Apart from the direct working collaboration there were many discussions, comments and suggestions. A good deal of the work that formed the backbone of this book was realised by my research students Pior Cichocki and Maciej Gil. Various problems concerning the computer tools were solved by my colleagues and collaborators of the computer techniques team at the Institute of Machine Design Fundamentals at the Warsaw University of Technology: Janusz Bonarowski, Jacek Jusis, Boguslaw Kozicki, Grzegorz Linkiewicz, Witold Marowski, Stanislaw Skotnicki, and Jerzy Wróbel. Many problems were solved practically by numerous students, research students and participants of the post-graduate studies. I would like to thank everyone mentioned above for taking part in the research. Also many thanks to my “English advisers”, my wife Antonia and our friends Sophie and Chris Klimiuk who made every endeavour to give my book its final shape.

00 25/7/03 09:53 Page vii

Contents

1. Introduction to the Problems of Knowledge-based Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 The Role of Knowledge in Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Concepts of Design Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Design Knowledge Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Introduction to the Concept of an Intelligent Personal Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Examples Explaining the Sense of Knowledge in Engineering Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 10 10 18 18

2. The Nature of the Personal and the Team-based Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3. Survey of Engineering Knowledge Representations . . . . . . . . . . 39 4. Survey of Intelligent Personal Assistant Software Concepts . . . 51 5. A Common Model of an Intelligent Personal Assistant Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6. Intelligent Personal Assistant – Concepts for Solving Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7. Intelligent Personal Assistant – Design Process Modelling . . . . 81 8. Intelligent Personal Assistant – Knowledge Modelling . . . . . . . . 99 9. Intelligent Personal Assistant – Optimisation . . . . . . . . . . . . . . . . 113 9.1 9.2 9.3 9.4 9.5

Multiobjective Optimisation Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formal Model of a Machine Design Problem . . . . . . . . . . . . . . . . . . . . . Two-level Optimisation Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concepts of Criteria Space Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relationships Between Different Concepts of Criteria Space Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6 A Survey of Selected Multiobjective Optimisation Methods . . . . . . . . vii

113 118 125 126 128 129

00 25/7/03 09:53 Page viii

viii

Contents

9.6.1 Methods Based on the Value Function Concept . . . . . . . . . . . . . . 9.6.2 Method of Interactive Multiobjective Optimisation . . . . . . . . . . 9.6.3 Method of Constraints and Utopia Solution . . . . . . . . . . . . . . . . 9.6.4 Lexicographic Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6.5 Characteristics of Multiobjective Optimisation Methods . . . . . 9.7 Additional Assumptions in the Formulation of Large Optimisation Problems in Machine Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8 Method of Leading and Related Sub-problems . . . . . . . . . . . . . . . . . . .

129 130 131 132 133 134 137

10. Intelligent Personal Assistant – Implementation . . . . . . . . . . . . . 145 11. Intelligent Personal Assistant – Unified Framework . . . . . . . . . . 157 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

01 25/7/03 09:53 Page 1

1

Introduction to the Problems of Knowledge-based Engineering

1.1 The Role of Knowledge in Design This book is concerned with mechanical engineering. Most of the considerations, comments and examples presented in the following chapters deal with mechanical products and mechanical design processes. The goal of design is to create a vision of a product. The product is then marketed with the aim of achieving a scheduled position. The design procedure is carried out by designers working individually or in design teams. They have to start the whole procedure from an initial specification. First they plan their design activities and discuss details of the design. The designers’ planning and handling is based on short-/long-distance strategies. The strategies can have many different goals. Designers have to develop the concepts of a product, which are then evaluated, and subsequently the designers generate a project in detail. The detailed documentation is nowadays mostly done by computer. Design is an activity where designers create new solutions. This activity, since it has a beginning, a middle consisting of various stages, and an end, is called a process (Figure 1.1). It is very difficult to create a formal model of such an activity. Not every step has a formal representation. Much of the activity can take place in the designer’s mind and so not necessarily be apparent to others. The designer, looking for new solutions, tries to test his ideas. He has to model real situations. He decides what is modelled and how. He analyses, considers different aspects, evaluates and synthesises. The whole process consists of a number of actions which are treated by the designer as important, such as which should be performed. The results of these actions support the process of decision making – selecting partial solutions, selecting subsequent problems and steps. Finally, the designer decides when the results are satisfactory and discontinues all actions. Let us take an example: the design process of the braking system design for a mobile crane.

Example 1.1 The process is based on real industrial procedures [12]. The process, proposed and used by an industrial office, was routine but it was the product of longstanding design experience. The procedure was developed some years ago when calculations were generally carried 1

01 25/7/03 09:53 Page 2

2

IPA – Concepts and Applications in Engineering time Product representations

... Process representation

Process activities

Figure 1.1 Product and process representations.

out without the use of computers. It consists of linearly placed steps that are followed sequentially (Figure 1.2). In the case of difficulties with fulfilling constraints in one of the steps it was necessary to repeat the design process from one of the steps preceding the corrected step. Consequently the whole procedure had a linear form. The original version of the process was depicted as a scheme on paper and was stored in that form. The scheme includes places where the designer had to look for external sources of information:catalogues, standards, etc. Every step was regarded as an important activity, and as such was connected with a number of design variables for which values had to be obtained during that step.The values of the design variables were calculated or selected from standards or catalogues. Design processes can be classified as routine, innovative or creative [10, 12, 32, 109] (Figure 1.3). The borders between these classes are not very rigid. However, our example can be called a routine process.

01 25/7/03 09:53 Page 3

1 Problems of Knowledge-based Engineering

3

Standard calculations Vehicle data specification

Braking force calculation

...

Standard components

Pressure distribution

Selection of servo-motors

Selection of air containers

Standards

... Composition of particular sub-systems

... Figure 1.2 Example design process – braking system design for a mobile crane.

We can also classify design processes according to the features of the design variable sets: ●

●

●

If the set of design variables remains the same and each design variable from this set does not change its standard range during the design process, then we call this process routine. However, in the case where the set of the design variables remains the same but some design variables from this set change their standard ranges, then we have an innovative process. When the set of design variables changes and some design variables from this set also change their standard ranges then we have a creative process.

01 25/7/03 09:53 Page 4

4

IPA – Concepts and Applications in Engineering (a) Routine problem Standard tooth gear

Standard list of design variables Z1 Z2 M A B

Standard constraints

...... ......

… fulfilled (b) Innovative problem Standard tooth gear

Standard list of design variables Z1 Z2 M A B

Standard constraints

..... .....

… not fulfilled (c) Creative problem Harmonic drive

Non-standard list of design variables Z1 Z2 M C D

Standard constraints

...... ......

– Comparing with standard toothed-wheel gear different list of design variables and constraints Figure 1.3 Classification of design processes.

The characteristics presented in the above example are a kind of exposition – an articulated process, represented in some objective form. The processes, based on the articulated process, presented above and actually realised in life by particular designers, could have had many different forms resulting from personal experience and knowledge (Figure 1.4). Knowing that this example was a process realised without computer support we can easily imagine that all the steps were done by one particular designer and that all intermediate stages were stored on paper. The designer made calculations, and selected suitable parameters in catalogues and standards. He probably discussed some problems with his colleagues. Each of his steps were evaluated by him alone. He could accept or reject the achieved results.We can also imagine that our designer looked at existing projects, compared the results of the calculations and tried to comprehend the decisions which were made in particular steps. However, he might have had difficulties with some information. It is not always possible to infer from written classic project documentation why he decided on this option (Figure 1.5). Provided that the designer knows the type of the problem considered he may be able to understand the situation. However, it often happens

01 25/7/03 09:53 Page 5

1 Problems of Knowledge-based Engineering

5

Articulated design process

...

Designer X

... Designer Y

... Designer Z

... Personal variants of articulated design process Figure 1.4 Articulated design process and its personal variants.

that people who carried out a certain design process in the past, after some time forget the background details of a particular design situation. The whole design process can be shown in a more formal way than so far in this chapter. This means that we can store the history of different design aspects. The only problem is whether the facts belonging to the history are available. For the designer at the time of solving the problems the facts probably are available. The question, however, is how much of the history of the project development is recorded later in the formal project model and the formal project documentation. We should not expect this formal documentation to contain everything. Somehow there is a formal limit due to external reasons, such as laws and contracts. Thus a formal project description can be realised to some degree – it is mostly a

Realised design process Designer‘s real activities

Final project documentation

...

............. ............. .............

How was it done?

Figure 1.5 Design process and its final results.

01 25/7/03 09:53 Page 6

6

IPA – Concepts and Applications in Engineering Designer’s real design activities

... time Designer’s personal associations

Designer’s personal evaluations

Designer’s personal paper notes

Designer’s formally expressed personal knowledge

Figure 1.6 Intensity of designer’s knowledge generation and articulation.

compromise of different goals created in a very subjective way.Very often one of the goals is to spend a minimum of effort on the problem of project documentation. On the other hand, when analysing real design processes we can observe that the designer remembers a lot of information from the overall accompanying data flow. However, we cannot fully rely on the designer’s ability to remember, although we should notice that any data are at once validated by the designer. The data receive comments containing evaluations and associations made by the designer. This process leads to the designer’s personal knowledge modifications and it is the basis for knowledge development (Figure 1.6). Most designers carry out many different projects throughout their lives. Each project consists of a number of actions. Many of the projects are good material for the verification and modification of concepts which are stored as designers’ knowledge. This knowledge has a dynamic aspect – it changes and develops. We can easily imagine the situation of a car designer in the 1970s. An expert responsible for car safety explains to us that the most important aspect of car safety is the mass of the car body. Twenty years later, the same expert would have told us that according to his knowledge the structure of the car body is the most important aspect of car safety. These are only two stages in the knowledge evolution of a particular designer. As we can see, a designer’s knowledge is not only dynamic but also personal and consequently very subjective. From all the designer’s knowledge we only get to know what is explicitly expressed by him. He can express his knowledge through telling and through sketching, etc. However, the overall process of expressing knowledge requires effort as well as time. It is also influenced by exterior factors such as personal relationships with other designers. Moreover, it often happens that some knowledge starts to evolve while being articulated. Why is that? Because somebody who permanently works with the knowledge without being aware of it modifies the knowledge while sharing it with others. This means that he performs some extraction or verification. It would cost

01 25/7/03 09:53 Page 7

1 Problems of Knowledge-based Engineering

7

enormous effort to update the exterior knowledge depot; it is a task that most people are not willing to undertake. The designer’s auto-censorship is another aspect of personal knowledge acquisition. Simply when he makes private notes (stored in his mind, on paper or in the computer memory) for himself he does it spontaneously and without further deliberations. However, when the notes are meant to be read by others, the designer, consciously or unconsciously, selects his information and considers the consequences. The knowledge which designers have in their minds has different levels of validity. It can be standard routine knowledge or very personal knowledge, which is not verified and more hypothetical. We can observe this feature after longer cooperation with designers, with mutual trust. For what they allow you to acquire depends on a very subjective, personal view and on human interrelations. The last 30 years have brought a relatively high development of computer tools supporting engineers in their design activities. CAD and CAE systems have become industrial standards. Many other engineering problems like simulation, analysis and decision making have been supported by both commercial and non-commercial software. Many of these systems are in permanent use. Others are used from time to time only. The ability to use these systems during the design process is connected with designer cognitive effort. The way in which particular software is applied depends on the domain, its traditions and the personal characteristics of the designer. Design teams, working on their projects, use various computer systems and many computer codes. These systems and codes often function separately. Mostly they are not integrated and exist in several versions.In many design offices we can observe how different computer systems are involved in design processes. The existence of office standards dealing with how they are used is noticeable. These standards function as some office knowledge, as repetitive plans. However, when we take a closer look at why their procedure is so similar to that of others or even the same, we will find that their understanding of the problem is very individual and therefore different (Figure 1.7). Available computer tools: CAD systems

………………… CAE systems

………………… Self-written computer codes

........................... ...........................

Designer X’s real design activities

... Designer Y’s real design activities

... Figure 1.7 Personal way of using computer tools.

01 25/7/03 09:53 Page 8

8

IPA – Concepts and Applications in Engineering Stages of design process [68]: Clarification

Conceptual design

Embodiment design (rough embodiment)

Detailed design (final embodiment)

Design tools: Non-computer tools supporting design processes: human knowledge, human imagination, human memory, drawings, sketches, models, etc. Computer tools supporting design processes: CAD systems, FEM systems, PDM/EDM systems, simulation systems, etc. Figure 1.8 Design process and its stages.

There is a wide variety of computer tools, from which every designer selects a group and uses it in his individual and subjective way (Figure 1.8). By doing so in some way, dedicated software for the needs of a particular designer is created. This fact shows the individualistic aspect of the design process; and what we observe with single designers is also valid for design teams. We have seen that designers’ work is very individual, in the way they use their own approaches and methods, and their individual ways of seeing a problem. When we observe how these people solve their problems, we first notice that they use mental modelling, mental problem identification and mental problem-solving procedures. They do mental exercises with the problem. Sometimes they use handmade drawings, sketches and material models. For them, design can exist as a project in their minds, on paper or in computer memory. However, a lot of the important knowledge remains in designers’ minds. Designers differ in the way they solve their problems [5, 22, 35, 67, 106]. There are people who do everything according to the methodical approach. Others prefer to do everything quickly in their minds without documenting and make fast jumps between different methodical stages, while others like chatting to solve problems. In mechanical engineering, we observe that today’s designers tend to use computer tools at relatively early stages of the design process. These cases are very domain sensitive. Designers often have a number of ready-stored sub-tasks, well known, well tested and well understood to some extent (Figures 1.9, 1.10). When they solve a new problem they like to apply sub-tasks from their private repository of tasks. These tasks have their own knowledge and own rationale. In most cases they are stored in human minds. Sometimes they are made into computer software. In this situation we can speak about customised software. Let us turn to the dimensions: the number of such sub-tasks in the case of a particular designer may reach hundreds. These sub-tasks are somehow knowledge-intensive processes. While using these sub-tasks, knowledge is acquired and verified. Therefore, sub-tasks change in a very dynamic way. Sub-tasks are ready to act as knowledge chunks. Because the customised software reflects the designers’“sub-task thinking” it should offer the possibility of modification and easy redefinition.Without these features the software will become outdated quickly. Ten to fifteen years ago we could observe that some software producers were developing dedicated software for some “very important” customers. Mostly it was done in narrow domains. The development of the software was permanent and the

01 25/7/03 09:53 Page 9

1 Problems of Knowledge-based Engineering

9

Knowledge associated with particular sub-task in its historical development Knowledge associated with particular sub-task in its historical development Sub-task n

... Knowledge associated with particular sub-task in its historical development

Sub-task 1

Sub-task 2 Figure 1.9 A variety of sub-tasks developed and used by a particular designer.

relationships between user and software-maker were very strong. Both partners knew the whole problem very well but from different aspects. After many years of this kind of development the computer systems which resulted from this process had very personal features resulting from the personal knowledge of the designers, the software and the economic circumstances. It is very interesting to see that among designers in the same country, in the same domain, with similar education at a similar age, but working for different firms, there is significant diversification of the structuring and building of sub-tasks. This observation makes software building a personalised engineering activity.

Knowledge associated with particular sub-task in its historical development

Knowledge associated with particular sub-task in its historical development

ed w ith Knowledge associated with particular sub-task in its historical development

... Sub-task j

Sub-task i

... Sub-task k

Computer tools for fast integration Figure 1.10 Design process created from available sub-tasks.

01 25/7/03 09:53 Page 10

10

IPA – Concepts and Applications in Engineering

However, parallel to this development, large vendors of software started to offer universal software, such as CAD/CAE systems with many possibilities that could be customised to some extent. In addition to this, the variety of the existing software tools supporting the design process allows it to be created in a very flexible way. When we look at the actual state of the development of computer tools supporting the design process, accepted by the designers, we see quite a wide variety and flexibility. Nevertheless, all these features allow the user to maintain an individual personalised character throughout the whole computer support system. Actually both kinds of software coexist and cooperate. Not always does the development of software made by large vendors improve software which is made for a very specific domain.

1.2 Concepts of Design Rationale 1.2.1 Design Knowledge Repositories Computer tools belong to the wide range of tools supporting the design process. Information processed by computer tools is not always integrated. However, the integration of computer tools can make the whole design process more efficient. Therefore the problem of fast, effective and flexible integration of design tools should be addressed. It seems to be the only way to exploit the newest achievements in science. Returning to the sub-task concept we can say that the newest science achievements mean adding new sub-tasks to existing software and testing them in conjunction with the existing sub-tasks. We can observe a growing number of commercial systems offering the possibility of fast and efficient integration. These tools enable the user to integrate computer systems quickly and flexibly. They also make it possible to store, repeat and optimise the whole process and to perform parallel analyses with alternative models or software. The trend mentioned above concentrated on the aspect of “how” a particular design process was achieved. In recent years, however, many research teams have worked on the methodology and on tools whose main goal is to store the “why” of the procedure. The information behind a project is called the design rationale [58, 99]. The design rationale information tells why a particular design process has its actual form and why particular design decisions were made. It can be stored as a full project history together with its background in the form of significant decision descriptions. Another practical solution is the storage of design features together with their argumentation. During the last 20 years a lot of research has been accomplished in this field. Some approaches and applications were known already. Most of them were done ad hoc. The problem of data exchange between different applications appeared later. Consequently the standardisation of design rationale information became the next step of this development.We can observe attempts to create knowledge-oriented standards which are the natural development of data-oriented standards (e.g., STEP, IGES) [105]. The acquired knowledge can be re-used by other designers, as it is accessible in specially made design knowledge repositories (Figure 1.11).

01 25/7/03 09:53 Page 11

1 Problems of Knowledge-based Engineering

Designers can be geographically distributed

11

Design knowledge repository

Why?

......... .........

Figure 1.11 Role of design knowledge repositories.

The main goal of collecting the information behind some decisions is to exploit thoroughly the existing knowledge, and to better organise the work of cooperating teams enabling world-wide distribution. As a result the following problems occur: ● ● ●

How to motivate people to share their knowledge with others. Who should do the knowledge acquisition. Who should do the servicing and management of the design knowledge repositories.

However, all the tasks mentioned above require additional effort. Our concept, presented in this book, is based on the idea of an intelligent personal assistant. We assume at first that knowledge is delivered, serviced and managed by the designer personally for himself, in his notebook or his own personal computer database, and for his own purposes. If we think about the actual generation of engineering software and we try to implement the designer’s knowledge in this software we will notice that this is nearly impossible. First, it would be very distributed; second, permanently incomplete and not integrated; and some research [19] has proved that designers do their tasks in many cases on the basis of their private stored materials, often called a “drawer depot” (Figure 1.12). Every designer uses notes of some kind in his professional practice. These notes generally are stored in some paper notebooks. The information in the notebook does not need any formal structure. It can be composed of different pieces of data. The data coming into the notebook are stored chronologically. The searching for data is also done chronologically. Sometimes keywords are important. They can be

01 25/7/03 09:53 Page 12

12

IPA – Concepts and Applications in Engineering

Designer’s “drawer depot” Figure 1.12 Content of designer’s “drawer depot”.

connected with a particular project, the kind of analysis, results, comments or dates, perhaps functioning as headings. Designers often make notes which do not only deal with the actual problems but which are also more general comments on some technical problems and situations. They store their conceptual visions of products or some aspects of their functioning. Designers’ notes often contain comments to other data structures like formal project documentation, formal analysis, formal contacts, etc. In most cases, paper notebooks are treated as personal tools. Today, designers use computer systems to support the design process. The results of the design process are stored on computers, often using standard formats. Designers who have to solve new design problems use their paper notes. Some of the notes are selected and again transformed into a practical form – to a piece of action in the design process, and we obtain valuable results. The whole procedure described above is obviously done by the designer personally. Looking at the process we notice: ● ● ●

Knowledge storage – complete and incomplete form in the paper notebook. Knowledge retrieval – from the paper notebook. Knowledge application – in the design process.

The expert designer knowledge can be acquired and used in a knowledge-based computer system. We can imagine that an expert designer adds knowledge, created by himself, to an existing knowledge base in a dynamic way for his own (expert designer) purposes. In this case the system fulfils the role of the expert’s active notes. This knowledge may contain comments relating to different models, parameters, achieved results and successful plans etc. The stored knowledge can be used by the expert himself and also by the people collaborating with him. Let us assume that we do not only want to collect the text documents but we also want to keep the user’s personal opinions and his personal knowledge chunks with their different representations, because it is likely that the user has had different associations connected with different pieces of knowledge or information.

01 25/7/03 09:53 Page 13

1 Problems of Knowledge-based Engineering

13

Every design office has its own knowledge, specialisation, achievements and style of work. The knowledge of the whole design office can function in different forms: as human (designers’) knowledge, knowledge encapsulated in documents, in selfwritten software, in commercial software and in an officially accepted procedures. This knowledge, available in the office, decides what products can be designed, how they are designed, what analysis should be made in the design process, what goals can be achieved, what the design process is like and what it consists of in a particular case. The knowledge stored in a design office is in permanent evolution. Each project can give impulses for articulation of a new knowledge chunk or for the modification of an old one. Designers’ knowledge can exist in a variety of forms. Non-articulated knowledge, existing only in their minds, probably makes up a large portion of it. Designers’ knowledge can result from design cases developed by them in the past or from the analysis of projects made by other people. In both cases the knowledge is very closely connected with the human and personal way of problem solving. At first, some people approach new problems by analysing many things mentally, some look for inspiration, some start doing conceptual models with computer tools, and others like to discuss the case with each other [5, 22, 35, 67, 106].With each of these approaches very personal procedures are connected. For instance: ● ● ● ●

What plan should be used for the first concept creation. How to create a first conceptual model with the help of the computer tools. How to continue the discussion with other people. How to provoke their interest.

Finally, all the information gathered while dealing with the problem in different ways is stored in the designer’s mind with his own personal interpretation; and importantly, this interpretation changes in the course of time. In this case human designers are the acting power which can transform such knowledge into a sequence of activities which will eventually lead to valuable solutions. The principal problem is how to acquire, capture and encapsulate as much as possible of this knowledge in computer repositories. Computer tools used in the design process are developing towards knowledgesupported software. Many technologies belonging to artificial intelligence are starting to support classical engineering systems (expert systems, case-based reasoning, neural networks, machine learning, intelligent databases, embedded artificial intelligence technologies, blackboard architecture, intelligent agents etc.). All these movements lead in the direction of software taking the role of a knowledge repository and are a mixture of many techniques and software based on different computer technologies (Figure 1.13). Many design problem analyses are based on knowledge which is the result of a long period of design experience, for instance the long period of modelling and analysing dynamic phenomena of some structures with the help of multibody formalism. With this the designer exploits theoretical knowledge together with the knowledge he gained during earlier design activities. While working he conducts a kind of dialogue – between the problem actually solved, his own available knowledge sources and cases from his past experience. It is not easy to depict what knowledge is needed to solve particular problems in machine dynamics. In any case we need a theoretical basis, experience and the ability to model successfully, to make correct observations and to create a suitable

01 25/7/03 09:53 Page 14

14

IPA – Concepts and Applications in Engineering

Content: – data – comments – associations – ...................

Management: – chronology – keywords – projects – ...................

Computer tools: – computer systems – codes – databases – ...................

Personal tools used by designer – actual state

Content: – data – comments – associations – ...................

Management: – chronology – keywords – projects – ...................

Computer tools: – computer systems – codes – databases – ...................

Personal tools used by designer – future state Figure 1.13 Designer and evolution of personal tools.

hypothesis. Most of these elements are rarely found in the literature. Authors who write about problems of real systems mostly concentrate on some theoretical or practical cases and do not describe their full decision path (including positive and negative experiences). The fact that such knowledge may not exist in the literature, and thus is not officially expressed, does not mean that it does not already function as expert knowledge, which – more or less efficiently – helps to solve some kinds of problem. Human experts exploit their own memory for storing such knowledge. Sometimes they have some notes or some schemes. Experts conduct dialogues with different knowledge sources such as what they remember, what they have as paper notes and what they can retrieve from the past stored on their own computers.

01 25/7/03 09:53 Page 15

1 Problems of Knowledge-based Engineering

15

Example 1.2 Let us assume that a designer solves problems of machine dynamics concerning some kind of product over a long period of time [12, 76–78, 90, 91, 93–95, 117, 119]. Each case is a new problem to be solved.While working he exploits his earlier experience and his earlier stored knowledge. Designing can be regarded as a process of moving slowly in the direction of valuable conclusions. During this process, documentation, comments, hypotheses and conclusions are permanently created and verified. Because of their size, machine dynamics problems force expert designers permanently to learn and to articulate new knowledge. Everything is very subjective. There are different levels of knowledge validity. Therefore, the process of multisession testing of the knowledge is very important. It enables the designer to modify and improve the articulated knowledge. Knowledge is a side-effect of designing. It appears and it may be stored. We assume that the designer will use knowledge stored in the following forms: ● ● ●

Classic notes stored with the help of relational database technology. Rules consisting of two parts, condition and action (e.g., when we have values for some data we can perform a particular action). Cases – full multimedia documentation of a particular solved problem.

The procedures of machine dynamics problem solving have the form of multistage processes and can be modelled in the simplest case as linear sequences of activities. As a consequence the linear model consists of a number of ordered nodes corresponding to particular activities. Important events from a particular design process are the basis for the node separation. The knowledge sources can be decomposed into subgroups and then connected with particular nodes of the linear process model (Figure 1.14). Consequently the knowledge-based system, which supports the process of modelling and analysis in machine dynamics, can consist of

Data base Case-based reasoning

Expert system

Figure 1.14 Relationships between different knowledge sub-sources.

01 25/7/03 09:53 Page 16

16

IPA – Concepts and Applications in Engineering

a number of knowledge sources, which are connected with particular nodes in the linear model. On the other hand, the knowledge source of a particular node may consist of several knowledge sub-sources. A designer’s knowledge of a particular node can contain the following: ●

●

●

Theoretical knowledge, based on classical mechanics, using multibody formalism,which is stored in the form of rule-based knowledge bases, relational databases, and multimedia. Case-based knowledge, resulting from problems solved in the past together with knowledge explaining past solutions and knowledge, describing the estimated range of a particular case adaptation (expert system technology, databases and multimedia). Descriptive knowledge, in the form of text and multimedia information, stored in a relational database.

Figure 1.14 presents the scheme of a knowledge aspect in a particular node. It shows that in every node of the linear model we can activate any knowledge source,which supports the generation of missing data. Consequently the linear model of the analysis process is equipped with components which should allow modelling that correlates with human experience and time evolution. Consultations with our domain experts (on car dynamics and fluid flow dynamics problems) proved the fact that the global knowledge problem for particular real machine dynamics problems has a maze structure (Figure 1.15). The maze model is one of the concepts of

Figure 1.15 Evolution of design process model from linear to maze structure.

01 25/7/03 09:53 Page 17

1 Problems of Knowledge-based Engineering

17

models of the design process (Figure 1.16) [9, 10, 75, 78, 83, 132]. In a maze model the designer can start the process of designing from a set of nodes. His way of moving in the maze can be created individually and each time he can finish designing in a different node because not every design process looks the same. Let us consider a single node of the maze model. Let us start with the assumption that we want to move from one node to the next. For this purpose we can employ a relevant knowledge source and look for theoretical or practical experiences; most importantly, we can move from one node to the other via special links called association links. The association links are special fast connections between different knowledge sub-sources belonging to different nodes.They are created by the designer while using the whole structure. Designers often solve parallel alternative problems. If we add the ideas mentioned above to our concept of environment it means that the designer can move in the maze,change his knowledge sources and consider (i.e., change dynamically) several projects at the same time. Parallel to the process of creating a path in the maze model the designer can try to select the best parameters for his solutions and as a consequence create a sequence of problems belonging to the category of optimisation problems (Figure 1.17). We can assume that with every node of the maze model can be connected a multicriteria optimisation problem created by the designer by selecting decision variables, constraints and criteria functions.The sequence of optimisation problems – accompanying a path in the maze model – can be mutually interacted with via decision variables, constraints or criteria.

Initial nodes

Final nodes

Processing nodes Figure 1.16 Maze model of design process.

01 25/7/03 09:53 Page 18

18

IPA – Concepts and Applications in Engineering Problem 2 Problem 1 Problem 3

Realised path

Figure 1.17 Maze model integrated with optimisation problems.

1.2.2 Introduction to the Concept of an Intelligent Personal Assistant The concept of an intelligent personal assistant, from its functional point of view, reminds us of the concept of a word processor [91]. Word processors are an electronic development of the typewriter which have the ability to store and re-use text. We can observe that people who have used word processors for some time no longer produce documents by hand. The main reason is the ability to re-use text. If a user produces his own documents he takes care that everything is done according to the quality standards acceptable to him, and because text can be re-used by the author in new documents, this means less work in the future. In the book we try to interlink two ideas: ● ●

A computer system integrating computer design tools. A computer system fulfilling the role of an intelligent personal assistant.

The book presents the concepts of a knowledge-based system supporting machine design called the intelligent personal assistant.

1.3 Examples Explaining the Sense of Knowledge in Engineering Design In the above sections we started using the term knowledge. We were using it very intuitively and descriptively. The basic meaning of this term is widely known.

01 25/7/03 09:53 Page 19

1 Problems of Knowledge-based Engineering

19

Somebody can have knowledge, knowledge can be available, and can be created, captured etc. We can imagine that knowledge can be stored and later be re-used. Knowledge is behind all human activities. However, it is difficult to explain what knowledge representation means. Before we try to make it understandable we have to explain the role of knowledge in engineering activities. We do this with the help of several technical examples.

Example 1.3 Let us look at the process of toothed-wheel design. The complete design process is relatively comprehensive and complicated. For our purposes we want to concentrate only on few selected aspects. First we have to determine the intention of the process.Is it the calculation of basic parameters? The changing of the manufacturing process? Or is it a part of a more complicated and complex adaptation problem, for instance to create a new variant of a car gear box where we have several pairs of cooperating toothed wheels? There is basic theoretical and practical literature dealing with these topics. Should we look for knowledge there? Certainly there will be a lot of information, which should provide knowledge on this problem. However, there is little chance that we will find something that fits our design situation exactly. Probably only a part of the information found will be helpful for our purpose. Therefore we will have to do some intellectual work and transform the information available in the literature sources into a sequence of steps which can be carried out by the designer in order to lead to the solution of the problem. Many problems of toothed-wheel design are standardised and we can find procedures which consist of steps – single activities where we can get ready information on how to solve our problem. Maybe this procedure can even be done on a computer system where our role will be reduced to problem modelling and evaluating the final results. In both these cases we can speak about knowledge. The knowledge can be stored for instance in books, or as an algorithmic procedure forming the basis of some computer code (Figure 1.18). Our knowledge can have the form of separate knowledge chunks dealing with different topics and can tell us about the multitude of problems connected with our domain without any specific intention.This is the form which we know from lexicons, encyclopaedias and special guides. It is easy to imagine that today such an approach exists in the form of computer multimedia applications equipped with a number of tools (keywords, searching, browsing) helping to find the proper topics (Figure 1.19). Such applications are produced by firms or publishing companies. Some of them are accessible to everybody via the internet, others only to users who have been granted the right to use them.

01 25/7/03 09:53 Page 20

20

IPA – Concepts and Applications in Engineering Design process based on literature

Project documentation

Design process based on literature and expressed as computer code

Project documentation

Figure 1.18 Design process represented in two different ways.

Browsing, searching

Results: text, pictures, ...

Browsing, searching

.........

Figure 1.19 Looking for knowledge in knowledge repositories.

01 25/7/03 09:53 Page 21

1 Problems of Knowledge-based Engineering

21

How can the designer use such an application? First he must clearly know what problem he has to solve. Then he decides on several keywords and starts searching. Finally he gets some results, for instance some pieces of information in form of articles. Let us assume that he selects two of them, reads them, and starts again with new keywords and new searches, and the procedure continues. In this approach we can recognise two stages in each cycle: (1) formulation of keywords (by the designer) and searching (by the computer), (2) reading of information found, and inferring and understanding (by the designer). The whole approach is shared between the designer and the computer. We call such an approach “human interpretable”. In this case the human plays the key role. Obviously our knowledge stored and manipulated this way can be connected with some narrow domain and can then have the form of specially prepared recipes. Moreover the knowledge can be continuously updated. From this a complete management system can be made.The knowledge which is stored cannot only be used by a single designer, but also by a department or by the whole company.The system in question can exist as an autonomous application or as a deeply integrated system.In the latter case such an application looks like a help tool only, but in reality it offers rich functionality and it is an intelligent assistant.

Example 1.4 Let us turn towards a system which supports the design process of a car braking system (Figure 1.20) [102]. Naturally such a system is relatively large, consists of a number of modules and is integrated with a database of components offered by different suppliers. Designers who work on braking systems often have to consider whole families of cars and at the same time they must try to reduce the number of braking system variants. They have to compare the results of their work with former models, models from competing companies etc. In any of these analyses they need approximate data for instance about the centre of mass. These data are often evaluated on the basis of some knowledge. We can imagine a system where a module which supports generation of missing data is added to those modules aiding the design of the braking system; and this additional module is organised as an application with keyword searching. It is very useful to have the ability to move directly among different modules. An example of such an application is shown in Figures 1.20 and 1.21. Reading and understanding information costs effort. Therefore we should consider whether this effort can be reduced. The knowledge chunks stored in the system are relatively short and are not complicated. This means that what we store normally should be represented in a more decomposed way. We can imagine that our knowledge chunks can have the form of rules where the first part contains the conditions

01 25/7/03 09:53 Page 22

22

IPA – Concepts and Applications in Engineering System functionality

Knowledge chunks supporting assistance, implemented into system

Main window of system – procedural processing

Integrated knowledge-based assistance module

Figure 1.20 System for car braking systems design support.

which should be fulfilled and the second tells us what actions can be taken after the conditions have been fulfilled. The main problem is that we have to prepare a lot of such knowledge chunks and that they should be based on the same vocabulary. Only then we are able to think of an automatic control system which can perform the inference. We may start from some initial keywords; later our control system looks for knowledge chunks which have conditions fitting our keywords. After having used the knowledge chunks found, the result can be stored and be the basis for the next automatic attempt to find suitable knowledge chunks. This procedure can be continued again and again. The process of inference presented above is nearly an informal description of the way that classic expert systems solve problems. However, we want to make it more formal. This is to be shown with a simple example.

Example 1.5 As we see, knowledge can be expressed in a “human-interpretable” form and in a “computer-interpretable” form as well. The inference

01 25/7/03 09:53 Page 23

1 Problems of Knowledge-based Engineering

23

Inference

.....................

Results of inference

Data flow from procedural part to knowledge-based module Figure 1.21 Cooperation between procedural part of system and knowledge-based assistance.

process in the case of a computer-interpretable application does not only work with information which is in the form of words (strings). It can also make modifications to technical models, geometrical and non-geometrical. Let us consider the following case. We want to integrate inference together with geometrical modelling. For instance we want to create a geometrical model of components belonging to the car gear box: a toothed wheel together with a clutch cooperating with a wheel [92]. For this purpose we may create a number of variables which are basic parameters of the toothed wheel. If we want to obtain a geometrical

01 25/7/03 09:53 Page 24

24

IPA – Concepts and Applications in Engineering Basic initial parameters of toothed gear ................ ........ ................

Parametric formulas for toothed wheels

........

Rules defining geometry of clutch

Parametric and knowledge-based model of toothed wheel

Knowledge-based model of clutch

Complete assembly Figure 1.22 3D knowledge-based and parametric modelling of tooth wheel and clutch.

3D model of the gear we have to define formulas describing the geometry of the toothed wheel. If we want to add a clutch to the wheel, the geometry of the clutch should correlate in some way with the basic parameters of the wheels.We can build rules defining these dependencies, and then for any combination of toothed-wheel parameters we can get a full geometrical model of both the toothed wheel and the cooperating clutch. As a final effect, our design is partly parametric and partly knowledge based (Figure 1.22).

Example 1.6 Let us take another example belonging to the category of knowledge-based non-geometrical systems. It is a system which supports the design process of a piping system [74, 85] (Figure 1.23). The specialised system consists of two sub-systems: one models the geometry of the piping system and the other analyses the problem of fluid flow dynamics within the system. These sub-systems are connected to each other. The generator of the fluid flow dynamics model is a knowledge-based system. When the geometry of the piping system is given first, the user can later add some physical data and then get the pressure distribution in the piping system. The knowledge-based system was filled with the knowledge of how to transform a geometrical model and its physical data into a fluid flow dynamics model. Thereby about 60 rules which supported the model transformation were created. Additionally the geometrical model required physical data like pressure, flow or temperature.

01 25/7/03 09:53 Page 25

1 Problems of Knowledge-based Engineering

25

Geometrical model with defined physical data

Geometrical model

P, T, ... Problem modelling

Knowledge-based module for fluid model generation

Cells ........... ........... ........... Links ................ Knowledge-based and procedural processing

Simulation problem written in problem-oriented language

Simulation

State variables in nodes (in time domain) ............ ............

Results of simulation

Visualisation

Results analysis Figure 1.23 Functioning of system for fluid flow dynamics analysis.

A special editor supporting the physical data modelling, as values connected with geometrical primitives, was developed. Some data were generated on the basis of an algorithmic approach, for instance the flow resistance calculations for different structures like bends and valves. Rules deciding what is processed in which part of the piping

01 25/7/03 09:53 Page 26

26

IPA – Concepts and Applications in Engineering

network were created.The knowledge-based module could then create a dynamic model of fluid within the geometrical model of the piping system. The results of the simulation were presented as diagrams modelled in a geometrical model. There were static diagrams of different state variables anywhere in the network, or diagrams and animations were made on an indicated path in the piping system. In this way the user could work with the system without knowing the simulation system. In the above examples we showed that our knowledge dealt with the problem of features in particular.We see that the knowledge can be connected with design subtasks which are knowledge-intensive processes.

02 25/7/03 09:53 Page 27

2

The Nature of the Personal and the Team-based Design Process

Every design process is initiated by a specific need. This process normally starts with some ideas. Gradually the designer develops a basic concept which meets the need. He analyses and evaluates developed ideas. He has to create and be precise with his design details. This multistage activity is called the design process. Questions relating to this process are [5, 35, 50, 51, 62, 65, 68, 101, 106, 112, 113]: ● ● ● ● ● ●

How do individual designers work? How do concepts appear? How is a concept developed? What are the sources of inspiration? How are different interactions between connected sub-problems achieved? How does the designer handle design process iterations?

As was found by research, designers often do mental modelling. They exploit their imagination and work with pictures in their minds. Then they try to figure out characteristics of the problems. Often, while explaining their task to other people, designers begin to understand the matter themselves. It becomes more clear to them and they find new ideas. With more complicated problems some designers try to sketch their ideas on paper or use a CAD system. Others build physical models and test their concepts at once in “reality”. The third group are quick thinkers who are immediately able to express their ideas on how to handle the problem. Others have to speak with other people. Finally, all the different ways of approaching a project help the designers to understand the main problem of the task and clarify its characteristics. During this initial stage of the process the designers look for new information and try to form associations with what they already know. Everything is done with the intention of finding a solution to their problem. They do some mental inference. The designers do their analysis with the help of a multitude of models and tools. The models which are considered could exist only in the designers’ minds or be expressed in a more formal way. The designers build the so-called formal models often by using formal methods and formal software. The human ability to build models and test them is still the key aspect of designing. Specific knowledge is connected with every technique of modelling and analysis. This knowledge decides what analysis can be done, what goals can be achieved and how the design process can look in a particular case. 27

02 25/7/03 09:53 Page 28

28

IPA – Concepts and Applications in Engineering

The sequence of problems considered in the design process reflects the design history and can be a good source of information for solving particular problems. It may also be a source of available plans already applied in a design process. The knowledge stored by designers is continuously modified. Each project analysis can give impulses for a new articulation or modification of a knowledge chunk. Designers exploit their own memory for storing different kinds of knowledge or for the evaluation of other knowledge sources by referring to notes and schemes. Very interesting results with the interdisciplinary empirical studies of engineering design can be found in [5, 22, 35, 50, 51, 67, 100, 106]. The research presented was done in industrial design offices and university laboratories over many years. One of the goals of this research was to answer the following questions from the perspective of our times: ● ●

What patterns of thought do designers use while problem solving? What is the influence of formal methodologies?

The results obtained are multidimensional. Details of different design stages, different models, different tools, the influence of computer tools and the way they are used are considered. Very informative are the results of the comparison between designers who are only practitioners and designers who have a methodological education. Along with this are extremely interesting comments about the form of information which is applied during the design process and the way this information is transformed. The observed relationships between individual and team work in real cases are significant, for instance [67]: “in design processes individual work dominates to an extent 70% compared to 30% of teamwork.” For us, most significant is the variety of ways that designers do their job at each stage (individually or in a team). We can notice a strong influence of subjective and personal factors. If in addition we think of the knowledge behind every design decision, we see clearly the importance of these personal and subjective aspects; most of the design knowledge has such roots. Environmental conditions can also play a significant role. If we want to consider a particular design process realised by a particular designer we not only have to understand his actual knowledge-intensive activities, but also some background knowledge concerning his professional experience. In the case of team work this aspect often becomes even more important. The development of computer technologies has changed the shape and the range of analysis carried out during the design process. It allows classic approaches to be exploited to a wider extent. New methods have been developed which were originally invented as a computer approach. The problem of interaction between man and the computer implementation of a particular method has become very important. The interaction between the designer and the design problem can be considered on different levels. The levels are set on the basis of cooperation between man and computer. However, this classification has a very strong influence on the particular level and the knowledge structure. When we speak with designers they mostly use the following levels: ●

Designer–domain problem (e.g., domain knowledge for the class of problems in machine design or mechanics). This is the highest and the most abstract level, which is very well synthesised. The knowledge presented in this context is very valuable. We can observe an articulated knowledge structure, its hierarchy

02 25/7/03 09:53 Page 29

2 The Nature of the Personal and Team-based Design Process

●

●

●

29

and its dynamic historical aspect. Hereby the designers use analogies and metaphors while explaining. Listening to them, we can almost sense (if we have enough imagination) how two surfaces cooperate in a joint or how one toothed wheel fits into a second one, for example. Designer-methods of particular domains (methods which belong to a particular domain and have an acting function). They support the process of achieving valuable solutions. Most of the designers who achieved the first level did their work exploiting relatively wide experience with some models and methods. Each of their cases solved in practice has a knowledge-intensive background. They can present practical knowledge on how to solve a particular problem by giving the evaluation of the whole approach. Additionally they compare this approach with other approaches, indicating their advantages and disadvantages. We can learn how the approach was developed over some years. Designer-methods of a particular domain in a programmed form. Today many of the engineering problems are solved with the help of computers. Consequently behind the designers’ decisions stand processes or other steps realised by computer systems. This is connected with very practical knowledge assisting in solving design problems with a particular computer code. Designer-computer systems, including methods of a particular domain in programmed form. Rarely does a designer use only one single computer tool. Often a variety of tools are used as a part of a larger task. This can be thought of as the building of a code of codes. One of the main technical problems is its integration. However, at the moment, most important is the knowledge of how and why new tasks are created, which is obviously the consequence of new integration ideas.

From a certain stage, most of the design problems are solved with the help of computer systems which allow different computer models of design products to be built. The designer’s work is to extract important artefacts which can be formed from his mental models. Then he must “squeeze” them into the frames of existing computer systems. Later he has to follow the design process and do the same with different analysis, considerations and details; and at every step he has to consider what parts of his mental work can be placed in the formally developed models and descriptions. This is a situation we are always confronted with, irrespective of whether we use computer tools or not. One has more freedom in thought than in action. From this we gather that a design process developed by a designer is richer than its formal representation can ever be. Let us take an example from machine dynamics.

Example 2.1 The development of computer technologies has a strong influence on the range of analysis in machine dynamics [12, 72, 78, 90]. Many problems previously regarded as complicated have become routine. However,some classes of problem have been left unchanged by this development. Up to now it is still difficult to store the knowledge of modelling and solving a particular problem.If somebody wants to solve a certain problem in machine dynamics (a particular phenomenon or

02 25/7/03 09:53 Page 30

30

IPA – Concepts and Applications in Engineering

product) he has to build (or select from earlier considered models) and examine several models. This process can be called problem learning (by the designer). In many cases it is a long and time-consuming process. The modelling of a car dynamics model means a lengthy period of work for the designer.For the modelling of a specific multibody system, for example, it is necessary to describe a system of bodies, their connections, their parameters and their external forces. A real car dynamics problem will serve as our example:the stabilising moment of the steering wheel. We started analysing our problem by reviewing relevant literature.We found several descriptions of this problem. There are also some theoretical models and mathematical formulas.They present a part of the abstract knowledge,which gives a general overview of existing problems. However, in the literature there are hardly any examples of described models. It is very difficult to find out which model could be used in our specific situation. All described models are similar to each other as far as their complexity is concerned. So to put in order and complete these pieces of information we arranged meetings with an expert from the domain [12, 78, 90]. The expert has been dealing with simulation models of cars for more than 20 years,therefore he has extensive practice and theoretical knowledge. We obtained from him information about the relevant cases resulting from negotiations with clients, decisions regarding constructions of a new model and the adoption of a new problem to already existing solutions. We were particularly interested in the way he collected data, searched for missing data, and finally assessed the achieved results. We have noticed that the expert at the beginning of each thread often refers to one of the previous cases. Then he establishes the procedure for the actual case and tries to generalise it.This is how a linear description of problem solving arises. After the expert has presented several cases we notice that there are common points in the set of linear descriptions. We connect these points and we notice that the output reminds us of a maze model. Figure 2.1 shows us how to proceed with the problem.The diagram presents the way of adapting the problem to existing models and the possibilities of building a new model. The expert divided the problem into several subgroups. These subgroups distinguish the way the problem is perceived: how deeply one wants to analyse it, which situations are taken into consideration, if the driver’s point of view is important in a particular case, or if the research results are to be used in court.When the problem is classified,it is necessary to find out the purpose of the research, what kind of data can be delivered, and the influence of geometry relationships on the final results. Finally, it is important to know who performs the research because some of the developed models are of an enormous value and cannot be disclosed.It should also be remembered that time and financial resources allocated to a project are of great importance. At the end

02 25/7/03 09:53 Page 31

2 The Nature of the Personal and Team-based Design Process Crash inspections: require precise calculations, but a lot of data missed, and not available at the time after an accident Define the scope and level of detail for modeling the problem: – general assessments – detailed calculations

Preliminary problem description – Define the scope and level of detail – Adoptions of test scenarios – Crash inspections – Driver’s comfort and safety

Adoptions of test scenarios: – normal conditions e.g. parking – specific and extreme conditions e.g. chicaneries

Examine or enhance vehicle – driving features, like: – driver’s comfort and safety – stabilizing features of wheel

General assessments – Value of electronic controlled steering systems (ASP) – All wheel drive systems and their stabilizing features Detailed calculations – Prepare the system to meet appropriate standards – Enhancing geometry of legacy steering systems – improve unfavourable phenomena playing in system

Client’s profile Who is the project for? Student, research lab, industry delegate Client’s profile Estimated inputs: time and founds allocated for project

Driving scenarios Examining low speed drive (