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 ...

Author: Jerzy Pokojski

36 downloads 1088 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

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 Cranﬁeld University Cranﬁeld 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 speciﬁc 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 speciﬁc 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 ﬁeld. 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 signiﬁcant inﬂuences 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 conﬁned 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 ﬂexibly 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 ﬁnal 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 – Uniﬁed 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 speciﬁcation. 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 difﬁcult 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 classiﬁed 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 Classiﬁcation 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 difﬁculties 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 ﬁnal 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 ﬂow. 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 modiﬁcations 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 veriﬁcation and modiﬁcation 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 inﬂuenced 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 modiﬁes the knowledge while sharing it with others. This means that he performs some extraction or veriﬁcation. 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 veriﬁed 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 ofﬁces we can observe how different computer systems are involved in design processes. The existence of ofﬁce standards dealing with how they are used is noticeable. These standards function as some ofﬁce 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 ﬁnd 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 ﬁrst notice that they use mental modelling, mental problem identiﬁcation 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 veriﬁed. Therefore, sub-tasks change in a very dynamic way. Sub-tasks are ready to act as knowledge chunks. Because the customised software reﬂects the designers’“sub-task thinking” it should offer the possibility of modiﬁcation and easy redeﬁnition.Without these features the software will become outdated quickly. Ten to ﬁfteen 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 ﬁrms, there is signiﬁcant diversiﬁcation 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 ﬂexible 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 ﬂexibility. 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 speciﬁc 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 efﬁcient. Therefore the problem of fast, effective and ﬂexible 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 efﬁcient integration. These tools enable the user to integrate computer systems quickly and ﬂexibly. 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 signiﬁcant 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 ﬁeld. 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 ﬁrst 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 fulﬁls 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 ofﬁce has its own knowledge, specialisation, achievements and style of work. The knowledge of the whole design ofﬁce can function in different forms: as human (designers’) knowledge, knowledge encapsulated in documents, in selfwritten software, in commercial software and in an ofﬁcially accepted procedures. This knowledge, available in the ofﬁce, 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 ofﬁce is in permanent evolution. Each project can give impulses for articulation of a new knowledge chunk or for the modiﬁcation 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 ﬁrst, 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 ﬁrst concept creation. How to create a ﬁrst 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 artiﬁcial intelligence are starting to support classical engineering systems (expert systems, case-based reasoning, neural networks, machine learning, intelligent databases, embedded artiﬁcial 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 ofﬁcially expressed, does not mean that it does not already function as expert knowledge, which – more or less efﬁciently – 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 fulﬁlling 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 difﬁcult 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 ﬁrst 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 fulﬁlled and the second tells us what actions can be taken after the conditions have been fulﬁlled. 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 ﬁtting our keywords. After having used the knowledge chunks found, the result can be stored and be the basis for the next automatic attempt to ﬁnd 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 ﬂuid ﬂow 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 speciﬁc 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 ﬁgure 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 ﬁnd 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 ﬁnding 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. Speciﬁc 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 reﬂects 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 modiﬁed. Each project analysis can give impulses for a new articulation or modiﬁcation 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 ofﬁces 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 inﬂuence of formal methodologies?

The results obtained are multidimensional. Details of different design stages, different models, different tools, the inﬂuence 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 signiﬁcant, for instance [67]: “in design processes individual work dominates to an extent 70% compared to 30% of teamwork.” For us, most signiﬁcant is the variety of ways that designers do their job at each stage (individually or in a team). We can notice a strong inﬂuence 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 signiﬁcant 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 classiﬁcation has a very strong inﬂuence 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 ﬁts 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 ﬁrst 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 (<10 kmp h) – maneuvering

Driving scenarios Examining higher speed drive the impact of tire

31 Simple models – give general outlook of the problem (motorcycle models)

Average models – most of data can be easily acquired from client's side, tables, past cases

Partial models – 1/2 or 1/4 part of whole vehicle

Complex straight forward drive models

Models in time frequency domain

New models required to be developed from scratch

Figure 2.1 Expert’s plan for solving car dynamics problem [78].

we can find out which of the existing models could be used in a particular situation, or if the expert would be interested in building a new one. The results of our research can be described with the following characteristics. The number of degrees of freedom (if referring to multibody systems dynamics) is one of the most significant parameters.In real industrial cases it can amount to a few hundred and result in a multitude of models and analysis. The overall process of analysis can take several months. The designer formulates many rules in his mind and tries to explain the examined phenomena. Parallel to this he validates this knowledge, creates new or better rules and draws final conclusions. For this he uses written notes. At the same time the designer tries to improve his modelling, his methods of analysis and his parameters, and observes all the side-effects. All together it provides an immense field for searching.

02 25/7/03 09:53 Page 32

32

IPA – Concepts and Applications in Engineering

In the above example, we presented the way human designers do their work; in a knowledge context and as individuals. The selected problem can be regarded as a speciﬁc design task realised by a single designer. Real design tasks consist of several sub-tasks. In his work, a designer does not only try to build the structures of his sub-tasks: parallel to this he also tries to optimise particular problems. So while he is creating a path of sub-tasks (which reﬂects the core of building the problem structure) the designer at the same time is trying to select the best parameters for his solutions. In the end he can create a whole sequence of problems belonging to the category of optimisation problems. With every sub-task a multicriteria optimisation problem created by the designer can be connected by selecting decision variables, constraints and criteria functions. The sequence of optimisation problems – accompanying a path of sub-tasks – can be mutually interacted with via decision variables, constraints or criteria. However, optimisation problems of different sub-tasks can interfere. We want to clarify this problem by means of a simple example [64, 72].

Example 2.2 Let us assume that our designer has to consider the problem of moving a car with constant velocity and that he has to estimate the quality of the suspension [63, 72, 97]. He builds his first sub-task – a simple dynamic model – linear with two degrees of freedom (Figure 2.2).The equations of motion are m1y˙˙1 + k1( y1 − y 2 ) + c1( y˙ 1 − y˙ 2 ) = 0, ˙˙ ˙ m2 y 2 + k1( y 2 − y1) + c1( y 2 − y˙ 1) + k2 ( y 2 − q) + c 2 ( y˙ 2 − q˙ ) = 0,

(2.1)

where: – – – – –

m1, m2 are the sprung and unsprung masses; k1, k2 are the stiffnesses of the suspension and the tyres; c1, c2 are the damping coefficients of the suspension and the tyres; y1, y2 are the displacements of the sprung and unsprung masses; q is the kinematic excitation (road roughness). y1 m1 k1

c1

k2

c2

y2

m2

q

Figure 2.2 Dynamic model of car.

02 25/7/03 09:53 Page 33

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

33

The designer assumed that the excitation is modelled as a stationary stochastic process with zero mean value and spectral density S(v).The spectral density corresponded to the asphalt road and the speed of the car v 18 m/s. Then the designer selected a set of decision variables (stiffness and damping coefficient of the suspension). The feasible domain is defined in the following way: 1 = {( k1, c1) : k1min ≤ k1 ≤ k1max ; c1min ≤ c1 ≤ c1max )}.

(2.2)

The designer selected two objective functions: Q1, the variance of differences between the displacements of the sprung and unsprung masses. Q2, the variance of the sprung mass acceleration. The designer did calculations and obtained results. In Figures 2.3 and 2.4 we have the feasible domain together with the objective space

Decision variables: (k1, c1)

Fixed values: (k1, c1)

Problem 1

Decision variable: (k0)

Problem 2

Realised path Figure 2.3 Optimisation problem together with maze model.

02 25/7/03 09:53 Page 34

34

IPA – Concepts and Applications in Engineering (k1, c1)

(k0)

(k1, c1)

c1

[Ns/m] 5000

k1

0

50 000 [N/m]

10 000

[m2/s4]

Q2 Pareto-optimal solution selected by designer

0.20

Q1

0.05 10⫺5

4 ⫻10⫺5 [m2] Pareto-optimal solutions

Figure 2.4 Results of ﬁrst sub-problem.

with final results. As is visible in the objective space we obtain a Pareto-optimal set. This means that the points belonging to this set cannot be improved. After that the designer selected one of the points belonging to the Pareto-optimal solutions. Later the designer started to consider the next dynamic problem concerning the respective car. He built a model which was suitable

02 25/7/03 09:53 Page 35

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

35

for examining how the same car performs when going over bumps in the road. Again he built equations of motion: m1y˙˙1 + F + c1( y˙ 1 − y˙ 2 ) = 0, m2 y˙˙2 − F + c1( y˙ 2 − y˙ 1) + k2 ( y 2 − q) + c 2 ( y˙ 2 − q˙ ) = 0.

(2.3)

The physical parameters are as in the previous model. The elasticity force is a function of the spring deflection. The force has the following form: k0 ( y1 − y 2 ) + ( k0 − k1)a  F = k1( y1 − y 2 ) k0 ( y1 − y 2 ) + ( k1 − k0 )a

for ( y1 − y 2 ) ≤ − a, for | y1 − y 2 | ≤ a , for ( y1 − y 2 ) ≥ a.

(2.4)

In this case the excitation was modelled as a single harmonic wave (H – height, D – wavelength, x – horizontal coordinate):  H 2  1− cos x  for x ∈[0, D ], ± q( x ) =  2  D  0 for x ∉[0, D ]. 

(2.5)

There were the following decision variables: ( k1, k0 , c1).

(2.6)

The feasible domain was defined as 2 = {( k1, k0 , c1) : k1min ≤ k1 ≤ k1max ; k0min ≤ k0 ≤ k0max ; c1min ≤ c1 ≤ c1max }

(2.7)

The objective functions were defined as min

 max | y (t ) − y (t )|, | max | y˙˙ (t ).  1 2 1  t ∈[ 0,T ] 

( k1,k 0 ,c1)∈2 t ∈[ 0,T ]

(2.8)

Calculations were made for the fixed value of k1, c1 (from the first considered problem) and as a consequence, the designer obtained the results shown in Figure 2.5. These results were obtained when he considered problem 1 first and then problem 2.We assumed that the designer would solve both problems sequentially, according to their importance. It is also possible that the results which the designer acquired after solving the first problem enabled him to build and solve the next one.This thought process can be observed quite often.

02 25/7/03 09:53 Page 36

36

IPA – Concepts and Applications in Engineering (k1, c1)

(k1, c1)

(k0)

k0 40 000

1 20 000 [N/m]

max ÿ1(t)

Pareto-optimal solution selected by designer in second problem for fixed decision variables from first problem

t僆[0,T]

[m/s2] 12

max y1(t)y2(t) t僆[0,T]

4 0.05

0.1 [m]

Pareto-optimal solutions for second problem solved separately Figure 2.5 Results of second sub-problem.

The number of interconnected sub-problems can be higher than two. According to his knowledge the designer can consider various additional phenomena. Everything depends on the whole design problem and the goal of the design analysis. The sub-task structure of the path and the associated optimisation problems can be created dynamically by the designer. However, the two interconnected problems presented above can also be considered in a different way. We can treat the two sub-problems as one global optimisation problem. In this case we can build a common feasible domain (Figure 2.6). As presented in the ﬁgure, we have two objective spaces. Now we can observe that in both sub-problems two Pareto-optimal sets are achievable. However, if we analyse the points from the ﬁrst Pareto-optimal set we will see that the points corresponding

02 25/7/03 09:53 Page 37

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

37

k1, c1

min(Q1, Q2) Driving on asphalt road

{

min max y1(t)⫺y2(t) , max ÿ1(t) k0

t僆[0,T]

t僆[0,T]

}

Driving on bumps

Figure 2.6 Structure of optimisation problem.

(k1, c1) (k1, c1)

First designer and first problem

Realised path

(k1, c1)

Second designer and second problem

Realised path

Figure 2.7 Coordination between two designers.

(k0)

02 25/7/03 09:53 Page 38

38

IPA – Concepts and Applications in Engineering

to the second sub-problem are not Pareto-optimal. Similar dependencies exist between the second Pareto-optimal set and the corresponding points in the ﬁrst sub-problem. If we ﬁrst solve the ﬁrst sub-problem then we will have a limited choice in solving the second one. If we solve the second sub-problem ﬁrst, then we will have the opposite situation. In any case there is a conﬂict between our two subproblems, and they should be solved in a rational way. Probably we will have to make a compromise between these two sub-problems. We can do this if we cooperate while selecting the optimal solutions. For instance we should try to understand the consequences of selecting particular decision variables for both problems and try to satisfy both points of view in a certain limited way. The selection of common decision variables will be known as coordination, and the common work to ﬁnd compromises will be known as cooperation. Designers usually work in teams. This means that people have to coordinate their activities and that they can cooperate while solving their problems. We can easily evolve our example into a case for two designers. Each designer assumes responsibility for his respective problem. Then they solve their problems separately and have different solutions in the decision space. There would then be no coordination. However, they could work with one dominating the other. We have created a privileged situation which would allow the senior designer to solve his problem ﬁrst and thereby dictate his decision variables to the second designer. These situations are presented in Figure 2.7. The two designers could also cooperate and create a common compromise. This could also be done at a distance (Figure 2.8). The designers’work is based on knowledge.Design knowledge can be modiﬁed and can reﬂect progress in a domain. This knowledge can be used by various people. Most people employ some archetypes when applying the knowledge. There are even sets of different archetypes. Moreover, archetypes are domain speciﬁc. They are often created by teams and used by a wider community. However, there are also archetypes which are applied only by a single designer. Anyway, both cases cause problems because for successful communication among designers and to fully understand designers’ work, it is important that all people involved use the same, or at least similar, archetypes.

First designer and first problem

Second designer and second problem Figure 2.8 Cooperation at a distance.

03 25/7/03 09:53 Page 39

3

Survey of Engineering Knowledge Representations

We have learnt from the previous chapters that knowledge is one of the most important components in engineering design. In principle it is its basis. In their work, designers exploit their knowledge sources. They use acquired knowledge, they create new solutions and in this way they gain new knowledge, that is: knowledge exists, is being created and can be re-used. Thus design knowledge is constantly evolving. It is comparable to the process of learning. In most cases, after having ﬁnished a project the designers realise what they could have done better. However, examples show that in daily work-life there is neither time nor resources for the iteration of a project. Understanding the value of maintaining knowledge and because of the constant evolution of design knowledge, concepts to store and re-use the knowledge have been developed. Nowadays the storage and re-use of knowledge is done with the help of computer tools. The overall process of capturing knowledge, modelling, storage, selection and re-use consists of many technical and non-technical factors. First, we want to ﬁnd out what kind of knowledge can be useful during the design process. The problem has been widely explored [17–19, 36, 61, 98, 107, 108].Authors have compiled their results as lists of potential knowledge sources for particular design domains. Some offer even complete frameworks. According to most of the proposals we ﬁrst of all have to analyse what our information sources are. We should then specify the information which has to be stored. After that our decisions are confronted with the reality of personal and ofﬁce contexts. Finally, we must identify those probable and evident information streams which have to be received by our environment. If the potential sources of design information are numerous then often they are categorised according to thematic groups [36]: ● ● ● ● ● ● ● ● ● ●

Libraries of documents and books. Information from patent ofﬁces. Information from research centres. Information from engineering associations. Articles from press, magazines, journals. Information obtained through visits, exhibitions, conferences. Information resulting from personal contacts. Industrial standards used. Company design documentation depot. Information provided by customers. 39

03 25/7/03 09:53 Page 40

40 ● ●

IPA – Concepts and Applications in Engineering

Information provided by suppliers. Internet databases.

Each of the listed items represents a whole host of structured and unstructured information, which is put at our disposal by different media. It is available to us as data sets, text, graphics and in other forms. The typology of [36] is not the only one. Other authors found different categories to which they assigned the sources of information. Ullman [112, 113], for example, decided on the following design classiﬁcation (citation Court [17]): ● ● ●

General knowledge – acquired in life experiences and education. Domain-speciﬁc knowledge – acquired while working with a speciﬁc domain. Procedural knowledge – acquired from experience and concerns about how to perform tasks.

The following systematisation is presented in [17] (Vincenti – citation by Court): ● ● ● ● ● ●

Fundamental design concepts. Criteria and speciﬁcations. Theoretical tools. Quantitative data. Practical considerations. Design instrumentation.

He (Vincenti – citation by Court [17]) thinks that knowledge can be generated by the following activities: ● ● ● ● ● ● ●

Transfer from science. Invention. Theoretical knowledge research. Experimental engineering research. Design practice. Production. Direct trial and testing.

The authors of the MOKA project [57] prefer their own typology of knowledge types in engineering design. Their list is more related to the components and structure of the design process than in previous cases: ● ● ● ● ● ● ● ●

Terminology – glossary of domain-speciﬁc terms with deﬁnitions and illustrations. Product speciﬁcation – considered in wider market context. General constraints – many classes of constraints appearing during the design. Conceptual design – conceptual ideas, principles. Physical design – all aspects connected with giving the product its ﬁnal form. Design rationale – answer to the questions “how” and “why” the design was done in this way. Design process – activities – enumerated activities within their context – during the design process. Design process – techniques – different methods used during the design.

03 25/7/03 09:53 Page 41

3 Survey of Engineering Knowledge Representations ● ● ●

41

Rules – strategic rules, etc. Strategy – concepts for achieving successes expressed in different ways. Associations – connections between different components of the design process.

The classiﬁcations based on the design concepts are well understood by designers. They are very helpful while modelling the design process and while considering its knowledge issues. Before we go any further we have to discuss some basic terms like data, information and knowledge as they take a key position in building software for knowledge storage. Most of the authors [17–19, 34, 36] treat data as a collection of numbers. A collection can be ordered and structured. However, it does not contain comments explaining its sense. We can treat any collection of other non-numerical items as data as well, provided they are not commented on. Data can have related context information; it is then necessary to interpret the data. Take as an example a ﬁeld of temperatures. The context of how the data were obtained is then the information which helps us with the data interpretation. Now we want to have a closer look at the relationship between data and information. Often we observe that these two terms are treated as synonyms. In the literature it is underlined that information [17–19, 36] stands for data and their meaning, or data which are understood. Applying this deﬁnition to our example of the temperature ﬁeld the following happens: information becomes a detailed description of the place, and the way the temperature was measured. All this shows us the context of the whole problem. The relationship between information and knowledge is another important issue [17–19, 36]. In some papers these two terms seem to be interchangeable. However, often researchers and practitioners do not want to accept their equality and look for the differences. Different real-life examples are considered. For instance: a book contains information and when a human reads this book he gains knowledge [17]. Different people gain different knowledge. Thus we conclude that this process cannot be directly steered nor controlled externally. Consequently, when we supply different people with the same information (also known as knowledge) it may lead to different conclusions (i.e., to knowledge which is not uniform). Therefore knowledge is more than only recorded information. In knowledge methodologies we often see the classiﬁcation as formal information and informal information [17–19, 36, 57]. Formal information [36] is information through which all individuals infer the same knowledge. Some authors (e.g., [36]) distinguish three forms of formal information: ● ● ●

Textual (structured) – formal documents, published materials. Pictorial (structured) – for instance, diagrams, 2D/3D drawings, ﬂow charts. Verbal – typically used for descriptions or explanations among individuals in a design team.

Informal information, however, means unstructured information. This can be personal information or information which is the result of an interaction between two or more individuals [36].According to [36] there are ﬁve classes of such knowledge: ● ●

Textual (unstructured) – information is the form of notes taken by somebody. These notes are written in an accepted convention. Pictorial (unstructured) – such as sketches, incomplete pictures, diagrams.

03 25/7/03 09:53 Page 42

42

IPA – Concepts and Applications in Engineering

●

Verbal (conversational) – for instance, a conversation which does not have a clear main topic. Intellectual information – treated as elements within a person. Expression – both physical expression and voice intonation.

● ●

The authors [36] suggest a classiﬁcation of knowledge. They show two aspects of knowledge: the ﬁrst is called the knowledge element, the second, the knowledge process. When an individual makes an inference (in his memory) on the basis of the information and generates a knowledge element, then we call this activity a knowledge process. Not only information is used for inference but knowledge elements as well. Using this classiﬁcation of knowledge components it is easier to distinguish what is mentally being done from that which is the ﬁnal effect of a mental process and can be explicitly represented. The storage of knowledge (elements) and information can be done with various media: text ﬁles, books, ﬁlms, computers etc. With each of the media we associate suitable representations with which we can express our stored knowledge. In the case of books these are words, sentences and pictures. Words and sentences can have a structured form. The reader understands the stored knowledge and can make use of it. We deﬁne “using” as acting on the basis of the stored knowledge. Often we look for knowledge support when we have to solve a problem. In general, the wealth of knowledge stored on different media is relatively immense. For every new problem we need suitable knowledge at a proper time. A special assisting tool (system for knowledge storage, knowledge classiﬁcation and knowledge selection) can help us to ﬁnd it. Software which provides this ability is often called a knowledge management system. Keeping this information at the back of our minds, we return to the group reading the same book [17]. Their conclusions from the content of the book can differ very much in particular cases. There are many reasons for this: the reader’s age, his previous knowledge, his motivation, his education, his mental background and so on. In any case the knowledge gained by reading cannot be immediately transformed into a model which results in unique actions by every reader. However, for a computer implementation the ability to transform knowledge immediately into a formal model is a compulsory condition. To ﬁt this requirement some conditions have to be fulﬁlled. We have to limit and reduce the knowledge to rules, instructions, checklists, etc. because such structures can be transformed more easily into forms which can control computer actions. The last issue leads to a very important classiﬁcation, that of the informal knowledge model and the formal knowledge model. The informal knowledge model means knowledge which can be stored in different media in a form produced by people (texts, ﬁlms, e-mails) and can be perceived only by people. This model places the human who understands and carries out an action ﬁrst, whereas the action itself, based on knowledge, remains secondary. The formal knowledge model means knowledge which can be understood not only by people but also by the computer systems and can trigger computer-controlled actions. Both kinds of knowledge models (informal and formal knowledge) can be stored on computers. Informal knowledge is usually stored in databases as written notes, videos, e-mails, logs of actions done by computer systems, etc. This then can be recordings of human communications or designers’ personal notes. Except for the human notes, all other recorded cases lead to data explosion. Even a simple two-hour

03 25/7/03 09:53 Page 43

3 Survey of Engineering Knowledge Representations

43

tape-recorded interview can eventually result in two days of work to understand its details and context. In the case of e-mails the problem looks even more complicated. Often when we store e-mails on ofﬁce matters or scientiﬁc cooperation we think that they are a perfect source of knowledge on particular subjects. However, when we have real industrial e-mails discussing design problems with geometrical modelling, component indexing and other technical details, and e-mails consisting of about 20 interactions involving the design partners, then we have difﬁculty in understanding what was primary and what resulted from it. At ﬁrst glance the whole problem may be unclear. We can give the design knowledge the form of structured data, ordered according to some considered concepts complemented with comments and indexes. However, this requires additional effort. Several authors call the class of computer systems which are used to store informal knowledge “humanly interpretable” systems (e.g., [69]). These systems are often integrated with other engineering applications and act the role of assistants. They can have the form of web-based repositories of knowledge. Often they are a collection of text or HTML ﬁles. The knowledge stored in these applications has a computer representation which is only understandable to humans. The problem of knowledge sharing among the members of design teams is another issue which is especially essential in the case of informal knowledge. When we consider particular, real situations the problem of context and historical background increases. Let us imagine ﬁrst that the designer–designer communication takes place in a personal meeting in a direct conversation. Probably many small details of mutual observation are taken into account by both persons and are treated as sources of information which help to solve the whole problem. In the case of contact via electronic media information, casual perception is missing. Video and teleconferences could help, but also in recorded and stored video or teleconferences we miss the personal interaction which is so helpful in normal communication. Computer systems which can be controlled by formal knowledge are called “computer-interpretable” systems [69]. Another name for such a class of software is knowledge-based engineering. In this case stored knowledge can be transferred into an engineering system (CAD, CAE) and directly control particular design sub-tasks. The computerisation of design processes is very intensive. There are different classes of computer tools supporting design activities: CAD, CAE, CAM, etc. They do some parts of the design tasks in an automatic way. However, on the other hand they work interactively. It is the designer who interacts with this software. The designer sets problems, estimates results, selects the next tasks and makes decisions. If we want to embed knowledge-based tools into the design process we have to consider how a human designer performs his knowledge-based tasks [19, 112, 113]. The designer uses his own memory [17–19, 112, 113] and information which he has stored in it. This kind of memory is often called long-term memory [17, 113]. Additionally, the designer uses his private external knowledge depot: notes, catalogues, books, former project documentation, etc., popularly called “engineers’ drawer content”, which is treated as a widening of his long-term memory. Sometimes he looks for new information or new knowledge in different available external sources. However, in most cases the actual basis for the problem solving is the designer’s own memory. Processed information is taken directly from the brain. How this happens is still not entirely known.

03 25/7/03 09:53 Page 44

44

IPA – Concepts and Applications in Engineering

Besides long-term memory there exists a so-called short-term [17, 113] memory. If we can say that the long-term memory has an unlimited capacity, then the shortterm memory has a limited capacity which does not go beyond seven knowledge chunks. Short-term memory allows direct and fast cooperation with the knowledge chunks stored there. For more complicated problems, cooperation with the longterm memory becomes necessary, which involves more time. We want this as our model of the way designers solve their problems. This model is simple but it helps to show the double role of notes taken by designers. First, these notes function as a widening of the short-term memory and are used to discuss an already solved problem as it is too complicated for mental modelling. They are a source of information for strategies of problem solving used by the designer. Secondly, these notes function as a widening of the long-term memory. They can be prepared with this intention or they are simply notes taken while problem solving. In this case they can represent the history of the supplementation of short-term memory. The main problem for potential knowledge-based system developers is to ﬁnd a mapping from their particular problem characterised by several features concerning the structure of the developed system for design knowledge storage and management. The problem is multidimensional and generally not easy. Analysing the state of the art of knowledge-based systems in engineering, we see that there are some theoretical concepts, formalisms, frameworks, methodologies and computer tools. Some implementations are also known. One of the ways to solve the problem is to employ one of the proposed frameworks. Above we presented concepts which are used for knowledge classiﬁcation. After making a classiﬁcation of our own knowledge sources we can select tools for knowledge storage and capture. From these tools we have to choose those which are suitable for our knowledge and its representations. Now we want to concentrate on systems which belong to the “computerinterpretable” group. Mostly they are based on expert systems technology integrated with object-oriented approach and engineering software (CAD, CAE). They use knowledge representations similar to those applied in expert systems. They are classiﬁed according to problems which can be supported by them [69]: ● ● ●

Generative systems, which create geometry or another formalism on the basis of initial data speciﬁcation, rules and constraints. Advisory systems, which evaluate designed components or assemblies. Innovative systems, which can generate structures realising prescribed functions.

Hybrid approaches can often be met. The basic knowledge representations used in engineering systems are categorised as follows: ●

●

●

Procedural knowledge, which can be modelled as an algorithmic procedure with a clear beginning and end. All the steps in between are explicitly formulated. This is a standard approach in procedural programming languages. Declarative knowledge, which can be represented in a form speciﬁcally for artiﬁcial intelligence tools (rules, semantic nets, frames and object-oriented approaches), especially for expert systems. Descriptive knowledge, which can be stored in typical descriptive forms (text ﬁles, etc.) produced by experts.

03 25/7/03 09:53 Page 45

3 Survey of Engineering Knowledge Representations

45

Let us consider declarative knowledge [34, 42]. Rules are the most often-used knowledge representations. Rules consist of two parts: left-hand side (LHS) and right-hand side (RHS). The LHS is a set of conditions which are interconnected via logic operators. The overall structure of the conditions can be evaluated. This procedure consists of two stages: (1) giving the value true or false for a particular condition; (2) considering the sets of conditions connected by the operators AND, OR and the true/false evaluation. The RHS consists of a number of actions which are carried out if the LHS gives the value “true”. In our ﬁrst simple example, if fact A is true then action B shall be done. We can write this in the following way: If (A is true) then (do action B). Let us assume another situation: we have two facts (C and D); when both are true then action E shall be initiated: If (C is true AND D is true) then (do action E). Obviously the set of conditions on the LHS can have a more complicated structure created with the help of logic operators and basic conditions. An example of an LHS could be (F is true OR G is true) (H is true OR (I is true AND J is true)). Using basic conditions and logic operators it is possible to compose different structures. Each of these structures can have the value “true” or “false”. However, the rules must express real existing knowledge. With the help of basic conditions and logic operators we have to model real-life conditions which should be fulﬁlled before actions which are in the RHS are taken. Rules in real technical problems solved with the help of computer tools can have the following forms.

Example 3.1 (continuation of Example 1.5) We want to model toothed wheels in a CAD system [92]. Our toothed wheels have several basic parameters which are the effect of the basic calculations according to the standard approach. However, if we want to build a geometrical model of toothed wheels we have to calculate or infer many geometrical parameters which are needed to define the complete 3D model. We can integrate our basic parameters with formulas which can calculate step by step the resulting parameters. The sets of the calculated parameters are the direct inputs of a parameterised geometrical model in a geometrical processor. As shown in Figures 3.1 and 3.2, we can create different geometrical models of cooperating toothed wheels for different sets of initial values.The knowledge stored in this case belongs to the procedural category. We can also work in a wider design context, where we do not regard the toothed wheels as isolated elements but as parts of a gear

03 25/7/03 09:53 Page 46

46

IPA – Concepts and Applications in Engineering Procedural module: Interface from code supporting toothed-wheel calculations in gear box

Comments created by designer

Database of calculated cases

History tree for procedural calculations

Comments generated automatically by system

Reports with results of calculations and comments

Figure 3.1 Modules supporting toothed gear design calculations: procedural and descriptive.

box, for example. Then we can think of integrating some of the toothed wheels with friction multiple-disk clutches; and we also set the sizing of the clutch to be done in correlation with the parameters of the toothed wheel.This is an example of declarative knowledge. While doing an engineering project designers make decisions. The background to decision making is understood by designers. It is very useful to have the possibility to add to the project documentation notes (i.e., information about the background to the decision). As the project documentation can be very rich, the best solution is to place the background information in a suitable context, connected to

03 25/7/03 09:53 Page 47

3 Survey of Engineering Knowledge Representations

Basic initial parameters of toothed gear

47

Database of calculated cases

............................. ... Parametric formulas for toothed wheels

Parametric and knowledge-based models

Complete assembly Figure 3.2 3D knowledge-based and parametric modelling of toothed wheel and clutch – declarative and procedural knowledge.

a specific component and to a specific step in the component history tree. In our example the whole system is developed to support car gear box design. The user can store in it different variants of selected geometrical parameters of particular gears of a gear box. Each design variant can be commented on by the user in a combined way: partially automatic and partially manual. The information about the interpretations of values of calculated parameters is reported automatically. In general, for eight pairs of toothed wheels (the whole gear box) this is no trivial task. The remaining data are comments made by the user.This is an example of descriptive knowledge.

Example 3.2 (continuation of Example 1.6) Rule-based knowledge representation is not only useful in the case of geometrical engineering problems. It can also be applied to building other models as well [74, 85]. Let us assume that we have a geometrical model of a piping system and we want to build a fluid flow dynamics simulation model of the fluid in this system. Let us also assume that our geometrical model is done with the help of a system used for isometric piping systems modelling (Figure 3.3). For the simulation of fluid flow dynamics problems another system is used

03 25/7/03 09:53 Page 48

48

IPA – Concepts and Applications in Engineering Knowledge base: Rule 1

……… Rule i

………

pipe

link cell link

Rule n

Geometrical model of piping system with physical data Reduced Figure 1.23 P. T.

Inference module

Fluid network model

Figure 3.3 System for ﬂuid ﬂow dynamics analysis – knowledge-based processing.

where we have to prepare a special model of the fluid and the simulation task (this example is presented complete in Chapter 5). The simulation model has several basic objects.The fluid is modelled as a network of connected cells and links. The cells represent the modelling mass, the capacity and energy.The links represent the modelling flow resistance, etc. Now we want to explain the knowledge chunk which enables us to map a geometrical model into a model of fluid flow dynamics. For instance, taking a pipe we can model it as a cell with a corresponding capacity and other parameters.The flow resistance in the pipe we can model as links connected to both ends of this

03 25/7/03 09:53 Page 49

3 Survey of Engineering Knowledge Representations

49

cell, having in common the flow resistance of the whole pipe. Then our rule has the form: If (element is a pipe) then (create cell with two links connected to its ends) (calculate suitable parameters of cell and links). The rule contains procedural components as well. If we want to model the whole of the knowledge needed to create a fluid flow dynamics problem on the basis of a piping system, then we need rules which directly transform all objects of a geometrical model into objects of a fluid model. In addition to the geometrical data of the piping system we also need the physical parameters of the simulated phenomena; and as a further knowledge layer we have to create the rules for the resolution of the model conflicts. Another very popular representation which is used in engineering applications is the object-oriented approach [15, 104]. It enables us to model real-world situations as abstract classes, where the classes are deﬁnitions of objects. When we have a well deﬁned class it is possible to generate a plurality of named objects. The classes can be different and reﬂect different real objects and phenomena. Among the classes we can create inheritance dependences. Inheritance is a very useful mechanism. It means one class can inherit from another one so that we are able to build hierarchies of relationships and exploit the mechanism of multiple inheritance. Multiple inheritance allows a class to inherit from all classes which are above it. This mechanism is especially efﬁcient in the case of large problems with detailed and speciﬁc sub-structures. When building a concept of class we deﬁne its slots and facets. The slots are the ﬁelds for storing information. The slots contain information about the attributes of objects. The features of each slot can be precisely prescribed. The information about particular slot characteristics is stored in the facets. It can be default values, for instance. The above description of the object-oriented approach concentrates mainly on its static aspects. But we may add actions to that concept, meaning that the classes can be equipped with message handlers. The message handlers carry out actions. It is possible to build message handlers for each class. Each message handler has to take a speciﬁc role. Message handlers receive messages and act appropriately on them. A plurality of message handlers connected with object functioning can be created. We determine when particular message handlers have to act. The object-oriented approach is very useful in technical problems.We can use an object representation for structuring the product. In this case we build for each geometrical primitive a corresponding object-oriented model. Our model can be developed in various directions. We can create different instances of the existing object by changing its structural features. We can operate with it via message handlers. We can develop a modiﬁed sub-class of the existing class. Object-oriented models are useful in the case of standardised models, because then we can integrate our model with a database of parameters from existing designs, as the geometrical model is produced on the basis of parameters stored in the database. The characteristics of the model are calculated, and inferred in an object-oriented approach.

03 25/7/03 09:53 Page 50

50

IPA – Concepts and Applications in Engineering

Sometimes it is sensible to join a rule-based approach together with an objectoriented one. Then the rules can be ﬁred because of the existence of objects with speciﬁc features. Rules can modify, delete and create objects, and can activate message handlers. Today many of the above concepts can be realised directly in knowledge-based engineering environments, provided that they offer the integration of geometrical processing with a knowledge layer (see Example 3.1). However, in this case we are often limited to a particular knowledge-based engineering system. It is quite sensible, however, to develop knowledge models in more neutral environments and later transfer them as a knowledge layer to different knowledge-based engineering systems. This approach is especially fruitful if we have to cooperate with CAD systems belonging to very different classes of software.

04 25/7/03 09:53 Page 51

4

Survey of Intelligent Personal Assistant Software Concepts

In the literature we come upon software concepts which are developed for engineering knowledge storage. The authors consider the personal issues of their approaches. Most of the systems are domain speciﬁc and built with the intention of sharing individual knowledge and expertise. Numerous authors in their research arguments favour a personal approach to engineering knowledge storage [17–19, 28, 29, 112, 113, 118]. In most cases the paper design notebook unites two roles: ● ●

It is a tool for design process information storage. It is a tool for concept development.

Often, additionally, users keep in their notebooks their argumentation together with its important knowledge background. For us, most signiﬁcant is the variety of ways designers do their tasks. A strong inﬂuence of subjective and personal factors becomes obvious. If we add knowledge which always stays behind every design decision we see the importance of the personal, subjective aspect of design knowledge. Most of the design knowledge has such roots. When we look closer at the particular software implementations of a design notebook, we notice that they differ in various concepts [12, 86]: ● ● ● ● ●

Main development goal and assumed design process model. Implemented basic data structures. Higher level data structures. Set of preﬁxed functions, sub-tasks. Knowledge-based tools implemented in the system.

Let us describe certain implementations. The system presented by Dybala and Tecuci in [25] was developed as a learning-oriented tool. It can integrate problem solving with knowledge acquisition. The main goal of the research was the integration of the process of problem solving together with knowledge capture and learning on the basis of solved cases. The model of cooperation called Shared Expertise Space describes the interaction between the designer and the knowledge-based notepad (named DISCIPLE-3). In the cooperation model the designer has to insert several problems and their solutions into the system at an early stage. On this basis the system makes attempts to learn by itself. After inserting an adequate number of data the system is able to 51

04 25/7/03 09:53 Page 52

52

IPA – Concepts and Applications in Engineering

develop solutions of routine tasks within a speciﬁc domain. The system was developed and tested on conﬁguration problems. The cooperation with the system can be done in two ways: (1) the user presents his problem to the system and the system makes the evaluation on the basis of problems solved earlier; (2) the system creates solutions which are generated from the stored examples. The knowledge in the system is stored in the form of frames, hierarchical structures and rules. The developed system was tested on the conﬁguration problems in which the ﬁnal product was created from several available components. In the example shown in [25], a computer conﬁguration was built according to the users’ needs and preferences. The knowledge needed for this problem is partly heuristic and partly procedural. The component data were stored in frames. The frames contained the knowledge necessary for connecting the components. The frames were also sources of information for procedural calculations. Knowledge acquisition could be performed in numerous ways. If while problem solving the system had difﬁculties with processing, then it “asked” the user and generated new rules based on his answers. Other possibilities were the generalisation of accepted solutions, the narrowing of the search space, and the reformulation of rules. According to the authors the greatest advantages of the system were: (1) design process support; (2) integrating design with learning; (3) automatic knowledge capture during the design process. As disadvantages, the following issues were mentioned: (1) slowing down the designers’ work while capturing knowledge; (2) limited system services in the case of rules with different certainty factors; (3) limited possibilities of modifying stored solutions of problems given by the experts. From the description of the system we can conclude that the overall approach was machine-learning oriented. The authors put little effort into the problem of integration with other engineering and not-engineering software. The example problem conﬁguration has rather limited dimensions and it is not certain whether in the case of wider problems the proposed methodology will be easy to transfer. Clarkson and Hamilton [13, 14] describe the conception of the personal assistant. It was applied to projects in aircraft design. Its main goal was to collect experience, and store and evaluate activities taken during the design process. In this system the user is directed to the tasks according to the knowledge, based on possible activities and context information. The described system consists of four layers. All the parameters essential for a project are placed in the lowest layer (each parameter is connected with its own meaning, certainty of accuracy, connections with other parameters and possible physical interpretations). The second layer contains all tasks connected with a particular design process. Each task has a list of input/output parameters from the ﬁrst layer. A particular task can be performed when all the values of input parameters are deﬁned. The next layer is a process layer. In it the strategy of the overall problem solving is presented. The fourth and highest layer of the model is an interface level. The whole approach was developed for single designers or for small teams. The presented approach reminds us of a maze model developed in [9, 10]. Tasks and processes are modelled as a system of nodes and links. This way of seeing the problem is common among industrial designers. The implementation developed by the authors was made in the expert system shell Goldworks III. The software was built in cooperation with the industrial partner GKN Westland Helicopters Ltd.

04 25/7/03 09:53 Page 53

4 Survey of Intelligent Personal Assistant Software Concepts

53

The results of employing the mentioned software for solving real-life problems are very interesting. There were two groups of designers who tested the software, (1) experienced and (2) inexperienced. The test proved that the proposed approach had relatively little inﬂuence on experienced designers. In the case of inexperienced designers its inﬂuence was more signiﬁcant. In the papers by Yang and Cutkosky [116], and Hong et al. [38, 39] we ﬁnd a new kind of computer tool for designers. The tool is a computer notebook with information about the project. The information is stored in the form in which it was created, together with the whole unﬁltered project history. This information is the only source of circumstances which led to speciﬁc decisions. The notebook can exist in parallel with formal documentation. The electronic notepad called PENS (Personal Electronic Notebook with Sharing) proposed in [39] is internet based. The data in the application has the form of text notes. The user has to enter his data in this form and then he has to decide which data can be shared via the internet with other team members. The notes chosen are sent by an e-mail to the server and then automatically published on world-wide web pages. The authors in [116] mainly focus on searching data for indispensable information. The data do not have any speciﬁc structure. The data structure can be created by hand or automatically, but the authors concentrated on the automatic solution and used PENS [39]. They created an algorithm to index a text by splitting it into smaller blocks. The software tools presented in [39] and [116] are relatively universal. Particularly interesting is their high efﬁciency due to the proposed automatic indexing system. Unfortunately this system can only handle text note data types. It cannot handle project variables. Hildre [37] came to an interesting idea of a notepad for conceptual design. His notepad is paper based. In spite of their fast evolution, CAE tools are not able to replace a sheet of paper at the different stages of preparation of a project. Hildre’s notepads allow sketches and notes to be prepared fast and independently from all computer data, which is especially convenient in the conceptual phase where the freedom of product creation matters a lot. Later all the details of a product composed on paper by different designers are collected and then transformed into 3D and other computer models. According to [37] all the designers who want to work together on the same project have to assemble their work. The main idea of this work was to use a paper notebook with a special structure (Structured Notebook). This A3-size notebook is clipped with a binder which allows the user to insert and take out single sheets. Each sheet contains the designer’s personal details and provides a special place for a tree-level hierarchical classiﬁcation. The sheets are divided into four main sections: ● ● ● ●

Aspect views, which includes all matters concerning functionality. Product life views. Synthesis views, which includes functional reasoning, ideas, solutions, principles and evaluation. Building method views, which is the layout of the design.

The ﬁrst three views are kept private for each team member. However, when the documentation of the whole product has to be consolidated, problems appear because different sheets from different designers may show different views of the same part of

04 25/7/03 09:53 Page 54

54

IPA – Concepts and Applications in Engineering

the project. Then the sheets have to be put in proper order to make the project understandable. After that the building of computer models can be initiated. Another problem appears when one sheet has to be assigned to more than one section. As a possible solution the necessary number of copies of each sheet can be made, but when adding new data we may lose consistency. Regardless of these handicaps the Structured Notebook was put into practice and gave measurable proﬁts. The designers’ sketches and notes gained order and the time for the creation of computer models was reduced. According to Werner et al. [114, 115], the storing of knowledge, however, is far from perfect. The engineering/product data management (EDM/PDM) systems are able to trace document ﬂow, changes in drawings, models and documents but an automatic knowledge acquisition with the use of these systems is impossible. During his work the designer usually creates some alternative solutions, develops them and ﬁnally rejects some of them. These alternative solutions, their quantity, quality and the reasons for their rejection are part of the designer’s personal experience. Surely, the recording, storing and suitable organisation of such eliminated solutions could be very useful for future projects. According to Werner and Weber [115] the best moment to acquire knowledge about design is the design process, especially when the knowledge acquisition is automatic. This assumption was pursued in [115] with their proposed Ligo system. Werner et al. [114, 115] see three main stages of a project process: ●

● ●

Generation of new ideas with the special consideration for reasons of their creation, differences, advantages and disadvantages in comparison to other similar projects. Evaluation of these ideas, taking into consideration how they ﬁt for their requirements and what kind of difﬁculties they could cause at the production stage. Selection of one ﬁnal idea from all the alternatives.

The building of alternative projects in the Ligo system is based on the use of project objects. A project object contains information about a particular detail, the description of its behaviour and the interface with other objects. Design objects can be connected to each other like a semantic network. The connections between the objects are relationships like:“is a special case of ” and “is caused by”. Other objects like documents or contacts with people can exist simultaneously with a design object. Each object has its own methods and triggering procedures. The methods are intended for viewing, editing and connecting it with other objects. The procedures are triggered in order to use, edit, delete or create an object. The procedures triggered create the history of uses and changes of the design object. This history is a documentation made simultaneously to the design process. The main advantages of the system are: ● ● ●

Knowledge acquisition in the background of a design process. Complete and well-prepared process documentation ready for automatic processing. Designs which are modelled in Ligo can be re-used.

Another example of an intelligent personal assistant class software is Finite Element Modelling Assistant introduced in Fenves [28], and Turkiyyah and Fenves [111]. According to [111] getting good results from ﬁnite element programs requires from the user an interaction with the system on a relatively low, primarily

04 25/7/03 09:53 Page 55

4 Survey of Intelligent Personal Assistant Software Concepts

55

numerical level. The authors of this paper, experts in the ﬁeld of building computational models for ﬁnite element methods, attempted to create software which allows models to be prepared not only on a numerical but also on a physical level. In this project the user’s task is to provide a high-level problem description: the properties of the examined object, the description of loads, the assumptions for building the model and the required accuracy. The modelling assistant can apply an appropriate modelling assumption from a high-level problem description to make necessary decisions about element types, element properties, loading conditions, mesh size and gradation, boundary conditions, and solution procedures, and it can ﬁnally prepare the appropriate input data. In the end the modelling assistant tool can abstract and evaluate the output which is typically produced by ﬁnite element programs to produce a high-level description of the model behaviour. The knowledge in [28, 111] is represented using “assumptions”. Every “assumption” is built of a declarative and a procedural part. The declarative part describes for which models and under what conditions it can be applied and when it can give reliable results. According to these declarations the program can choose proper assumptions to prepare a speciﬁc model. The procedural part of an assumption contains procedures which can generate or modify a ﬁnite element model. First the most suitable assumptions for a speciﬁc model are chosen and then all their procedures are applied to the model. This process is applied iteratively. In each iteration the ﬁnite element model is improved. This method was tested on building models in the ﬁeld of civil engineering. From this survey on intelligent personal assistant software [12, 86, 118], we can draw the following detailed and global conclusions.

Detailed Conclusions Publications show the need for constructing software which can assist the designer with his work. The main goals of this software are: to acquire (informal and formal) knowledge from the expert, to offer the possibility to prepare routine tasks automatically on the basis of recorded knowledge and to prepare knowledge for re-use. It is relatively difﬁcult to develop universal software in the form of an intelligent personal assistant.

Global Conclusions When we look at the problem of knowledge-based systems from a distance, we understand that it is often an attempt to integrate the classic symbolic approach of artiﬁcial intelligence into certain models, in many cases spatial geometrical models; and nearly always the structure reminds us of the standard inference model. The symbolic representation takes the role of an indexing system for the design process model. In the case of intelligent personal assistants a symbolic representation is created by the designers (or under their control). If the knowledge which is stored in the intelligent personal assistant is very standard, such a system tends to become similar to the concept of a design repository. If the knowledge is more subjective,

04 25/7/03 09:53 Page 56

56

IPA – Concepts and Applications in Engineering

however, its context knowledge gains importance and therefore it is best understood by the person who delivered this knowledge. In this case the system functions as a personal notebook. With the personal notebook we obtain the following positive effect: the user, or owner of the notebook, is motivated to care about its content. Designers usually work in teams and they also have to cooperate with people from other teams. This is one of the ideas of concurrent engineering.We believe in the idea of integrating intelligent personal assistants via links into ﬁrm design repositories. In this case ﬁrm design repositories contain routine knowledge and links to very subjective personal knowledge sources with a special apparatus which organises the codiﬁed knowledge access. As an additional tool we can imagine context knowledge sources (with information about a professional biography of human knowledge sources) which support the classic ontology approach – explaining differences connected with context knowledge in different personal knowledge sources.

05 25/7/03 09:53 Page 57

5

A Common Model of an Intelligent Personal Assistant Concept

In the previous chapters we learned about the nature of the design process. We directed our attention to the components of this process and to the different forms of modelling design activities. In this chapter we want to go into the details of the software concept which is intended to accompany the designer in his work. We call it the intelligent personal assistant. Our concept of an intelligent personal assistant is based on the assumption that the system will follow the ideas of the maze and optimisation models of the design process (Figure 5.1). In addition, we now have the concept of case-based reasoning. Product and process modelling is a routine activity for persons who create environments for supporting the design process. Assumptions made in the model have signiﬁcant consequences for that which can be done later in the implemented environments. The abundant literature concerning product and process modelling is mostly based on the observations of human designers. The maze model is one of the concepts of models of the design process [9, 10, 12, 80, 83]. In a maze model the designer can start the process of designing from a set of nodes. The way he moves in the maze is very individual and he can ﬁnish designing each time in a different node. The maze model which is a reasonable but idealistic concept always needs some kind of knowledge support which generates the missing data and solutions on the basis of the existing knowledge. The process of moving from one node to the other in the maze requires testing to determine if all needed data really exist. If not, a special procedure is initiated and the missing data are created. This can be done by the designer personally or by computer modules. The maze model is a system of nodes connected by links. Every node stands for an important activity (Figure 5.2).Activities can be procedures of some model generation or analysis for example. The connecting links represent the possibility of moving from one activity to another. The maze model has an open structure so it can be easily modiﬁed. The design process can be initiated from different nodes. It can go via feasible paths, and it can ﬁnish in different nodes. New nodes and links can be added to the system (Figure 5.3). Nodes and links which are not needed any more can be removed. The actual state of the maze can be stored as a plan (Figure 5.4). The stored plans can be loaded.We can store plans which were used in any earlier design process.When we solve a design problem our corresponding design process is realised in the actual maze structure. We can exploit the available nodes and links. The design process realised can be stored as a path in the structure of the maze model. 57

05 25/7/03 09:53 Page 58

58

IPA – Concepts and Applications in Engineering

Multicriteria optimisation module

Maze model structure

Case-based reasoning

Repository of realised paths–cases

Figure 5.1 Maze model together with multicriteria optimisation module and case-based reasoning module.

Node

............. – – – – –

Figure 5.2 Node and its links.

Commercial applications Computer codes Rules Comments Associations

05 25/7/03 09:53 Page 59

5 A Common Model of an Intelligent Personal Assistant Concept

59

Figure 5.3 Editing the of maze model (adding or removing nodes).

Different versions of maze

ith version of maze

time

............. Paths realised in ith version of maze

............. Figure 5.4 Versions of maze structure.

05 25/7/03 09:54 Page 60

60

IPA – Concepts and Applications in Engineering

As a result a maze model reﬂects the state of knowledge about a particular class of problems solved by a particular designer. It is a kind of map where the nodes represent important activities and the links are sensibly used connections between them. As mentioned above, our maze model can be modiﬁed. New nodes can be added, new connections can be created and old ones can be removed. However, this implies that we have to uncover the history of the maze model. There are two possible variants (Figure 5.5): ●

The structure of the maze model used can be changed gradually according to the developed domain knowledge. For that we have to store each of the modiﬁed versions of the maze model if we later want to analyse previous design Variant with possibility of removing nodes

time

Variant without possibility of removing nodes

time

Figure 5.5 Two structures of maze model.

05 25/7/03 09:54 Page 61

5 A Common Model of an Intelligent Personal Assistant Concept

●

61

process cases (Figure 5.5). We have to take care that we connect the proper maze structure with the path of the design process which was realised in this structure. The maze model structure can be changed gradually according to the developed domain knowledge under the condition that we add only new components (as in the history). Consequently the current state of the maze model structure contains all the components which the maze held in the past and all the knowledge history stored in our plan.

The author tested both variants. Their assessment depends largely on the way we want to use the maze structure model. If we often return to past design process cases, then we will probably favour the second version. If we concentrate on the ﬁnal state of the maze model structure and the overall structure is also relatively large and complicated, then we can separate the current version of the maze from the previous version. If we refer to the history often, then it would be convenient to have the possibility of free movement within the maze structure. This is the problem of storage capacities. The second solution is a compromise. It has some ﬁltering proﬁles which can specify what range of the history should be available as short-term memory (e.g., a class of projects realised in the past). The possibility of seeing and returning to a maze model from the past is appreciated by users because they can go back to their former system structure which they used to solve the particular problem. Let us look at an example.

Example 5.1 (Continuation of Examples 1.6 and 3.2) Introduction This example presents the history of one application development [4, 53, 73, 74, 79, 85, 87–89]. As a suitable application we decided on a system which supports the design process of a piping system (it is the full presentation of the system shown in Example 1.6).This specialised system consists of two sub-systems: one models the geometry of the piping system and is connected to a second one which analyses the fluid flow dynamics problem in the system.The generator of the fluid flow dynamics model is a knowledge-based system.The whole system exists in several configurations. The evolution of the described software took about ten years (1989–99) [85]. We can make out three stages in the overall development of the application. The first one had an industrial focus. It was done in a software firm and was carried out in three versions.The main ideas developed at that time (1989–90) were based on the way industrial engineers worked, how they solve their problems and how they cooperated with each other. The second stage (1993–94) was scientific research for which the software of the first stage was equipped with a more sophisticated tool: the blackboard architecture [79]. During the third stage (1997–99) a specialised knowledge-based application for supporting the design of a heating system in detached family houses was developed [88].These three stages are described in detail below.

05 25/7/03 09:54 Page 62

62

IPA – Concepts and Applications in Engineering

System Development First Stage (Industrial Focus) The development was initiated in 1989.The software firm had its own system for the geometrical modelling of piping systems (so-called isometric modelling). The software cooperated with different specialised modules, like particular databases of standard components for example.The software was developed in cooperation with a small group of customers. By analysing the clients’ handling of the problem, the requirements of the software, which was meant to calculate the pressure drops in the piping system, became obvious. The software firm started with the geometry of the piping system to which the user later could add his physical data and then get the pressure distribution in the piping system. Although several formal approaches were considered,none of them was implemented on computer. Therefore a system for the simulation of fluid flow dynamics, based on cell formalism [4], was selected. The fluid was modelled as a network of connected cells and links. The cells were modelling mass, capacity and energy. The links modelled the flow resistance. The system had a special problem-oriented language for the modelling of fluid systems and fluid simulation problems. The system analysed the modelled problem and provided a huge number of results in the time domain (e.g., fluid flow, pressure in a particular cell, etc). As the model of the fluid piping system had to be created by the user, a graphical editor was built where the nodes (cells and links) were shown as an integrated network (first version of environment). The whole model was presented in 2D space. It was possible to add new cells or links and edit an existing network. Every node had numerical parameters, which were accessible via special windows. Special functions supporting the modelling branches and special functions for the visualisation were developed (the zoom function was most advantageous). In general the considered class of models had a size of 100–200 nodes. Thus the direct connection between the system and the simulation system was completed. A module for the graphical presentation of the results was built separately. Unfortunately the examination and evaluation of the prototype version revealed that the system was too demanding. Therefore the software firm came up with the idea to integrate the whole system with the system for geometrical modelling and to offer automatic model generation of the fluid flow dynamics. As a result the project was continued as a knowledge-based application (second version of environment). The expert system was filled with the knowledge of how to transform a geometrical model with some physical data into a fluid flow dynamics model. About 60 rules

05 25/7/03 09:54 Page 63

5 A Common Model of an Intelligent Personal Assistant Concept

which could support the model transformation were created. The geometrical model additionally had to be supplied with physical data like pressure, flow, temperature, etc. A special editor supporting the modelling of physical data, as values connected with geometrical primitives, was developed. Some data were generated on the basis of an algorithmic approach, for instance flow resistance calculations for different structures such as bending and valves. Rules deciding what is processed in which part of the piping network were also created. The expert system shell was fully integrated with the rest of the system. This newly developed knowledge-based module could create a dynamic model of fluid which was in 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 located anywhere in the network or diagrams and animations made on an indicated path in the piping system. The whole newly built system was tested on different examples. The test versions of the system were given to several users. However, not every simulation was successful. Soon new ideas appeared. For instance, a module based on some of the rules supporting the process of repeating a simulation was built additionally (third version of environment). The effects of these analyses were once again presented to the user. Either a place with a data error (errors had to be corrected manually) or suggestions for a new simulation with newly corrected values of simulation parameters (this could function automatically) were indicated. The industrial application finished at this stage.

Second Stage (Scientific Approach) The next stage of the system development was based on a more scientific approach. The author found it interesting to develop a module which searches for the reasons for simulation failures. He created a module which analysed the whole trace file of the simulation. It calculated distributions of different variables, their mid-values and variances; and knowledge concerning the phenomena patterns in the whole piping network was acquired. This knowledge dealt with basic values and calculated functions based on these values. In the case in which the simulation was not successful the system proposed that the parameters be altered and the calculations repeated. The system obtained information from the trace file of the simulation.The content of the file was filtered and the values of state variables were classified. The new measures of distribution were calculated. Finally, all data were placed on the lowest level of the blackboard.The different knowledge sources (i.e., expert systems) were also connected to the blackboard. There were two classes of knowledge sources: (1) analysing separately

63

05 25/7/03 09:54 Page 64

64

IPA – Concepts and Applications in Engineering

single variables, like elevation, pressure, temperature, mass flow, energy flow, heat energy flow; (2) analysing “abstractions” resulting from different kinds of variables and suggesting corrections of the model.The first type of knowledge source analysed,for instance,the temperature over a certain range of time for every node.It looked for specially prepared and remembered patterns of every node and pairs of nodes. Information resulting from this process was placed on a higher level of the blackboard. After that, knowledge sources analysing “abstractions”looked for some known phenomena on the basis of the information from the first and the second level of the blackboard.Their conclusions were the basis for model corrections and for the next, new simulation.The knowledge sources which triggered the conditions were based on the maximal ranges of state variables.The echo of the blackboard inference process was shown on the screen in an alphanumeric way. Only the final suggestions (i.e., placing of error, sensed phenomena, suggested action) were presented in a graphical way.They could be accepted or corrected by the user.This was the fourth version of the environment.

Third Stage (Customised Approach) At the end of the 1990s a scientific project was carried out which dealt with intelligent design techniques in civil engineering. As a result, software for the intelligent support of heating system design for detached family houses was built. A specialised editor for modelling houses in 2D (with the possibility of transforming it into 3D) completed the software which had been developed earlier.The module for the modelling of houses allowed us to add a module for the modelling of the heating system installation. A set of objects typical of heating installations was created. We developed software modules which correspond to the following activities: selection of type of heating system, configuration of heating system components, estimation of energy transfer through the building, simulation and evaluation of newly created design. To begin with, the preferences of the future user of the heating system had to be discovered. For that purpose a special control module was developed.When the preferences were evaluated the control module activated further modules to initiate a more precise formulation of the simulation problem. Afterwards the control module prepared a set of simulation problems. The information generated by the simulation problems can be of interest to a specific client with an individual profile for using the heating system in a defined house and its placement with the prescribed accuracy of the calculations. Later the system conducted a simulation process and stored its results. Finally another module estimated the quality of the modelled variant of the system. The module for the simulation of flow and heat phenomena in the heating installation had as input data the geometrical description of

05 25/7/03 09:54 Page 65

5 A Common Model of an Intelligent Personal Assistant Concept

the heating system and the physical aspect of a particular simulation. As a result we obtained the temperature of every room and the energy flow in the time domain.This was the fifth version of the environment. The description presented above shows the core of the problem which was used for the testing of a developed example maze structure. All versions of the environment were done by the same author. Every version had a form of a set of integrated applications where each of them could be treated as a single activity. It was possible to do an analysis with every version and store results.Then, we had a collection of the design environment states together with sets of problems which were solved at different states. However, when the history of the application became abundant, then returning to former examples from former states was not trivial. This software structure was used as a test problem for our maze model concept. The implementation of the maze model [81] was built in CLIPS [15] environment. The maze model structure was modelled as a system of integrated nodes and links. Nodes and links had their identifiers and they were modelled as templates.They were simply named, multifield data structures with named fields. The maze structure consists of nodes. The node of the maze was implemented as a template with the following list of slots (fields): ● ● ● ● ● ● ● ● ● ●

Identifier of the environment version. Name of node. List of connections with input nodes. List of connections with output nodes. Name of application which is activated in this node. List of input data for the application. Name of knowledge-based system which supports the missing data generation. Name of knowledge-based system which tests input data quality. Name of knowledge-based system which supports the designer with the next step of the design process selection. List of paths (stored in the case-based reasoning library) which go through this node.

With the help of the above structure it was possible to model different historical stages of the maze model. Only one variant with an increasing number of nodes was implemented. The system had the following data as input: ● ● ●

Complete model of the maze structure. List of used applications in the design process. List of connections between applications.

65

05 25/7/03 09:54 Page 66

66

IPA – Concepts and Applications in Engineering ● ●

Lists of design variables connected with particular applications. Modules supporting particular applications: – knowledge-based system which supports missing data generation; – knowledge-based system testing input data quality; – knowledge-based system supporting the designer in the next step of the design process selection.

The data mentioned above decides the type of system functioning model. Figures 5.6–5.10 describe the five stages of the maze model structure for the fluid flow dynamics analysis system. In Figure 5.6 we see the state of the whole environment in its initial stage. Figure 5.7 presents the second stage and Figures 5.8–5.10 the remaining stages. We want to consider particular design processes which were developed in our environment. The paths, which are sequences of steps, are stored together with comments and information about earlier stored data.Through this every design process realised by the designer obtains its corresponding data structures. Next, we can return to the processes which were exploited earlier and connect activities, computer codes or commercial applications to the maze model as new nodes (Figure 5.11). The maze model is quite useful with essential problems in conceptual design. It enables the designer to restart quickly processes from the past and to build processes with comprehensive structure. As mentioned above, moving in the maze model has both an operational and an inference (knowledge-based) aspect. While moving in the maze model the designer has to make decisions; what to do next, 2D editor Alphanumeric modeller

Simulator

Graphical postprocessor

Alphanumeric postprocessor Figure 5.6 First version of environment.

05 25/7/03 09:54 Page 67

5 A Common Model of an Intelligent Personal Assistant Concept

67 2D editor

3D editor Alphanumeric modeller

Fluid dynamics problem modeller

Fluid dynamics model generator

Model examination

Simulator

Graphical postprocessor Alphanumeric postprocessor Figure 5.7 Second version of environment. 3D editor

2D editor

Alphanumeric modeller Fluid dynamics problem modeller

Fluid dynamics model generator

Model examination

Simulator

Diagnostic module

Diagnostic decision module

Graphical postprocessor Documents generator

Alphanumeric postprocessor

Figure 5.8 Third version of environment.

05 25/7/03 09:54 Page 68

68

IPA – Concepts and Applications in Engineering 2D editor 3D editor Alphanumeric modeller Fluid dynamics problem modeller

Fluid dynamics model generator

Model examination

Simulator

Diagnostic module

Data analysis module

Diagnostic decision module

Graphical postprocessor Documents generator Alphanumeric postprocessor Figure 5.9 Fourth version of environment.

how to select parameters and how to evaluate results. He completes his inference with his knowledge. The main problem, however, is how to operate efficiently within an environment which allows different actions and where different actions can be supported with tools helping to create new solutions or adapt prior solutions.The designer may consider setting new nodes and forming new connections in the maze model. The process of moving from one node to the other in the maze requires testing to ensure that all data really exist. If the user does not want to do so a special procedure is initiated and the missing data are automatically created. Artificial intelligence tools fulfil the role of data generators in the maze. The knowledge bases contain domain

05 25/7/03 09:54 Page 69

5 A Common Model of an Intelligent Personal Assistant Concept 3D editor

69

2.5D editor

2D editor

Alphanumeric modeller Fluid dynamics problem modeller Fluid dynamics model generator

Model examination

Simulator Diagnostic module

Data analysis module

Diagnostic decision module

Graphical postprocessor Documents generator Alphanumeric postprocessor Figure 5.10 Fifth version of environment.

Projects First version

Projects Second version

Projects Third version

First version Versions of environment

Second version Third version Fourth version

Fifth version

Projects Fourth version

Projects Fifth version Databases with realised projects Figure 5.11 Designer’s cooperation with different versions of environment.

05 25/7/03 09:54 Page 70

70

IPA – Concepts and Applications in Engineering

knowledge connected with a particular node. The modules supporting particular node applications are as follows: ● ● ●

Knowledge-based system which supports missing data generation. Knowledge-based system testing input data quality. Knowledge-based system supporting the designer in the next step of the design process selection.

Consequently, the next objects of the whole system are paths, which are stored descriptions of design processes realised in the environment.They are kept as templates with the following slots: ● ● ● ● ●

Name of path. Version of the environment. List of steps realised in the process. List of addresses of data states of nodes. Notes and comments.

The system is controlled by commands.It is possible to select any node from which to start the whole procedure. We can name the realised project, test input data, correct these data, look for paths passing through a certain node, analyse the data states of the node and select the missing input data. It is also possible to activate the application connected with the node. After that we can analyse the result and take the next step in the maze model. With that the designer can add his associations and comments to the system using special data structures which can contain: ● ● ●

Verbal description of the association. List of nodes which are connected with a particular association. Name of path with the association.

The knowledge-based systems which are connected with a particular node can work in two ways: (1) with dialogue (user has to make a number of decisions), and (2) automatically (without dialogue with the user) taking data from the available data structures. In this chapter we want to concentrate on cases where knowledge-based systems connected with different nodes work separately.Hereby the user can open several projects at the same time, the one actually being worked on and previous projects. Normally the designer does not stop after having solved one simulation problem. Often he has to create a sequence of simulation problems. The results of every simulation case can be fruitful and inspire him for the next simulation. It means that the designer has to analyse the results of the simulations many times. He has to “fish”for expected and unexpected phenomena.

05 25/7/03 09:54 Page 71

5 A Common Model of an Intelligent Personal Assistant Concept

If we look at the dimensions of the problem we notice that the example system can be used for the following range of problems: several hundreds of cells and links, several state variables for every cell and link, and about 500 time steps. It can produce a huge amount of data for analysing, also in the form of diagrams and animations. Consequently, as the system is used there are many versions of additionally solved problems of different types, making it very important to manage the whole set of data information and knowledge structures. Every expert in fluid flow dynamics knows phenomena which he understands as the results of simulations which he had enforced and for which he was searching. In principle he looks for phenomena similar to those which he knows from past cases; and these are exactly the possibilities which the maze model structure offers. It makes the whole design environment user-centred and allows the designer to apply the computer environment which has evolved over the years and is still integrated. In addition to the operational aspect, the designer can store knowledge concepts and ideas which can support him while re-using and re-adapting former design processes and activities.

Multicriteria Optimisation Layer Now we want to introduce a multicriteria optimisation layer of a system called an intelligent personal assistant for machine design problems. It is the methodology of integrating a maze model with multicriteria optimisation. Parallel to the process of creating a path in the maze model, and performing activities belonging to this path, the designer can try to select the best parameters for his solutions and as a consequence create a sequence of activities belonging to the category of optimisation problems.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 function. The sequence of the optimisation problems, accompanying a path in the maze model, can be mutually interacted with via decision variables, constraints or criteria. The designer who solves a problem in a particular node should also have the possibility to create and solve an optimisation problem connected with this node. The solutions which result from an optimisation problem in a particular node can help with the selection of the next step in the maze model. However, optimisation problems of different nodes can interfere. So if we want to protect our final optimisation results from becoming game solutions (from game theory) we have to use the multicriteriadecomposed, multilevel optimisation approach which allows the

71

05 25/7/03 09:54 Page 72

72

IPA – Concepts and Applications in Engineering

designer to change the path in the maze model, to repeat some parts and to consider different structure solutions. An optimisation problem must always follow and be automatically generated according to the actual position in the maze. Therefore, we have to add an optimisation module to the concept of a maze-based environment described above. So far we have discussed issues concerning the sequence of modelled multicriteria problems. However, the method of solving such a problem is presented in Chapter 9.

Case-Based Reasoning In general an environment like the one portrayed above can be used over a longer period of time in which numerous versions of the environment are stored together with corresponding paths of particular solutions. When solving a new problem we can go back to the stored solutions (in the form of paths) and this will serve us as helpful material. Case-based reasoning is one of the artificial intelligence technologies [131, 133]. The cases are stored solutions of the problems solved in the past (in our approach these are paths). Case-based reasoning means the solving of new problems on the basis of similar past solutions. Design cases can consist of a problem formulation (with its history of its re-formulations), the design result (final project), all decisions and analysis made (with history, background assumptions and knowledge). So if we want to solve a new problem and look for some past solutions it should be possible to formulate our claims in a simple way. In our approach we intend to join our claims to a particular node (or nodes) and particular design variables. Our case can be adapted manually because we think it can be used as the source of context information. It is advantageous to open several maze systems having the opportunity to analyse the problem, using case-based reasoning and new problem solving while at the same time exploiting the knowledgebased support.

06 25/7/03 09:54 Page 73

6

Intelligent Personal Assistant – Concepts for Solving Integration

An intelligent personal assistant tries to cover several functions which are important in a design process. The integration of different design process components is one of them. There are a lot of computer tools used in design processes and they develop in the direction of knowledge-supported software. Consequently, their integration should offer a linking of different algorithmic computer tools together with different knowledge-based systems. Often, when we build an intelligent personal assistant application we ﬁrst try to capture reality and then reﬂect it in the (developed) software. There is a fairly wide range of separate tools and knowledge sources: (1) computer systems; (2) books; (3) notebooks; (4) human advice. While cooperating with a designer we get to know his plan or plans of work. His ideas may stimulate us to exploit them in a new software approach. We realise that the designer’s thoughts are the result of many years of experience and believe that they contain valuable knowledge for us; this is often the case. However, in many cases we observe that designers have mentally developed more concepts than they actually use. More than once the author has come across such situations in his research. Computer environments consisting of several modules supporting the design process were developed ﬁrst in each of these cases. The type of processing and the structure of integration was taken from reality. When the whole environment was developed and ready to support a particular design process the designer (knowledge deliverer) became aware that everything was fast and efﬁcient but that the process structure was not optimal; immediately the designer had ideas on how to improve it via a plan reconﬁguration, which was not always easy to do. In one industrial case, a certain design process had a very linear structure – ﬁrst multistage calculations, later geometrical modelling. The designers who worked on that project came upon the constructive idea to develop parallel alternative combinations of the whole unit and then compare them. This was surprisingly simple, but very promising. We think that there are at least two factors which inﬂuence a designer’s creativity. When a design process is conducted with little computerisation and integration then the whole design procedure requires more elementary effort from the designer’s side. When designers have to concentrate on very routine steps, ideas of modifying and improving the basic concept are not enthusiastically welcomed, because the consequences of any new concept may create an enormous increase of work and a higher risk of errors.

73

06 25/7/03 09:54 Page 74

74

IPA – Concepts and Applications in Engineering

If the design process is performed according to a particular procedure over many years and the knowledge which is behind the process has been forgotten in the meantime, then the whole sub-task is treated as a very informative black box. From all that we learn that designers need software structures which allow for more freedom with the selection of tasks. This means that such concepts are also very practical for the software developers. Every time we try to integrate several applications we have to consider the following questions: ● ● ● ● ●

How can we store data from each application? What data may be transferred from one application to another? How will data structures from future steps be integrated with the data structures from previous steps? How can the data consistency be tested in the case of an iterative approach? Will the integration of partially processed models be possible?

Apart from solutions practised in reality we are confronted with many theoretical integration concepts. Among them, two sub-groups, which are based on different principles of work, become obvious. In the ﬁrst group, the procedure reﬂects the actual circulation of information and is similar to a database approach. The second group, however, offers an open structure and often is based on blackboard architecture. Here, we want to concentrate on the second group. In [11, 16, 47, 48, 56, 59, 104, 109] blackboard architecture functioned as a tool for the integration of design software. Blackboard architecture has its origins in speech recognition systems (Hearsey II) [27]. It was often used as a method for solving large multidimensional problems where not only domain knowledge was important but also control knowledge. There is a certain setting frequently used to explain the principle of blackboard architecture. We imagine a room in which a group of experts sits and tries to solve a given problem. There is a blackboard in the room. The initial state of the problem is written on the blackboard. The experts look at the blackboard and propose their ideas of how to solve the problem. Their actual contributions are also written on the blackboard. As direct communication among the experts is not allowed, they can only communicate among each other via the blackboard. A single expert writes his proposal on the blackboard and by his action becomes visible to the other experts. Then the next expert can add his ideas. If it should happen that two or more experts want to present their proposals at the same time, then we need a moderator – a person who controls the order in which the participants may express their ideas. The procedure is conducted up to the moment when the problem is completely solved. We have learned that blackboard architecture [20, 27] consists of a blackboard, a set of knowledge sources, the experts, as well as a control mechanism, the moderator (Figures 6.1 and 6.2). The blackboard represents the database. As a global database it is visible to all knowledge sources and stores their data and hypotheses. The blackboard can have a hierarchy of levels; this means different sets of integrated data structures. A set of knowledge sources reﬂects all knowledge intended to solve a particular problem. There may be data structures on the blackboard which are common to several knowledge sources; and the knowledge sources can create,develop or modify the ideas on the blackboard. It is possible to activate the knowledge sources when they have fulﬁlled certain conditions. The control mechanism decides on a selected control strategy.

06 25/7/03 09:54 Page 75

6 Intelligent Personal Assistant – Concepts of Solving Integration

75

– Procedural application – Knowledge-based application – Human knowledge source

Knowledge source 1

Knowledge source 2

Knowledge source 3

...

Knowledge source n

Blackboard

Figure 6.1 Main principle of blackboard architecture.

Control module

Knowledge source 1

Knowledge source 2

Knowledge source 3

...

Blackboard

Figure 6.2 Role of control module in blackboard architeture.

Knowledge source n

06 25/7/03 09:54 Page 76

76

IPA – Concepts and Applications in Engineering

During the last 20 years, blackboard architectures with a different control mechanism have been developed [11, 16, 47, 48] and tested for many real-life problems. Even commercial toolkits for the fast construction of personal blackboard applications [8] are available. In recent years, blackboard architecture has been used as a platform for intelligent multiagent environment integration. Blackboard architecture offers high ﬂexibility with structuring a problem. It allows meta-level modelling, meta-level control and meta-level problem viewing. In [16, 47, 48, 104, 105] blackboard architecture functions as an integration platform of design tools. Blackboard architecture was invented as a structure reﬂecting the human way of solving problems. In our case the intelligent personal assistant application is the integration of various aspects of the design process, which we want to show with the example problem of machine shaft design.

Example 6.1 The problem was modelled as a Generic Blackboard Builder (GBB) [8] application.The process of machine shaft design consists of numerous activities, starting from an initial specification [33, 80]. Later different calculations are made whereby the designer can provide the forms of important shaft details (Figure 6.3). The process of shaft design is in general very routine, but when we try to grasp all the needed knowledge sources (especially those corresponding to what is done directly by the human designer) we see that the problem is not trivial at all; the number of knowledge sources is quite considerable.It is the same with the design variables set. At the end of the design process we have the process documentation together with all the corresponding actions. The overall process of shaft design can be realised in different ways, depending on the design problem characteristics. When we take a closer look at the shaft design process we see that various tasks have to be realised; a blackboard approach is capable of helping with all of them. Possibly the designers have different intents and the shaft can be meant for different machines. The design process may be carried out in a classical way as described in books where the standard calculations are done first and the form specification, second. However, the process may also be a shaft project adaptation. For instance, the stiffness has to be improved, the vibrations reduced or the shaft has to be adjusted to an already existing machine. A blackboard plays the role of a project development repository where certain stages are stored. The state of the blackboard information can be visualised at any time. This can be either a list of variables with their values or additionally a geometrical presentation of the shaft. The blackboard also functions as a working space for the environment. It is able to store all the elements of the shaft in a hierarchical structure.The design process can be understood as a dialogue among

06 25/7/03 09:54 Page 77

6 Intelligent Personal Assistant – Concepts of Solving Integration

77

Knowledge source: Machine shaft form spec Description: … Name of Knowledge source:… Triggering conditions:… Principles: Rules: 1. … 2. … 3. … 4. …

Control module

1. Formal: queuing mechanism, knowledge based mechanism, 2. Informal – done by designer.

Groups of data structures for machine shaft description placed on blackboard:

Blackboard

- geometrical data of shaft components, - material data, - surface data - data of bearings, -… - functions fulfilled by different components, -… - data of connections, -… - forces, - stresses, - displacements, -… - manufacturing data, -…

Figure 6.3 Example problem: shaft design, modelled as blackboard application.

knowledge sources: the knowledge sources observe the state of the blackboard and communicate when they want to perform a process (i.e., when they generate new information). The new information can be collected on the blackboard. Then the blackboard architecture allows actions which are possible at that moment. The blackboard is able to choose those actions which have the best chance of being realised. This selection may be performed automatically. However, with design problems it is very important that the designer has the possibility to interact with the blackboard. In such cases the designer can function as one of the knowledge sources. He then may initiate actions, observing and waiting for the response of the system. In the example problem [33, 80] the blackboard was implemented as a structure modelled in a GBB environment. There were objects

06 25/7/03 09:54 Page 78

78

IPA – Concepts and Applications in Engineering

which reflected the basic components of the shaft. During the design process, the objects were placed on the blackboard. Additionally, knowledge sources which had to solve particular groups of problems were selected: ● ● ● ● ● ●

Initial data selection. Theoretical form of shaft generation. Initial shaft form specification. Calculation of shaft deformation. Detailed form specification. Engineering analysis.

Apart from the main knowledge sources there was a group of knowledge sources holding minor roles, such as capturing information on the blackboard and creating graphical visualisations.The knowledge sources could be activated by objects or events connected to them. For every knowledge source, circumstances were defined under which it could be used. A control mechanism for the blackboard was built as well. Simple cueing solutions were implemented. After the specification of all data structures on the blackboard,their instances could be generated. The knowledge sources generated the object on the blackboard, observed the state of the blackboard and indicated when they were ready to act. The control mechanism fixed the order according to which the actions had to be performed. In the described application the dimensionality of design problems became obvious as well.The problem of shaft design, modelled as a blackboard problem, has a relatively high number of knowledge sources and a relatively low number of instances of particular objects.With this proportion of knowledge sources and instances the problem in question differs from signal recognition problems, which are often supported by blackboard architecture. Generally, blackboard architecture is a concept of how information and knowledge can be processed. Although blackboard architecture can be realised with different computer tools, the question arises, whether designers are willing to accept this concept and really want to use it. We wanted to find this out and therefore presented our approach together with two example problems (simulation results selection and machine shaft design) to industrial designers. The role of the blackboard as a sharable database was accepted at once, and the meaning of the knowledge sources was also easily understood. However, in spite of the fact that all the details of blackboard functioning had been carefully explained, the designers showed little enthusiasm towards the use of the control module approach. Obviously, they were not ready to accept that many actions can be carried out relatively quickly without significant graphical expression. We concluded from the designers’ reactions that for the time being

06 25/7/03 09:54 Page 79

6 Intelligent Personal Assistant – Concepts of Solving Integration

the concepts of the blackboard and knowledge sources have been accepted and will find their way into designing in real life.The control of the blackboard architecture is better left in the designers’ hands. Returning to our work with this method we may emphasise that blackboard architecture also offers modularity. Modularity means that the overall design problem consists of a number of structures, in our case knowledge sources, which exist separately and have their own way of development. Each knowledge source is a special independent unit and it develops as such. It can exist as several instantiations corresponding to its development. Knowledge sources may have the form of classic expert systems, databases or algorithmic modules. In the example application each of them was integrated with a knowledge-based application; and these knowledge-based applications were integrated with the blackboard as knowledge sources. Knowledge sources are relatively easy to integrate. However, we have to use the same system of data structures everywhere.The condition to operate with the same data structure with all knowledge sources must be fulfilled. Next, we had to consider the standardisation of the shaft components and propose shaft object structuring in a reasonable way. If we have integration with commercial CAD or CAE systems where there is already a collection of basic shaft components, we can try to apply it. However, often we do not have its complete and formal definitions. Applications based on blackboard architecture are relatively easy to rebuild because they clearly express how particular modules cooperate with each other. Blackboard architecture offers much freedom with the selection of alternative knowledge sources. Therefore, we may create different control mechanisms: a simple one which is based on a queue concept or a complicated one which is based on knowledge.It is also possible to perform blackboard control manually.In this case the designer can realise his most favourable version of a problem solution. However, he should be aware of the most important differences from automatic control. When blackboard architecture of a particular problem works according to the modelled knowledge (knowledge source, knowledge supporting control mechanism) then it is usually controlled by the formally articulated model and works automatically. However, in design it rarely happens that everything which is worth considering is also modelled formally. So in a certain cycle of blackboard architecture we may have a few knowledge sources which are “willing to be activated” and where the control mechanism has to select “the most suitable knowledge source”. However, if we allow a designer to do this he can think of his associated, permanently developing formal and informal knowledge and decide the selection of the knowledge source.In this case the designer’s personal knowledge development is probably more adequate for the

79

06 25/7/03 09:54 Page 80

80

IPA – Concepts and Applications in Engineering

particular solution of the design problem than the implemented formal control.This is an important aspect of the overall blackboard architecture approach. Therefore, we think that the basic concept layer of blackboard architecture, i.e. integrating the multitude of knowledge sources of different kinds, together with the working space, i.e. blackboard (database) can be successfully used for supporting design processes. We notice the presence of software on the market which supports the fast integration of various applications with a spreadsheet as an integration platform [24, 52, 60, 110]. The overall structure reminds us of blackboard integration. An essential feature of that software is its flexibility and its dynamic method of integration. The process of control is done by hand. This means that the designer makes decisions and selects knowledge sources (applications) for their activation on the basis of his actual knowledge. Recalling the concept of an intelligent personal assistant, we can say that blackboard architecture is a useful tool for the integration of different activities (knowledge sources). However, problems may appear with its control mechanism. If the control is knowledge based, it is only suitable for relatively small and routine problems. In this case the designers’ personal knowledge corresponds to the knowledge used for the blackboard control. The software of blackboard architecture is of great importance. Blackboard architecture is only a concept, and can be realised in many different ways. Parallel to the GBB project of shaft design support, another project for the same design process was realised with Visual Basic (VB) and CLIPS as computer tools [33]. In the second design case the results were successful and the application development was less complicated (VB is relatively well integrated with many software tools) and cheaper than in GBB. Additionally, VB and CLIPS are well known and quite popular computer tools.

07 25/7/03 09:54 Page 81

7

Intelligent Personal Assistant – Design Process Modelling

Nowadays real design processes in mechanical engineering are relatively complicated. The main reasons for this are: ● ● ●

Growing complexity of products. Advanced manufacturing methods. Short product development time.

The design processes have become more specialised and more intensive, but they are still performed by human designers. Designers specialise in their domains and when tackling bigger projects they have to collaborate with other designers. When we compare different design processes we notice a multitude of forms reﬂecting the richness of product variants and the ways they are developed and ﬁnally marketed by many different people. When we set about providing computer support for designers, we have to create a model of the design processes employed by them. However, real-life design processes can have many different forms.Each of them is realised in different external conditions by designers with different knowledge and personal experience. Even processes for the same or similar products realised by the same people may vary at different times. What we understand when trying to build a design model depends largely on our ability to ﬁnd contact with the people who provide us their model. Developers of computer systems supporting designers often use methodologies, i.e. frameworks containing sets of ready-made components and functions. This kind of tool is often based on the literature and on personal or company experience. For instance, somebody who has worked on many procedural industrial applications mainly concentrates on the procedural stages while analysing a particular design process and neglects the rest. Later he tries to make a mapping of the procedural knowledge on software modules which already exist. Additionally he has to build or buy missing modules. Then he creates the scenarios of work for the new application, builds an interface, composes the available users’ proﬁles and considers the issue of data storage and standards. While building his software structures he is trying to catch how designers solve their problems. The cooperation inﬂuences both parties. At the end a speciﬁc industrial system is ready. It can be tested, corrected and ﬁnally accepted. However, a system developed this way cannot exceed the abilities and perception of its developers. The questions arise: For how long will such software be useful? When will it become necessary to add new objects or new functions? When will somebody come 81

07 25/7/03 09:54 Page 82

82

IPA – Concepts and Applications in Engineering

to the conclusion to build a new version of the whole application and actually do it? Then,again we enter the phase of speciﬁcation,development and testing.Additionally, between launching the ﬁrst version of the application and its successor the real-life process has developed. Meantime the designers/users have produced new knowledge chunks which have been stored or lost; and the real-life design process and the application supporting it have developed apart from each other. Therefore we look for computer design support software which is able to absorb new knowledge chunks quickly. This means we require from our new system a mechanism which is able to store the knowledge acquired while designing. Thus the evolution of a computer support system would be more continuous. The modelling of a design process represents the articulation of activities which are done as a sensible sequence of steps. It can proceed with the help of a design process representation. This representation can belong to the category “human interpretable” or “computer interpretable”. In the second case we speak about a formal model of the design process. Behind the modelling of a design process there is always a certain intention, for instance to optimise the design process structure, to make the process re-usable or to create a repository of design processes with the goal of using them as a source of design rationale information. When we start modelling the design process we have to determine how detailed this should be done. Cooperation with human designers may lead to a wide range of descriptions. However, it was proved in [67] that there are some limitations in perceiving what a real-life design process consists of because the complete representation of the process exists only in the designers’ minds; and it is only the designer who knows everything about the process when the task is brought to an end. Most designers are able to repeat and then describe the whole process perfectly. This fact is good luck for us. However, to exploit the designer’s memory well, we should from the very beginning use formal categories which are often present in real-life problems like actions, steps, resources and consequences.

Example 7.1 To clarify our approach we want to take as an example a real-life problem – the design process of test stands for automotive components testing. The respective designer had specialised in projects for industrial stands for automotive transmission components testing. First he presented the background to his domain and explained how and when his interests were initiated.It was possible to associate this information with its technological and historical context. Knowing automotive factories and their products for which these projects were done we could easily identify a wider technical context. The designer enumerated a relatively long list of problems which should be considered in such a project. However, the items were of a rather general validity and did not give any case-specific information. Then the designer presented solutions met in real designs, using examples of earlier designed and built stands. He underlined that for a new stand the following sub-systems should be created: ●

Transmissions – we learnt that there are two functional classes: (a) main transmission, and (b) additional transmissions used for

07 25/7/03 09:54 Page 83

7 Intelligent Personal Assistant – Design Process Modelling

● ●

● ●

additional motions. In most cases this system is based on different kinds of electric engine. Braking systems – systems which should absorb and dissipate energy. In this case often different electric engines are used. Measurement systems – systems which should measure different values. The designers have to consider concepts for direct and indirect measurement, different types of sensors and computer processing. Components of the stand structure – plates and other components together making the body of the whole stand. Different additional systems for the following functions:positioning, loading and controlling of the stand.

As a first step the test object,for example,the belt gear or the harmonic drive, should be specified, then the test purpose, the durability of the components for instance, should be set. Next the principles of the stand functioning should be considered. The measurement is an especially important issue as it should meet the requirements of testing. After that the designer proposed a list of linearly composed problems which have to be considered: ● ● ● ●

Analysis of concept details of the measurement system together with its provisional costing. Availability of measurement system components. Conceptual development of components which should be designed and manufactured. Building concepts of software components.

While cooperating with the designer we got information about nearly every knowledge chunk and how it was developed over the years. For instance, the designer told us about a specific measurement sensor: when he heard of it for the first time; when he read about it for the first time; when he saw it working, when he worked with it himself; when he started to build software cooperating with it; and who were and are the main suppliers and how their products were reviewed. We noticed that the designer operates with knowledge which may be categorised in different ways. The first and most obvious categorisation was based on knowledge sources which were selected and used by him. This group comprised: (1) principles and knowledge taken from design theory; (2) principles and process plans resulting from his long practice; (3) different software tools and connected know-how for different stages of the design process. According to the different forms of how the designer expressed his design process knowledge we could do a second categorisation. We noticed that a part of his knowledge can be shown in the form of

83

07 25/7/03 09:54 Page 84

84

IPA – Concepts and Applications in Engineering

computer procedural applications, accepted and used by him.Another part of the knowledge could easily be articulated in the forms usually stored in databases. The next group of knowledge consisted of some clear rules on how to solve particular problems. It was a direct expert system representation. A relatively large part of it was typically his oral explanations, showing different paper and computer documentation. Many of the previous design problems occurred in parallel in several of the given representations. From this we concluded that our computer support should offer storage for each of these groups of design knowledge, so that the designer at any moment of the design process should have the ability to store: ●

●

●

Procedural knowledge in the form of commercial and self-written procedural software. The commercial kind of expressed knowledge can mean large computer systems used for specific classes of problems with many additional tools, integration concepts, user profiles etc., in contrast to the procedural software made by a designer, or the people cooperating with him, which is very customised. Declarative knowledge in a form which can easily be implemented in knowledge-based systems. Often these are domain rules and facts. Sometimes we may discover an object-oriented approach in the presented knowledge. Descriptive knowledge in the form of texts, pictures and schemes.

When speaking with the designer we noticed a very important issue concerning knowledge storage: its dynamic aspect. We learnt from some examples that real-life sub-processes realised by the designer (with the help of different tools) generated new knowledge chunks which could be represented in one of the previous forms; and what is more important, often the knowledge chunk, expressed for instance as a procedural application, was in principle a transformation of knowledge (done by the designer) based on many knowledge chunks stored earlier in the different forms mentioned above. From this we conclude that a designer notices a problem, builds its descriptive model, completes the model, tests its parts and then looks for further information and knowledge. It is a long process which can be recognised in the designer’s thinking and in his personal notes. If we keep track of the stored knowledge evolution we may capture this process to some extent; and later comes the moment of the designer’s illumination – something new which can be expressed and stored. The author was told several similar stories illustrating the background to ﬁnding the most important issues of various design problems. Obviously, the process of generating and articulating personal knowledge by a human takes time. Normally human designers operate with many hypotheses and are careful with their ofﬁcial articulation and presentation. While working, the designers test their hypothesis and often they ﬁnd positive and satisfying results. However, even

07 25/7/03 09:54 Page 85

7 Intelligent Personal Assistant – Design Process Modelling

85

with a growing amount of experimental material, hypotheses remain hypotheses. Therefore, many knowledge chunks are treated as something vague and weak. This issue forms the basis for our next categorisation: ● Knowledge which is hypothesis. It has a relatively high risk coefﬁcient. It is often very personal. Sometimes it is shared by several people but under speciﬁc cooperation conditions. ● Knowledge which is (treated as) routine. It has become standard and has a high validity. The design process characteristics shown here in an example problem have been found by the author and his cooperating team in numerous real design processes. On the basis of these observations we set up a framework for modelling the design process of an individual designer or a small team of designers. We assume that design processes consist of activities and that they are based on knowledge sources (Figure 7.1). As the activities and knowledge sources are selected and described by designers they reﬂect their personal and mental structuring of a design process. The activities and knowledge sources also have a very strong historical background. It means that each of the design activities and each of the knowledge sources changes in time according to personal knowledge development. At any moment the designer can explain a speciﬁc design problem and say what tools he actually uses, what knowledge depots are available and what experience he has

Single-activity knowledge representations: – procedural knowledge – declarative knowledge – descriptive knowledge

... Designer and multitude of available activities

... Designer and newly created plan (from available activities) Figure 7.1 Designer and variety of his activities.

07 25/7/03 09:54 Page 86

86

IPA – Concepts and Applications in Engineering

gained. He can also go back to the past and tell us about different things that appeared and the reasons for this. In every design process the designers use different non-computer and computer tools. Each of them is based on knowledge. Usually design knowledge is expressed in one of the following forms: procedural, declarative and descriptive. A designer’s knowledge is also stored in his mind. In this case the designer can do his private knowledge management. However, we may build computer applications based on this non-public knowledge. For this we should remember the classes of knowledge storage tools. For knowledge with a procedural form we have to build a procedural application. For declarative knowledge we have to build knowledge-based systems, for descriptive knowledge we have to create special databases. Each of these components should be modelled as a dynamic one which can evolve. With it the users or system developers then have the possibility to add new components or new knowledge chunks. However, when the system increases we need tools for its management. The basic concepts of knowledge management for individual designers derive from ideas developed for paper notebooks: ●

● ●

● ●

Chronological approach: each knowledge chunk is connected to a direct time event, i.e. when it was expressed by the designer in one of the forms which can be stored on the computer. It can have links to the knowledge chunks which were the basis for generating this particular knowledge chunk. Keywords: each knowledge chunk has keywords associating it with the particular problem’s categorisation. Storage of past design processes: storage of the earlier states of the whole computer support environment, including activities and knowledge sources in their historical interrelated context. Comments (called associations): generated by the designer and linked to suitable data structures in the whole notebook. The stored knowledge is accompanied by its validation type: (a) hypothesis, (b) standard.

Finally, we have speciﬁed the functions of a designer’s computer notebook in the case of individual or small team processes. An example will make it clear.

Example 7.2 We focus on a designer who specialises in the design of speed reducers. We present his environment in the state that it was in at different moments in time. 1. The designer is at the beginning of his career. He makes calculations of basic geometrical parameters of speed reducers. On the basis of literature and company know-how he selects initial parameters of toothed wheels. He uses simple computer codes for the calculations of toothed-wheel stresses. 2. The designer learns about optimisation and builds a code supporting the process of toothed-wheel optimisation. Using this, he starts calculations from non-feasible solutions.

07 25/7/03 09:54 Page 87

7 Intelligent Personal Assistant – Design Process Modelling

3. The designer learns about multicriteria optimisation and builds a code for the multicriteria support of speed reducer calculations. 4. The designer learns about multicriteria, multilevel and hierarchical approaches and builds computer tools for (computer) calculations of complete gear boxes. 5. The designer learns about calculations of planetary gears and makes a code for optimal calculations of planetary gears. 6. The designer adds the possibility of calculations for whole planetary gear boxes to the existing code for planetary gear calculations. 7. The designer learns about expert system technology and articulates a number of rules which are useful for specific cases. 8. The designer learns about knowledge-based engineering (KBE) and incorporates knowledge about form specification for toothed wheels into the KBE system. It is possible at once to visualise each of the sets of parameters as a 3D geometrical model. We want to add that in between the enumerated states, the designer did toothed-wheel calculations where he obtained experience of solving practical problems. He also read specialist literature. Then, the knowledge gained through all these activities was stored in paper notebooks. Logically, this had direct correlation with the states listed before. If we wanted to present all important states from (the perspective of ) the personal design process knowledge, the above list would be much longer. However, when we think about computer support of the design process modelled according to this example, we must store all kinds of knowledge gathered during the design process in exactly those forms in which they actually appeared (Figure 7.2). For instance, state number 1; the designer uses literature – this means we store as computer descriptive knowledge source information and knowledge resulting from this literature together with biographical data. We also store, in a descriptive way, concepts about how to select initial parameters of toothed wheels; and we have a computer code for the calculations as a procedural knowledge source. Moreover, we store descriptive knowledge when we explain the concepts and assumptions of the code and how to use it. Later, in the second state, after reading about optimisation, the designer tries to create algorithms for toothed-wheel optimisation. Doing so, new states with descriptive knowledge appear (not enumerated above) and the designer starts to experiment with the software. The first results are mostly rather frustrating due to the problems with the mixed decision variables (discrete and continuous).This stage may be described as the development of hypotheses and their gradual verification.At the end of state number 2 the code is ready and changes its

87

07 25/7/03 09:54 Page 88

88

IPA – Concepts and Applications in Engineering New procedural knowledge chunk created on the basis of earlier states

New descriptive knowledge chunk created on the basis of earlier states

Single-activity knowledge chunks: – procedural knowledge chunks – declarative knowledge chunks – descriptive knowledge chunks

State in moment i

Designer and multitude of available activities

...

State in moment j

time

...

Figure 7.2 Dynamic issue of single activity knowledge.

status from hypothesis to standard. Finally, different descriptive and procedural knowledge sources have generated a new procedural knowledge chunk. Similar examples can be found for all other states. However, knowledge creation does not have a fixed direction, it can develop in many ways. We assume that the designer can work in any environment which gives him the possibility to work this way. When the designer has to solve a new problem he can use everything which was done earlier and stored by him. The computer environment contains the professional designer’s “biography” (Figure 7.3). However, this “biography” would not be complete without realised design projects. To implement them we need information about how particular design projects were carried out. It means we have to add to different design steps, realised with the help of the existing tools, and their documentation, additional information having its origin in the designer’s personal notebook and being of a design rationale type. Obviously, the designer may add his actual personal comments, but it is easier to make links to his existing knowledge chunks or to connect them to the project documentation (Figures 7.4 and 7.5). Every time the designer wants to look at an old project he has the possibility to analyse its background design rationale information. However, it is more advantageous to return to the state of the design environment from the moment when the project was done and then to see each step in real circumstances.

07 25/7/03 09:54 Page 89

7 Intelligent Personal Assistant – Design Process Modelling

89

...

Designer and multitude of available activities

Intelligent personal assistant stores and manages all knowledge chunks of all activities

Intelligent personal assistant

State in moment i

State in moment j

time

Figure 7.3 Role of intelligent personal assistant.

time Product representations

... Designer and newly created plan while designing (from available activities)

Design rationale information generation on the basis of knowledge from intelligent personal assistant

Personal knowledge development

Intelligent personal assistant

State in moment i

State in moment j

Figure 7.4 Design rationale information generation.

time

07 25/7/03 09:54 Page 90

90

IPA – Concepts and Applications in Engineering

Repository of projects

Particular project documentation from repository of projects Links to particular states of intelligent personal assistants designer X’s and designer Y’s

Designer Y and his intelligent personal assistant State in moment i

State in moment j

time

Designer X and his intelligent personal assistant State in moment i

State in moment j

time

Figure 7.5 Connection between project documentation and intelligent personal assistants.

With this approach we obtain knowledge of a tacit type.We get to learn how a problem was solved and what the circumstances were. We can compare present and past states, and on the basis of this knowledge we can build a new plan for solving our current problem. The proposed approach was applied by the author and his cooperating team in numerous cases. Further details are presented in Chapter 10. Many design problems in engineering are complex and consequently designers have to work in teams. The realisation of one large design project can take months or even years. During this period each member of the design team has to carry out many activities and make many decisions. There are also many interactions among the team members. Data are processed and knowledge is considered and exchanged. The members of the design team move in an ocean of information. In order not to lose their way, they do their own knowledge and information management, which inevitably has its own dynamic. Because of their scope, many design projects have to be split up into smaller parts among several people or teams. Every designer or team realises the multitude of sub-tasks working with his own speciﬁc information and knowledge management. Hereby, new components are continuously produced which become further information and knowledge. This new material is directly and involuntarily connected to the structures already existing in the designers’ minds. The

07 25/7/03 09:54 Page 91

7 Intelligent Personal Assistant – Design Process Modelling

91

new information mostly consists of comments and reﬂections. However, there are also so-called communication acts which are stored as well. Design problems in mechanical engineering do not only mean a bundle of sub-tasks which are realised in parallel by different teams or individuals, they also consist of many partial problems which have to be solved sequentially. There are integrated structures and different stages of the overall process. Each stage has its own goals, interim results and constraints. Design problems rarely occur in isolation, as they are made of components which are processed in cooperation with external partners and consultants. Also design problems are often multidisciplinary and so cannot be solved by designers who represent only a single domain. Due to all these factors, it is very difﬁcult to really understand a certain design process. When approaching it we always should consider if our model of the design process and the associated knowledge can be directly re-used. The next issue is how to handle unexpected events. Many unexpected events result from a huge amount of processed information. However, it is possible to make everything more effective. Many steps in this direction have already been done. Most of them, however, deal mainly with the ﬁnal stages of the design process, which are quite well deﬁned. The design process information and knowledge can be captured in the notebooks of individual designers or as knowledge connected to the realised project. In the second case we can make the designers add their knowledge comments to the existing project documentation. We ask each of the team members to explain his decisions and to put his information into given frameworks. We can also think of tools with which this can be at least partially done automatically. When we set about doing real-life implementations of the design computer support we have to contact different people who worked on the same project. Often we quickly ﬁnd out who knows what and from whom we can capture certain technical parts of the process and organisation details. By this we get to know who played what role in the design process. Through the project manager we can learn how the project was managed and how its details were clariﬁed. He often provides a lot of information about the relationships with his suppliers, other cooperating teams and the higher management level; and what may be more important, he has a good view of the time schedule of the entire project, its long-term consequences and its budget limitations. We clearly see at least two perspectives from which to cope with the troubles observed with large design problems: (1) that of a particular domain designer; (2) that of a design process organiser. Both are equally important for building the design model, because they are deeply interrelated and their tasks are rarely done by one and the same person; their functions are rarely held in personal union. However, in some of our example research cases, which were relatively narrow, these two roles were held by the same person. That situation turned out to be very advantageous because in those cases the procedure of process capturing and computer support building was faster and the most successful. The process model was integrated in its sources. So, when we think about computer support for a design team we have to consider how much of the whole information and knowledge ﬂow during the design process can be captured. If we want to do that in a sensible way we should deﬁne some goals of our work as the basis for information and knowledge management: when we intend to improve the coordination among different members of the design team; when we have to think about increasing the design efﬁciency; and how to make the parts of the design process more repeatable, and how to reduce the rate of errors.

07 25/7/03 09:54 Page 92

92

IPA – Concepts and Applications in Engineering

Consequently, the approach proposed in the ﬁrst part of this chapter (for design process modelling of individual designers or small teams) should be equipped with possibilities which allow human cooperation. We work on the assumption that only the designer himself knows best what is done; and therefore, any act of communication always should be interpreted personally by the particular designer. So if we want to store information on communication acts, we always need the designer’s associated personal interpretations. This information is stored in individual design computer notebooks together with the designer’s subjective, personal issues. Nowadays we often observe methodologies which lead to the storing of the design process background knowledge. These ideas are known as design rationale and design knowledge repository. As a result, we obtain the ﬁnal project documentation together with the project history and the rationale of all important decisions. Such information may help in the future to understand the project. Rarely are there situations in which we can repeat the whole process directly because it is difﬁcult to ﬁnd two identical processes. There are too many changes in the external conditions even if a design ofﬁce works only on similar projects. Using this approach we assume that each member of the design team is willing to present and store his know-how used in a certain situation. Our approach may be called project-centric. It means that as an effect of the design we have the ﬁnal project documentation in a standard representation together with its documented design rationale. Hereby the design rationale knowledge is separated from the designers and exists in a separate computer representation together with the standard project documentation. We hold the opinion that we can learn about design processes from earlier cases. After having collected a number of cases we try to look for useful processes; and probably at some moment we can start to combine parts of stored processes.What we see is nothing else but the project documentation together with the design rationale information, as we have interrupted the connection between the private designer’s knowledge depot (notebook) and the project documentation with the design rationale information. Let us consider again the multitude of designers who work individually and also cooperate with others in a team. Each of them has to solve a set of interdependent tasks. All the tasks have common components that are ﬁxed and coordinated. This means that we have to add external knowledge sources to those of an individual designer which were enumerated earlier. The designer can use knowledge sources of other designers. The usage is controlled by the author. The designer also has access to the knowledge sources which were built for a team or a ﬁrm. In the case of small teams the problem of task management can be done ad hoc. With larger teams, however, professional project management becomes necessary, so that the entire system will be controlled by a project manager. Our design process model goes on the assumption that each designer operates with his private computer support system (notebook) which fulﬁls the role of a private knowledge depot. The design rationale information of the project can easily be generated on the basis of the knowledge content of private knowledge depots. The design projects can be stored in a central project repository of the team or the ﬁrm, together with its design rationale information (connected by different designers). Any time we would like to have a look at particular stored projects, the design rationale information for the project will also be available. The main difference with design repositories would be the creation of this kind of information, except that the creation of the respective knowledge has to be different in this case. It has to be based on knowledge

07 25/7/03 09:54 Page 93

7 Intelligent Personal Assistant – Design Process Modelling

93

stored in private knowledge depots. Additionally, project documentation and especially design rationale information contain links to the knowledge chunks from the notebook of a particular designer which were the basis for generation of certain design rationale information. Consequently, we are quickly able to ﬁnd the design context of a particular project done by a particular designer or several designers. This information is necessary for a deeper understanding of a real project. Another question which arises is, which sources from private design knowledge depots should be available when a project and the documentation linked with it is ﬁnished? The project with its design rationale belongs to the ﬁrm. However, what about the private context knowledge written down in private notebooks? First, we think that this problem should be resolved by contracts. Second, a more speciﬁc classiﬁcation of knowledge sources in private notebooks is necessary. The following three assignments may be helpful: 1. Knowledge of a hypothetical nature has a relatively high risk coefﬁcient. It is often personal. It is something very private which is shared under speciﬁc conditions. 2. Knowledge regarded as routine or standard is characterised by a high level of validity and is shared among all members of the team. 3. Knowledge regarded as routine or standard with a high level of validity is decided and formally described when it is available in the case of designer–designer collaboration. The difference between (2) and (3) lies in the short period of collaboration – a type of consultation which is often met nowadays. In (2) the team of designers is assumed to be employed by the same ﬁrm. In (3) the designers may come from different ﬁrms. We suggest three degrees of access to the knowledge of an individual design notebook which seem conceivable and suitable for practical use (Figure 7.6): ● ● ●

For the designer himself and the people cooperating with him intensively. For the designer and the members of the team permanently cooperating with him. For the designer and periodical external collaboration.

We may add a fourth category called advertisement with basic keywords. It can give an overview of the designer’s professional abilities. After we have stored the project and the design rationale information together with its links to particular individual designers’ notebooks we can relatively easily return to the designers’ environment states from when the process was realised. Then we can compose a new design process on the basis of selected design processes. Knowledge stored in notebooks but belonging to different cooperating designers can be shared. Obviously, we need some technical mechanisms allowing for this sharing and incorporating of concepts of knowledge management. As we have seen, the knowledge associated with a design process can be procedural, declarative or descriptive, and can have different degrees of validity. The knowledge which is stored in a procedural form (procedural computer systems and codes) is divisible from the beginning. However, some parts of the procedural knowledge may be of personal character (e.g., small MS Excel applications, self-written codes, etc.). The declarative and descriptive knowledge is sharable only to some extent. Obviously, each problem can be presented in each of these forms. However, we now want to focus on the issue of how the knowledge of individual designers can be shared. Again, we return to the problem of toothed-wheel calculations. We have a computer code which does these calculations according to some

07 25/7/03 09:54 Page 94

94

IPA – Concepts and Applications in Engineering

Designer Y and his intelligent personal assistant State in moment i

State in moment j

time

Designer X and his intelligent personal assistant State in moment i

State in moment j

time

Content of intelligent personal assistant not available to other designers Connections allowed by owner of intelligent personal assistant Connections not allowed by owner of intelligent personal assistant Figure 7.6 Connections between designers and their management via intelligent personal assistants.

standards. We can have a knowledge base with rules on how to select the initial parameters for toothed-wheel calculations. We can also have descriptive knowledge on how to calculate toothed wheels with a different approach in the form of documents and experimental data. Different kinds of project documentation dealing with toothed-wheel calculations are also available and from these we can conclude how toothed wheels are usually calculated. When we look at real-life design processes from the aspect of how divisible design knowledge is, we get the impression that there is no problem as long as the designers are working in the same place, and have a similar background and education. However, as soon as teams cooperate over a distance and their members belong to different cultures, misunderstandings occur. This will hold even with regard to our toothed-wheel example. In Poland, for instance, German standards are well known and widely used. However, when Polish engineers take information from, e.g., the UK or the USA, problems often follow. The reasons for this are the different roots of knowledge in these countries. Probably, we may ﬁnd many similar situations in global industrial cooperation. The possibility

07 25/7/03 09:54 Page 95

7 Intelligent Personal Assistant – Design Process Modelling

95

for both sides to look into selected knowledge sources from designers’ notebooks would make mutual understanding easier. The same problem can appear with different knowledge chunks represented in different ways; and what is more important, these knowledge chunks can be transformed from one form into another. For instance, we build a number of rules on the basis of descriptive knowledge or we build a computer code based on it. It is also imaginable that we use a computer system for some time. Our descriptive knowledge about it grows and can be stored as well. These operations in which knowledge gets a new form are usually done by designers personally. They can either be performed with the help of some computer tools (data mining, machine learning) or additional people (ofﬁce assistance, knowledge engineer). The possibility of analysing individual paths of the knowledge development gives a wide context to the realised design processes even in the case of multicultural cooperation. In this book it is very often emphasised that we want to improve designers’ personal computer support, because we see great advantages in storing all that is generated while designing, and this is how the whole process can be improved: via more effective re-use of personal knowledge sources. Personal knowledge sources have various forms and develop continuously. Nowadays it is impossible to imagine a single personal approach without its correlation with the multitude of other single personal approaches. It means that when a design ofﬁce gets a new computer ﬁnite element system, this system is at the disposal of all members of the design team. This is an example of procedural knowledge storage. There are team members who have their descriptive, declarative and tacit knowledge which helps them learn quickly how to operate the new system, but not everybody is able to become familiar with it in an appropriate time. Another interesting tendency can be observed. Servers with installed procedural applications are being built which can be used over long distances via networks. Such an application has a very good, competent servicing and above all it is divisible. The same idea is noticeable with different dedicated knowledge repositories which are available to a wider community of designers. Consequently, we model a design process as a sequence of continuously improved plans, which are carried out by designers. New components are added and other components disappear, but they are still kept as design process history. This sequence of plans changes dynamically. However, there is always knowledge which says where to go now and how to do the next step. In a design team, designers work by realising design process tasks. Most of these tasks are characterised by their names (identiﬁers). The designers decompose their tasks into several sub-tasks. They establish personal plans for solving their individual design problems. The knowledge which they use is stored on different media. There are also private knowledge depots as the knowledge develops. The designers’ descriptive knowledge can exist as comments which are associations with different knowledge chunks. The overall process of knowledge transformation has an intensive dynamic structure. The main intention of our concept of private knowledge depots was to achieve a better quality of stored knowledge. The notebooks are the work ﬁelds of private designers. The proposed structures allow dynamic knowledge storage for a certain designer. As follows, the design knowledge repository for a team or a ﬁrm should contain links to all knowledge chunks of the private depots. It is up to the designers to decide which of their private knowledge chunks should be linked to the common knowledge depot of the team or ﬁrm.

07 25/7/03 09:54 Page 96

96

IPA – Concepts and Applications in Engineering

Example 7.3 Again we want to call upon the services of the designer who specialises in toothed-wheel gear design. We imagine that he cooperates with a designer who is responsible for the selection of gear ratios according to the expected car dynamics characteristics for a particular engine.We assume that the first designer has finished with the selection of gear ratios for a particular car and engine and that he has checked his results and made sure that he has obtained the expected dynamics of the car. Then, after receiving the values of the gear ratios, the second designer starts to model the toothed wheels of the gear box.He tries to solve his problem and to meet the durability criteria for toothed wheels. Both designers achieved good results for the future structure of the whole problem. Both used their own computer notebooks. At the end they created the final documentation of their problems together with explanations about the background of their decisions. Parts of these explanations were based on entries in their private notebooks. Hereby the design rationale information stored together with the project documentation was linked with suitable knowledge chunks in the designers’private design notebooks.The final documentation was placed in the repository of the project. If now we wanted to analyse a particular design project we would not only find information about its final state, but we would read about the background of particular decisions and we would be provided with all the proper information from the private notebooks. Thus, we gain a complete picture of our example design process. What can be improved in the process structure? Surely the connection between the first designer who selects the gear ratios and the second designer who calculates the toothed wheels is a weak point. The question arises as to whether the solution selected by the first designer and later by the second designer is the best for the problem as a whole. It is possible for instance, that by adjusting the gear ratios a little way from their optimal solutions we may obtain better results for the second problem, the toothed-wheel calculation. This problem is not easy, because starting from two optimisation problems where one is solved after the other, we try to create a structure in which both problems are regarded equal; and we assess global results together with the goal to improve our two-problem design from a rather global perspective. To achieve this goal we have to repeat these two design problems for other values of the gear ratios and compare them with the results achieved in the case of the first structure. After analysing and comparing these results we select the best compromise solution.Mathematical details of the optimisation procedure are given in Chapter 9. Here we concentrate on the issue of new functions for a designer’s notebook. It seems that we need the possibility to store optimisation problems connected with a design problem,so that these optimisation problems can later evolve into a sequence of problems while finding

07 25/7/03 09:54 Page 97

7 Intelligent Personal Assistant – Design Process Modelling

97

the best compromise solution for the global perspective. Additionally to our optimisation problems, design rationale information should be available which is connected to the final project documentation. Inevitably the question arises as to how we are to capture the design process models that later we can build as a computer environment based on the suggested concepts.We have built several experimental applications and we can produce comments which resulted from them. The designers are asked to indicate what should appear from their realised processes in a particular computer environment, because they know best what is important. It is recommendable to work here with scenarios of computer system functioning which were developed and expressed by the designer. We have built models (mainly user interface) of future applications. They show a simulation of the functions of the future system. Standard computer ofﬁce tools were helpful in expressing the designers’ thinking. Because of such external impulses the designer became more creative. One of the reasons for that was that the designer was freed from secondary activities which were not important for the design process, but absorbed time and effort. Earlier design processes were overloaded with non-creative work connected with data processing organisation, tool integration and other tasks. By automating these simple and monotonous activities (like updating information via the internet, automatic naming of components, automatic indexing, automatic billing for material, automatic connecting of design documentation with business information) a part of the load was taken off the designer. He rediscovered submerged creativity. The results were often very much estimated, dedicated feature-based models and knowledge-based engineering models. Offering different computer storage spaces with different representation forms gives the chance to capture what is important in formal and informal knowledge. These applications were based on subjective, actual and future visions of the process. The author observed that many designers have very sensible ideas on how to improve their processes. In most cases, these ideas are based on the integration of different kinds of tools and knowledge sources. This is the best method; the ﬁnished software resembles the human thinking or at least is not far from it. These basic ideas can result in different speciﬁc, complex design process representations. The maze model is the most useful structure in this ﬁeld. It is possible to show the maze in different ways and to create various views. However, we always have to keep in mind the human factor, the past standards of a domain and the acceptance of possible improvements. In accordance with those items we may build the following views: ● ● ●

Chronological development of the design environment. Available resources for each state of the environment. Presentation of past processes. We can add more detailed concepts, if we remember two very essential aspects:

● ●

We have to support the successful management of existing resources of individual designers. We have to support the creation of new components of resources of individual designers.

Although nowadays design problems are becoming more complex, the design processes are being realised more quickly. Both phenomena lead to very rigid domain

07 25/7/03 09:54 Page 98

98

IPA – Concepts and Applications in Engineering

specialisations among designers and eventually to a growing belief in experts and their abilities. It is impossible to understand everything about specialist knowledge. A specialist who is a member of a cooperating team can only describe the results of his work to his colleagues in a selective, limited way. They will not be able to comprehend the various paths of his work in complete detail. Our personalised approach facilitates easier design process documentation. In some way our approach represents reports from the existing real-life environment. The user can put in things as they are in reality, sometimes developing suitable representation with proper comments based on what were assumptions or simpliﬁcations. Consequently even very specialised decisions remain under control. The software developed by us is intended to ﬁt to the standards, concepts and metaphors of computer solutions actually used for real-life design problems. Often, however, we meet with problems in automatic processing. Designers try to understand everything, starting from simple tasks. Software developers need the designers’ acceptance. Education has to be fostered; metaphors are very helpful. However, in general, software developers have to encourage designers to express their ideas in the forms of tools which are widely applied. These are in any case partial formal models of the design processes which can easily be transferred by software developers to a more suitable computer environment. Our approach aids the prolongation of designers’ short- and long-term memory. It supports the cooperation in teams by personal computer environment cooperation.

08 25/7/03 09:54 Page 99

8

Intelligent Personal Assistant – Knowledge Modelling

The problem of knowledge modelling in an intelligent personal assistant is strongly connected with the design process modelling. In the previous chapter we learned that in the designer’s computer notebook we ﬁnd tools for capturing particular design process knowledge and for modelling it. We agreed on the following categories of knowledge: ● ● ●

Procedural Declarative Descriptive

We understood that stored knowledge develops. Knowledge in any representation can be generated on the basis of other knowledge chunks. As an effect of this, any knowledge chunk can later exist in several representations. Real-life problems show that our framework can have even more speciﬁed and sophisticated solutions. The proposals presented in this chapter are based on research done in the ﬁelds of engineering knowledge acquisition, modelling and management for the purposes of intelligent personal assistant building. During our work we cooperated with engineers at different stages of their careers. Some of them were novices; others had long practice and experience. We could observe a wide range of attitudes which were effects of their personal development. In our research cases we used unstructured interviews as our knowledge acquisition method. The interviews took place on many occasions over a period of 3 to 10 months. Most of the interviews were tape recorded. With the permission of the experts being interviewed, written records were then made. Between the interviews there were stages of intensive software development and stages where knowledge engineers tried to clarify the value of the acquired knowledge with the help of additional materials, tools and consultations. Often the search for missing data caused unintentional interruptions. Using software models of future computer applications turned out to be successful. These were computer tools limited to a multiform graphical interface which was intended for speciﬁc domain problems. The presented data were mostly static. The approach supported the creativity of the interviewed designers and provoked them to express new ideas. A programme of meetings and interviews was also prepared. After the ﬁrst contact and after initiating the whole process, the author of this book gave several lectures and presentations explaining the main ideas of the proposed software concept with samples. In some cases we had to conduct laboratory training sessions for engineers and designers (potential future users of the intelligent personal 99

08 25/7/03 09:54 Page 100

100

IPA – Concepts and Applications in Engineering

notebook) to teach them expert system technologies, knowledge modelling techniques, blackboard architecture etc. Most of the designers had experience of procedural processing languages, databases, CAD systems and certain CAE applications. When we presented our methodology to them, they found that there were components which were already well known to them. Some of the engineers had already tried earlier to build their computer tools with functions similar to the intelligent personal assistant and used methods which were known and available to them. All developed applications had an academic and experimental character. The engineers participating in our project belonged to different generations. We noticed that age and experience had a strong inﬂuence on their professional knowledge and the way they represented their knowledge. The novice engineers, fresh from their studies, in general referred to the knowledge they had acquired during their formal education. The knowledge used by them was typically academic, categorised according to academic subjects and even academic textbooks. Exceptions were experiences which they had gathered in laboratories and when doing semester and diploma projects. Although the knowledge in those cases was more complex, it had its limitations as well. The basic approach for knowledge management followed a very academic classiﬁcation based on the names of subjects and topics. Any attempt at knowledge acquisition and knowledge modelling took place within familiar frameworks. In contrast to this group there were the engineers with more than 20 years of professional practice. They structured most of their professional knowledge, probably in its original form, in cases presented ad hoc. They also explained different processes from their past and added various additional comments to different stages of their presentation. Most of them were rather personal assessments. Some of those engineers tended to generalise the problem and showed its wider context, others concentrated only on the main point. The basic knowledge-structuring concepts used by all the designers were those of sub-tasks. For them, a sub-task was a complete unit of knowledge, expressed always in parallel and in different forms. Mostly their classiﬁcation corresponded with ours, introduced in the previous chapter (procedural, declarative, descriptive forms of knowledge). The engineers used sub-tasks to solve a particular problem. Experiences with the applications of these sub-tasks were associated with them. Each sub-task had its own history of development. The principle of sub-tasks is equivalent to the concept function of activities in the maze model structure. Starting with the subtasks, plans were composed for solving new problems. The number of sub-tasks used by a single designer varied from tens to hundreds. As soon as a new design problem appeared, the designers ﬁrst of all veriﬁed that their set of available sub-tasks was complete. The effect of this stage was a speciﬁcation of the sub-tasks and their classiﬁcation into three groups: – Sub-tasks which are available and can be used at once. – Sub-tasks which are available but have to be modiﬁed. – Sub-tasks which are not available and have to be developed or acquired. In the case of the ﬁrst group we get proper cost and time estimations from the designer. In the case of groups (2) and (3) we always have associated risks. Building and developing sub-tasks means creating personal primitives for modelling an intelligent personal assistant structure. In the material which we acquired from real-life examples we found how important a general ﬁrm context is; the

08 25/7/03 09:54 Page 101

8 Intelligent Personal Assistant – Knowledge Modelling

101

functioning, its history and obviously the individual details for understanding the individually articulated sub-tasks. We stated above that the case-based reasoning approach is often used by experienced designers (often without using the casebased reasoning nomenclature) when they present their personal way of solving design problems. In this chapter we have concentrated on the knowledge modelling with the help of personal assistance. We present knowledge modelling on the basis of two examples of personal assistance which were carried out using a case-based approach. These illustrate difﬁculties occurring with engineering knowledge modelling. The ﬁrst example shows the knowledge layer in the case of integrating knowledge-based engineering technology with a design rationale approach and a case-based reasoning method [1, 54, 75, 84] on the basis of a car gear box design [92].

Example 8.1 A complete 3D model of a car gear box for a van was built. A gear box for a van has a relatively complicated structure. The overall system is intended to be a personal environment supporting the process of gear box adaptation. It is possible to change the parameters of particular gears. The resulting parameters of the gears are calculated by a computer system (for standard toothed-wheel calculations) which is integrated with a CAD system. The knowledge-based parametric models, implemented in a CAD system, generate geometrical 3D models of toothed wheels. The system has a database which can store the parameters of the gears which were considered during the design sessions. These data are regarded as the project history – the evolution of the gears. The final project documentation consists of the final CAD system documentation together with the database of the annotated history of the gears. Later in the case-based reasoning approach this information can be used for case selection and as a case adaptation support. The stored information can give background information about the past sessions, telling how the project was carried out, what problems occurred and what strategies were applied. All the information can be visualised in a CAD system; the past project evolution together with comments made at that time by a designer.

Case-based Reasoning and Gear Box Design Case-based reasoning is one of the artificial intelligence technologies. Hereby, the cases are stored solutions of problems solved in the past.In our problem the cases are particular variants of a car gear box. Case-based reasoning involves the solving of new problems on the basis of similar solutions from the past.We assume that designers can store not only the final version of project documentation but also its history, in our case, the development of a car gear box.

08 25/7/03 09:54 Page 102

102

IPA – Concepts and Applications in Engineering

With our system we present its working scenario (single subtask, which can be used iteratively) (Figure 8.1). We arrange that the designer works only with computer documentation. He uses two computer systems: (1) CAD system; (2) computer code for toothed-wheel calculation written in C. We assume that at the beginning the designer does not have any case in the database of cases. The designer develops his project and stores it as his initial case. First, he analyses the structure of the gear box for a van. Because of the complicated structure of the gear box he creates a special procedure for the calculation of toothed wheels.This procedure is encapsulated in codes written in C and in Visual Basic. Then, the designer makes a first attempt at the selection of toothedwheel parameters. Next, he creates knowledge-based models of toothed wheels in the CAD system. Later he builds a complete 3D model of a car gear box in the CAD system. As a result he obtains a geometrical model of a car gear box and he can then observe what his gear box, which consists of gears and many other components, looks like as a geometrically composed structure. He can also examine the relationships between shafts, gears and the gear box body. The designer can continue his work and select new gear parameters, calculate new toothed-wheel parameters, and again he can build a geometrical model of the gear box. However, in this case, he

Iteration of process Routine calculations of gears in gear box (with particular structure) Automatic generation of comments Adding comments, made by designer, to actual version of gear box parameters

Parameters of gear box Connected comments

Storage of design process history as results of multi-iterative, annotated calculations

Database of iterative processes – cases

CAD system 3D parametric and knowledge-based model of gear box

3D parametric and knowledge-based model for particular variant of gear box parameters Figure 8.1 Single sub-task application and its iterative functioning.

08 25/7/03 09:54 Page 103

8 Intelligent Personal Assistant – Knowledge Modelling

only modifies the geometrical model from the previous step. Then, again, he can analyse the relationships in his gear box and repeat the whole cycle. The stage of calculations of the toothed-wheel parameters from each of his steps can be stored in the database. The database has a management system which allows it to go back and forth in the project history tree.The user can observe the various combinations of toothed-wheel parameters.They are ordered in the database according to the history path. Additionally, the user can store his private notes – comments about particular steps. The comments are made partly automatically, and partly by the designer. We assume that the final case in the case-based reasoning approach is the final geometrical model of the gear box together with the history of changes to the toothed-wheel parameters which the user had made. The designer analysing the stored history parameters can at any time generate a geometrical model of the whole gear box from their stored values. When there are stored cases we can look for a case which had, for instance, some geometrical constraints or specific calculation problems during the design process. The overall standard approach of case-based reasoning in our implementation consists of the following stages: ●

● ● ● ●

New problem definition: we can define the parameters of the gear box which we want to find and we can specify some states of the design process which are of interest. Retrieving a suitable case from the past stored cases: we can find the case in the database of cases. Re-using the newly created solution: we can analyse the history of a selected case and try to create our new case on its basis. Revising the used solution: we can try case modifications and observe their geometrical consequences. Retaining the learned case in the database of cases: we can store the results of our attempts as a new case with its new history.

Calculations of Toothed Wheels The application presented was developed for one structural scheme of a car gear box for vans. The application consists of a special management system which integrates a database and a code for toothed-wheel calculations for the considered gear box structure. The management system supports the process of gear calculations. In this case, the process can be applied partly in parallel, partly sequentially. It is possible to do a local optimisation of gears. The resulting sets of toothed-wheel parameters can be stored in a database as design cases.The process of toothed-wheel parameter selection is visualised as a tree.Every node in the tree structure can include comments dealing with this particular step.

103

08 25/7/03 09:54 Page 104

104

IPA – Concepts and Applications in Engineering

Modelling of Toothed Wheels The developed system allows calculated toothed-wheel data to be exported to the CAD system. A global 3D geometrical model of the car gear box considered was built in the CAD system. The overall model consists of three classes of models: ● ● ●

Parameterised models: toothed wheels together with wheel hubs. Knowledge-based models: multiplate clutches. Non-parameterised models: the remaining components.

When the designer has exported the data from the calculation module he can observe a geometrical model of the currently considered gear box variant.

Storage of Design History and Design Process Viewing The overall design process realised in our system can consist of events which are variants of the basic parameters of toothed wheels. The storage system stores a relatively small amount of data. The user can play with the problem, try to operate with these parameters and find optimised solutions. The user is supported with a database of cases calculated in the past which are stored as processes. The processes can contain useful comments. Returning to a past case the user can analyse its particular steps and try to understand the process. At any moment the user can generate a parameterised, knowledgebased 3D model of a gear box in the CAD system and study the past process on the full geometrical level. In the approach presented it was assumed that design process flexibility will be included in the basic toothed-wheel parameters only.The rest of the data connected with toothed wheels, their geometrical details, manufacturing parameters, manufacturing knowledge etc. are implemented in the geometrical models developed in the CAD system. Changes to the basic toothed-wheel parameters influence the gear box geometry via parametric and knowledge-based models.

Searching for Cases and Case Adaptation Each gear box project together with its history can be stored in the database. The user can look for a project, as in the standard casebased reasoning approach. The developed application supports the design process of only one structure of a car gear box. Its usefulness is limited to the assumptions mentioned earlier dealing with the areas and the size of parameterisation and the knowledge-based approach.So if we try to apply the casebased reasoning approach to our computer environment we must be

08 25/7/03 09:54 Page 105

8 Intelligent Personal Assistant – Knowledge Modelling

aware of the fact that our adapted solutions will only revolve around the existing structure of the gear box. The developed application supports a single engineering design sub-task. It is based on knowledge acquired from academic experts on gear box design. The selection of knowledge sources and knowledge modelling was done according to their knowledge and their suggestions. The sub-tasks were intended to support the selection process of the gear box parameters iteratively. The history of achieving a particular result for the whole gear box was regarded as an important source of knowledge about the problem-solving strategy. Finally a database for the storage of the history was established. Navigation of the history (the iterations of the project development) was considered to be an important issue. For that purpose, the tree view structure was used.The ability to add informal comments to the particular variants was also essential. Therefore an automatic generator of comments which indicate the specific values of calculated parameters was created. As the structure of a gear box is complicated, the concept of its calculations is also complex. However, we had expert knowledge to solve such tasks. The problem was programmed in a procedural way because a universal knowledge-based approach would have been more difficult and expensive. The knowledge about the form specification of the toothed wheel was treated as very routine and it was modelled as declarative knowledge in the CAD system. A future development of the applied solutions is planned. However, for the calculations of other structures of gear boxes we have to build different procedural applications. However, we can use the low-level modules from the developed application. The design rationale information generated automatically can be widened easily on new topics which can be inferred from existing data and facts. Alternative manufacturing technologies can be modelled as new modules in the CAD application. The whole environment was developed in the scheduled time period. This fact had a very strong influence on the selected knowledge representations.

Example 8.2 Introduction The following example shows the architecture and functioning of a system supporting machine shaft design [96]. The main goal of the procedure presented is to create prototype software supporting the approach of case-based reasoning in machine design.

105

08 25/7/03 09:54 Page 106

106

IPA – Concepts and Applications in Engineering

It is well known that case-based reasoning in mechanical engineering cannot be limited to final project documentation. Apart from the design rationale information, the intent of the design is very important for the selection of proper cases from the past. The history of the stored project can be very useful for this. However, the history should reflect the key points of the project development. In the literature dealing with these problems we can find groups of researchers who try to achieve this goal on the premise that the designers should be disturbed as little as possible by the whole approach. One of the methods which can help is modelling with features. In our case the features are not only understood as geometrical or physical but also as typical modification sub-tasks. First of all, a number of predefined scenarios (sub-tasks) of selected shaft adaptations are prepared. The input shaft can be modelled in advance with different formalisms (2D, 3D classic universal CAD system primitives, etc.). The first stage of cooperation with the new software is the knowledge-based transformation from input formalism (any of the developed 2D, 3D) to the modelling with features (3D). Later the user can proceed to the adaptation via selecting scenarios (sub-tasks). The whole development history of the designed shaft is then stored in the database.The MS Excel representation serves as an integration platform between the CAD system and the database system.It has functions similar to the blackboard in blackboard architecture. The selection of cases is not only based on the information stored in the project documentation but also on the design rationale information stored in the project history data.

Case-based Reasoning Approach As in the previous example, the cases are stored solutions of problems solved in the past. Case-based reasoning means the solving of new problems on the basis of similar solutions from the past. The approach presented in this example is an attempt to integrate classic case-based reasoning methodology with very specific, engineering-oriented concepts. We supposed that the designer who starts a new design exploits a repository of past projects (cases). He can define geometrical constraints dealing with his new project (shaft) and look into the past projects repository for some project which fits his expectations. The projects stored in the repository (at the beginning) use 2D or 3D standard modelling tools. After finding a suitable solution (project), the designer may transform this model from 2D or 3D to a feature-based 3D model (developed by authors of the system) with the help of a feature recognition module. Later the designer can start

08 25/7/03 09:54 Page 107

8 Intelligent Personal Assistant – Knowledge Modelling

modifications of this project. It is also possible to use other models with features prepared by the authors of the system. While working with the system, each step made by the designer is stored together with the corresponding state of the project.The stored case (in the case-based reasoning approach) is not only the final project for the shaft; it is the project history as well. When the designer wants to keep the newly developed project as the next case he has to store it together with its history. The history may include notes made by the designer during design sessions. The notes make it easier to understand why a certain project was tackled accurately this way.

Modelling of Shaft The developed system is based on the CAD system. In the developed version of the system the existing set of objects was increased to a set of feature-based objects. The newly created software was written in Visual Basic. The proposed set of feature-based models allows the immediate building of the whole shaft in the developed system. As an advantageous consequence the feature-based geometrical model of the shaft can be stored in the form of a data structure of feature-based primitives, and it is possible to edit and redesign it easily or combine several projects. The authors of the system think that the shaft can also be designed as a 2D or 3D geometrical model with the help of standard CAD system tools. This option makes it possible to use projects as design cases which were done without our software. Then the 2D or 3D geometrical models of the shaft which were made with the standard version of the CAD system can be the input model to our system. A special knowledge-based module which is able to transform a 2D model or 3D model into a 3D feature-based model was developed (Figure 8.2). The model transformation can be monitored graphically by the user, and is controlled by parameters influencing the precision of the feature recognition. Additionally to the 3D feature-based primitives supporting the shaft design the authors of the system developed sub-tasks which may be useful during shaft (case) adaptation. These sub-tasks are sequences of actions which have a predefined goal. Some of them are based on simple rules, algorithms, local optimisation problems or on knowledge stored in very specific knowledge bases. In the current version the following sub-tasks are implemented: ● ●

Model transformation (knowledge-based) from 2D into 3D (featurebased). Model transformation (knowledge-based) from 3D (universal) into 3D (feature-based).

107

08 25/7/03 09:54 Page 108

108

IPA – Concepts and Applications in Engineering

...

Designer and multitude of sub-tasks supporting process of shaft design

Sub-task development

2D model

3D model

Knowledge base

2D model Knowledge-based application

3D model Figure 8.2 Designer’s sub-task evolution.

● ● ●

Analysis and correction of the geometrical proportions of a shaft (knowledge-based). Correction of parts of a shaft for placing selected bearings (procedural). Local correction of the shaft geometry with a preselected goal (to make length,diameter or radius fit the surroundings) (optimisation).

With the help of the case-based reasoning approach and sub-tasks we are able to find a suitable shaft and in a few steps to carry out all needed modifications. It looks as if the designer has a clever assistant to whom

08 25/7/03 09:54 Page 109

8 Intelligent Personal Assistant – Knowledge Modelling

he gives orders:install the bearing in the indicated place and correct the form of the shaft.The assistant (computer module) knows how to apply the suitable procedures (stored sub-tasks) and executes the order. Shaft designing is very routine. However, we think that even with this problem the sets of useful sub-tasks may differ from one designer to another. Therefore a period of testing and adaptation to this technology from both sides – designers and system developers – has to be conceded.

Storage of Design History and Design Process Viewing The overall design process realised in our system consists of events which are effects of feature-based model usage. The system is able to store two kinds of information: ● ●

The current (mostly final) state of a project, i.e. all objects with their parameters and integration data. All the steps which were done by the designer to achieve the current stage of the project together with the past stages of the project.

The system stores the sequences of steps together with the corresponding project states.The steps are based on the use of feature-based models. The mentioned sub-tasks can also be treated as design steps. So in the step-space we see usage of both: ● ●

Feature-based primitives (structure of a product). Sub-tasks (structure of the process).

The visualisation of the step-space in the software version of our system has the form of a tree.The tree reflects the history of the project development. It is possible to filter it so that the user can concentrate on a particular level of the shaft description. During the design the user may add notes to each step in the stepspace and explain the design rationale information connected with this step. The acquired design rationale knowledge can then be re-used by the designer himself or by other codesigners. The main goal of collecting the information behind a decision is to exploit the existing knowledge thoroughly, and to better organise the work of cooperating teams. The acquisition of design rationale information is realisable parallel to the design process. Every step done during the design, especially with the help of computer tools, can be represented in the step-space. In the case of feature-based modelling and sub-tasks the step-space is created automatically.The steps show the path of activities done by the designer while creating a design model (successful and unsuccessful steps). Each step done in the CAD system can be stored. Each step (node) in the step-space is connected with a data structure into which

109

08 25/7/03 09:54 Page 110

110

IPA – Concepts and Applications in Engineering

the designer can insert the notes explaining why a particular step was done this way. As design rationale information the designer may add a full description of the considered decision problem together with the information about other alternatives considered and about the limitations of their application. The user has the possibility to view the projects by indicating certain steps of the history tree. He can point to any step in the history tree and observe the state of the project in the CAD system. Parallel to this he has design rationale notes at his disposal. This information is intended to help him to understand why a particular project was done in a certain way. He can move back in the history tree of the project and make parametric corrections of objects or he can add new steps, changing the structure of the history tree.

Searching for Cases and Case Adaptation Each project can be stored in the database together with its history; and as in the standard case-based reasoning approach the user can look for specific projects. Before the user tries to search among the stored cases for the one suitable for solving a new problem he has to define his expectations – the new (incompletely formulated) problem, its parameters, limitations, etc.The data delivered by the user/designer need not be complete. It is sufficient when they contain either global or detailed attributes. In our application the designers’ demands can have geometrical characteristics. As a result of the comparison we obtain selected similar cases. After that the designer can also describe features of the design process. In this case the system looks for similar sequences of steps in the existing (stored) processes. As a result of the searching, the designer may get processes similar to the one he described. When the designer has found a suitable case in the database of cases, he can analyse the stored design process with its design rationale information and at the end he can modify it using a set of prepared sub-tasks.The modified project can be stored as a case with its history path. In the above example we had a multitude of sub-tasks which were modelled in the developed computer environment. The overall environment was based on the concepts used by designers who do many similar projects which are often based on past projects and which are adapted in a very routine way. These assumptions allowed a number of useful sub-tasks to be created. Each sub-task can be modiﬁed according to the corresponding knowledge development. For instance, modules transforming 2D models into 3D on the basis of declarative knowledge are easily developed into more advanced structures. The sub-tasks proposed in this example may be used in any order.

08 25/7/03 09:54 Page 111

8 Intelligent Personal Assistant – Knowledge Modelling

111

In both examples, MS Excel spreadsheets were added to the existing software. The data structures of the developed mechanical models (gears, shafts) were represented on the integrated spreadsheets. The spreadsheets acquire the function of a blackboard in blackboard architecture. Other computer systems like a ﬁnite element module for shaft calculations, a system for shaft manufacturing process modelling and a knowledge-based design rationale generator can be integrated easily and understandably for the designer via spreadsheets. Thus, in general, the process of knowledge modelling in the personal assistant approach consists of the following stages: ● ● ●

Identiﬁcation of a set of domain sub-tasks. Identiﬁcation of knowledge associated with each sub-task. Selecting suitable knowledge representations and building particular applications.

The knowledge modelling has to be looked at in the context of the system development. The structuring of the knowledge modelling process presented above does not contain knowledge components which belong to the so-called meta-knowledge. In every design process we can try to acquire knowledge which is on a higher level and which can help to create a general problem-solving structure. Such knowledge may be directly captured from designers or from documented past cases. As long as the knowledge is described as informal knowledge sources it is widely accepted. However, when we create formal models based upon it we are likely to face problems with its acceptance by the designers. We know by experience that designers try to analyse and understand each single step of such an application. Perhaps creating a complete, understandable, on-line exposition (using suitable graphical representation) of the inference at meta-knowledge level will help in this case.We were not successful with it and as we did not do it on-line and did not use graphics, we had to put a relatively large effort into oral explanations.

08 25/7/03 09:54 Page 112

This page intentionally left blank

09 25/7/03 09:54 Page 113

9

Intelligent Personal Assistant – Optimisation

9.1 Multiobjective Optimisation Layer This chapter describes a multiobjective optimisation layer of an intelligent personal assistant. It portrays the details of the methodology of integrating a maze model of the design process together with a multiobjective optimisation. The approach presented is based on multiobjective, multilevel and hierarchical optimisation methods [31, 55, 70, 82, 103]. Computer technologies have opened new possibilities in engineering design. New methods have appeared which allow a deeper and wider analysis. Analyses done with the help of computer technologies did not only give the chance to prove if the design process was carried out correctly, they also make it possible to ﬁnd optimal design solutions. Moreover, the designer is capable of selecting the best possible solution of a project according to criteria ﬁxed by him. To ﬁnd this solution we can use the methods of single-criterion optimisation. However, single-criterion optimisation in machine design means a simpliﬁcation because real-life design optimisation problems are multicriteria. A multicriteria optimisation problem implies a potential possibility of conﬂicts among criteria which do not cooperate. Conﬂicts require their resolutions for decision making. This is why multicriteria optimisation methods based on a singlecriterion optimisation look quite different from single-criterion optimisation methods themselves. The analysis of a particular design multicriteria optimisation problem is usually more time-consuming than solving the same problem reduced to that of a single criterion. The necessity of using multicriteria optimisation in technical problems is understood by many experts. Additionally, most optimisation problems met in design are nonlinear. As a consequence, multicriteria optimisation in machine design is a relatively expensive computer tool. The multicriteria approach is generally divided into two groups [40, 41]: ● ●

Multiobjective programming methods. Multiattribute methods.

In the case of multiobjective programming methods the optimisation problem is expressed in the form of a feasible domain deﬁned by constraints on decision variables (Figures 9.1, 9.2). Each decision variable vector has its corresponding values of objective functions. Multiattribute problems, however, have a different form. For them we have to select from a set of alternative variants the one which is optimal (Figures 9.3, 9.4). Each variant is characterised by a set of attributes. These two approaches, quite different in their formulation, have many similarities in their 113

09 25/7/03 09:54 Page 114

114

IPA – Concepts and Applications in Engineering Objective space Objective functions (maximised)

Q2(x1, x2) Q (x1) Q(x2)

Q1(x1, x2) Decision variables Mapping of feasible domain into objective space

x1

x1

x2 x2

Constraints

Feasible domain

Decision variable space Figure 9.1 Multiobjective optimisation problem (reduced to 2D decision variable space and 2D objective space).

Objective functions – stiffness of beam (maximised) – weight of beam (minimised)

Decision variables x1

x2

a

b

F – force

Figure 9.2 Example multiobjective optimisation problem.

09 25/7/03 09:54 Page 115

9 Intelligent Personal Assistant – Optimisation

115

Attributes: A1, A2, …

Variants:

V1 V2 . . . . . . . . Vn

Am

.......... .......... .......... Data Vk Variants

Aj

Ai Attribute space

Figure 9.3 Multiattribute optimisation problem. Variants with their attributes

Attributes: A1, A2, …

Variants:

V1 V2

Am

..........

. . . . . . . .

..........

..........

Vn

Data

Fuel consumption (minimised) Aj

Vk

Variants

Price (minimised) Ai Figure 9.4 Example multiattribute optimisation problem.

09 25/7/03 09:54 Page 116

116

IPA – Concepts and Applications in Engineering

Figure 9.5 Example product structure decomposition as a basis for optimisation decomposition.

multiobjective optimisation concepts. Because of this we continue our considerations and concentrate on the multiobjective methods. At the end of this chapter we present an example multiattribute application. Every designer tends to look at the entire design problem as a complex of mutually interacting sub-problems (Figures 9.5, 9.6) [70]. This feature leads to a better description of the reality in which the quality of the design analysis can be improved. In this case it is possible to ﬁnd regularities not only for single components but for the whole unit, i.e. the machine as well. It is a design which joins a rich multitude of single partial problems. The tendency mentioned above evidently contrasts with the development of detailed knowledge. The ﬁelds of specialisation become more and more narrow. Therefore large design problems call for the cooperation of many designers specialising in different disciplines. To make the whole process more effective, it should be better controlled and protected from too much specialisation by single designers. Each specialist makes models of the design process for his own needs, creates its structuring and constructs its actions. He can add a multiobjective optimisation

Vertical vibrations

Transmission vibrations Figure 9.6 Example integration of different design aspects.

09 25/7/03 09:54 Page 117

9 Intelligent Personal Assistant – Optimisation

117

problem to one of his usual activities. However, looking at the wider problem, the designers’ work consists more of single activities. Each of the single activities (done by an individual designer or by a team of designers) represents a single aspect of the whole design process. As the design process is unique, all these aspects may interfere. Common points can appear among different multiaspect approaches. Turning to the formulation of optimisation problems we can say that it means common sub-spaces of decision variable spaces or criteria spaces. Conﬂicts are very probable. They can appear in problems solved by single designers, by teams or by groups of teams. Thus, the problem of decisions and conﬂicts becomes multilevel and hierarchical. To solve a large real-life multiobjective optimisation problem with only the help of multiobjective optimisation methods is in most cases very difﬁcult or even impossible. The main reason for this is the fact that the design process is constructed while designing, and somehow a global formal multiobjective optimisation problem can only be fully understood when the whole design process is ﬁnished. However, a global design process implies the necessity of many decisions by the designers concerning the high dimensionality of criteria space. Making these decisions at the end of the design process looks like a repetition of the procedure. Therefore it is more suitable to decompose the decision-making process at stages which can be connected to activities which are parts of our maze model of the design process (Figure 9.7). Consequently the structure of the design process optimisation turns out to be decomposed, multilevel and multistage.All these structures are typical of large optimisation problems. However, our problem is not only multilevel, it is also multiobjective. There is no general method for solving such problems. It is a result of the possibility that many different structures of the whole problem can be built, with different

Problem 2 Problem 1 Problem 3

Realised process path Figure 9.7 Maze model of design process integrated with multiobjective optimisation problems on realised process path.

09 25/7/03 09:54 Page 118

118

IPA – Concepts and Applications in Engineering

roles and competencies of the decision maker(s).Moreover,the proposed methods are strongly inﬂuenced by their speciﬁc domain focus.Additionally, machine design has its own speciﬁcity. The approach proposed here takes this speciﬁcity into account. Before presenting our proposal of an optimisation approach for large machine design problems, we have to build a formal model of large optimisation problems in machine design.

9.2 Formal Model of a Machine Design Problem With each design activity belonging to a design process we can associate an optimisation problem. We select decision variables which can be mapped into the objective space. Each of the values of the decision variables has to belong to the feasible domain. When the problem is formulated this way we can apply the multiobjective optimisation method. However, this approach may turn out to be quite complicated in the case of bigger problems, i.e. the optimisation of a whole unit, a system, a machine etc. It is the problem of multidimensionality that makes it so difﬁcult. Logically decomposing the whole global problem into a system of interconnected problems with a lower dimensionality may help solve the problem. We illustrate this problem with an example of car design. Each car is designed with the premise that it has to fulﬁl some functions, for instance, it has to transport a certain number of people, achieve a certain speed, have a certain acceleration, brake with a certain effectiveness, move ﬂuently with a particular stability, satisfy safety standards and have an economic fuel consumption. These issues and many others have to be taken into consideration during the design process. Many different models for the respective situations are created. In principle every model can be optimised. However, how can we ﬁnd a better solution for all the models as a whole? How can we tackle the problem of something that is optimal in a speciﬁc situation but does not work in other situations? Effective brakes only do not make a safe car. Here we can only indicate the problem. Structures of real-life problems are more complicated.

Example 9.1 Let us consider the problem of car gear box optimisation [63, 70]. We assume that our gear box has a structure as shown in Figure 9.8. It is a classic gear box with three shafts. We select decision variables for each pair of toothed wheels: numbers of teeth z1 and z2, normal module mn, distance between axles aw, helix angle of the tooth’s line , width of toothed wheel b and correction coefficient x1. We should make sure that one decision variable is common to the whole gear box: the distance between axles. So for the gear box with four gears we obtain (4 6) 1 25 decision variables. For this optimisation problem we can define the following criteria functions: Q 1i – contact ratio of the ith gear. Q 2i – volume of the ith gear.

09 25/7/03 09:54 Page 119

9 Intelligent Personal Assistant – Optimisation

119

aw

Figure 9.8 Scheme of optimised gear box.

Q3i – difference between fatigue durabilities resulting from bending stresses of toothed wheels of the ith gear. i Q4 – difference between fatigue durabilities resulting from bending and contact stresses of lower toothed wheel of the ith gear. A feasible domain for the optimisation problem was defined according to the procedures proposed in [43, 44].Then the number of criteria for the whole problem was 4 4 16. The structure of the problem is depicted in Figure 9.9. We can treat the problems defined above as one global optimisation problem. However, in reality we rarely come across this way of problem solving. Often such a complete optimisation problem is only

...

Gear I

i

i

i

...

i

Q1, Q2, Q3, Q4,

...

Gear II

aw

(z1, z2, mn, , b, x1 (i – number of toothed wheels) )i

Figure 9.9 Structure of optimisation problem.

Gear IV

09 25/7/03 09:54 Page 120

120

IPA – Concepts and Applications in Engineering

known after finishing the whole design process. This is not a suitable time to repeat many of the procedures. In most situations, optimisation is done step by step. For instance, we optimise one gear, and then we formulate and solve the next problem of the next gear. This problem may look different from the previous one; for instance, it may have other decision variables, other constraints and criteria. We can continue, applying this approach to the next gears. However, we should remember that the structure of Figure 9.9 for our primary problem shows only a few variants used in practice.We can create a number of combinations of gears reflecting the order of optimisation of our gear box. For example, we start our toothed-wheel calculations from pair number 1. All the calculations for this pair must be done first and later other toothed-wheel pairs may be calculated (Figure 9.10). It means that pair number 1 was in a privileged situation. For that pair the decision variable common to all problems, i.e. the distance between axles aw, was selected. Consequently, for all succeeding gears we had one decision variable

1

1

1

1

Q1, Q2, Q3, Q4,

Gear I

aw (z1, z2, mn, , b, x1)1

i

i

i

...

i

Q1, Q2, Q3, Q4,

Gear II

...

Gear IV

( z1 , z2 , mn , , b, x1)i (i – number of toothed wheels) Figure 9.10 Structure of optimisation problem with one privileged sub-problem.

aw

09 25/7/03 09:54 Page 121

9 Intelligent Personal Assistant – Optimisation

121

less; or to put it the other way round, we had one constraint more: the fixed value of the distance between axles. It is equally possible to start the optimisation procedure from any other pair of wheels. However, this is always an extreme case, privileging a certain gear. Therefore we should look for an approach which leads to a compromise. After the first intuitive attempt to calculate the toothed wheels we formulate the general dependencies between different components of our optimisation problem.The feasible domain for it is as follows: Fd { x : g p ( x ) 0, h p ( x ) 0}, Fd ⊂ W .

(9.1)

x represents the decision variables, and gp (x), hp(x) the constraints. – Space W is replaced with spaces V, Mv1, Mv2, …, Mvr The feasible domain is now given by: V {v : go (v ) 0, h o (v ) 0}, V ⊂ V i i i Mvi { m : gi (v , m ) 0, h i (v , m ) 0}, Mvi ⊂ Mvi , i 1, 2, K, r .

(9.2)

where V is the feasible set of coordinating variables v, and Mvi are feasible sets for some v pairs of vectors (v, mi). Now we want to look closer at the following multiobjective optimisation problem: 1

1

2

2

r

r

o

max ( f n ( x ), f n ( x ), K, f n ( x ), f ( x )), x ∈ Fd , i i x (v , m ) ∈ U {v } Mvi , i 1, 2, K, r .

(9.3)

v ∈V

where f ni () is the local vector objective function, and f o() the global vector objective function. f o() is assumed additive as follows: -

o

f ( ) ( f1o ( ), f2o ( ), K, fso ( )), r

∀ f jo ( ) ∑ f jio ( ). j

(9.4)

i =1

Many cases in machine design fulfil the last assumption. Examples of such criteria are weight of machine, cost of materials, energy consumption. In simplified terms we may portray it as follows: i

i

f ( ) ( f n ( ), f1oi ( ), f2oi ( ), K, fsio ( )).

(9.5)

09 25/7/03 09:54 Page 122

122

IPA – Concepts and Applications in Engineering

A

B

Figure 9.11 Maze model with two selected nodes.

Now we return to the maze model of the design process and try to integrate it with an optimisation approach. 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 multiobjective optimisation problems [82, 83]. With every node of the maze model can be connected a multiobjective 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. We want to explain these dependencies more precisely. The maze model consists of nodes. The designer can initiate the process of analysis starting from one of the initial nodes. His decision depends on how many existing solutions he has to adopt and where he expects difﬁculties. We assume that the designer started from node A (Figure 9.11) and then he formulated an optimisation problem connected with node A. He selected the decision variables, constraints and criteria and solved his problem with the help of one of the multiobjective optimisation methods and obtained satisfactory results. After analysing the whole problem at its current stage (in node A) the designer decided next to solve a problem connected with node B. He moved to node B and deﬁned a multiobjective optimisation problem connected with this node (Figures 9.12 and 9.13). As before, he solved his problem (not taking into account decision Multiobjective optimisation problem connected with node A

Multiobjective optimisation problem connected with node B

B A Figure 9.12 Maze model with two connected optimisation problems.

09 25/7/03 09:54 Page 123

9 Intelligent Personal Assistant – Optimisation

123

Multiobjective optimisation problem connected with node A

Multiobjective optimisation problem connected with node B

For problem A: – objectives – decision variables – constraints

For problem B: – objectives – decision variables – constraints

B

A

Figure 9.13 Two nodes and their optimisation problems.

variables selected in problem A) with the help of a multiobjective optimisation method and again obtained some satisfying results. Now we want to concentrate on the structure of the whole problem: ﬁrst we solve problem A, and then problem B. The results of problem A can inﬂuence problem B. We can choose between two groups of decision variables, namely those connected with: 1. One particular node of the maze model. 2. More than one particular node of the maze model. Group (1) we call local decision variables, group (2) we call coordination decision variables (Figure 9.14). Multiobjective optimisation problem connected with node A

For problem A: – objectives – local decision variables – constraints

Multiobjective optimisation problem connected with node B

B A

For problem B: – objectives – local decision variables – constraints

For problems A and B: common coordination variables Figure 9.14 Two nodes and their structure of decision variables.

09 25/7/03 09:54 Page 124

124

IPA – Concepts and Applications in Engineering

With respect to the multiobjective optimisation theory we notice the following conﬂicts: with the selection of local decision variables for problem A, with the selection of local decision variables for problem B, and with the selection of coordination variables common to problems A and B. A rational solution is to ﬁnd a compromise. However, a compromise can only be found after having solved the whole problem together as one multiobjective optimisation problem. If we tried to exploit this idea with a maze model it would not be possible because it is assumed that we select our sub-problems while being in the maze model (Figure 9.15). When we start to solve the ﬁrst sub-problem we do not know what the next problem will look like. However, the results of our work with this sub-problem can inﬂuence our decision in the next step, when we go further. If we want to solve our optimisation problem we ﬁrst have to solve the optimisation problem of the node in the maze model, which we selected ﬁrst. Later we can select the next node and try to solve the optimisation problem connected with this node, not caring about what was ﬁxed in the ﬁrst node. Next, we have to solve the two problems together, analyse the conﬂicts between them and ﬁnd the compromise. To move to subsequent nodes in the maze model is a similar procedure. As one way of solving the above optimisation problem the author suggests the application of the method of leading and related sub-problems [70, 82, 83]. However, before going into the details of this method we have to introduce this approach and present the methods and concepts which are essential for understanding it.

Problem 1 q

q

Where to go next?

Now we are here

Path realised up to now Figure 9.15 Path building in maze model and optimisation problems.

09 25/7/03 09:54 Page 125

9 Intelligent Personal Assistant – Optimisation

125

The methodology in question is based on the multiobjective programming methods (e.g., [40]) and the methods of multiobjective, multilevel and hierarchical decision making (e.g., [31, 70, 103]).

9.3 Two-level Optimisation Method The method of two-level optimisation [30] plays a very important role in our further considerations. The principal idea of it is to divide the whole single-optimisation problem into two levels. On the lower level the problem is optimised by some decision variables (called local decision variables) for the ﬁxed values of the rest of the decision variables (called coordination decision variables). The result of the optimisation on the lower level depends on the values of the coordination decision variables. The optimisation problem of the higher level is how to ﬁnd optimal values of coordination decision variables. Then according to [30]: max f (w) max f (v, m) max[max f (v, m)]. w

vm

v

m

(9.6)

The feasible domain is assumed to have the following form: W {(v, m) : g o (v) 0, h o (v) 0, g (v, m) 0, h * (v, m) 0,} * W ⊂ W .

(9.7)

The constraints have to fulﬁl the following conditions: W V Mv, V ⊂ V , Mv ⊂ Mv, V {v : g o (v) 0, h o (v) 0}, Mv {m : g * (v, m) 0, h* (v, m) 0}.

(9.8)

ˆ ), such Consequently the resulting problem has the following form: to ﬁnd (ˆ, m that for each (v, m) ∈ U { } M v∈V

ˆ ) f (v, m). f (vˆ, m

(9.9)

After the decomposition we can solve the whole problem as a structure of integrated and coordinated problems. The lower level problem looks like this: for given ˆ ( ) Mv such that for each m Mv v V to ﬁnd m ˆ (v)) f (v, m(v)). f (v, m

(9.10)

The higher level problem looks like this: to ﬁnd ˆ V such that for each v V ˆ (vˆ)) f (v, m ˆ (v)). f (vˆ, m

(9.11)

09 25/7/03 09:54 Page 126

126

IPA – Concepts and Applications in Engineering

It is very important that the coordination decision variables do not have values for which there are no local decision variables in sub-problems. Many optimisation problems have very speciﬁc structure: Mv ⊂ Mv , , Mv Mv1 Mv 2 K Mvr , Mv1 ⊂ Mv1 , Mv 2 ⊂ Mv 2 , K, Mvr ⊂ Mvr i

i

(9.12)

i

Mvi {m : g (v, m ) 0, hi (v, m ) 0}. i

We assume that the function f (v, m) can have the form of a function ψ f1(v, m1(v)), f2(v, m2(v)), … fr(v, mr(v)). The optimal solution for the lower level looks like this: ˆ (v) (m ˆ 1 (v), m ˆ 2 (v), K, m ˆ r (v)). m

(9.13)

The optimal values of objective functions of the lower level are: ˆ (v)) [ f1 (v, m ˆ 1 (v)), f 2 (v, m ˆ 2 (v)), K, f r (v, m ˆ r (v))]. f (v, m

(9.14)

The higher level problem looks like the one before.

9.4 Concepts of Criteria Space Ordering One of the most important aspects in multiobjective optimisation is the relationship ordering the criteria space [3, 6, 21, 40, 41, 45]. We begin with the situation which we deﬁned as a multiobjective optimisation problem in the decision variable space; for each feasible solution in this space we found its mapping in the criteria space. Consequently, we can sign a picture of the feasible domain in the criteria space as → S; –f 1, –f 2 S;–f 1 (f 11, f 12, …, f 1k ), –f 2 ( f 21, f 22 , …, f 2k). For the criteria space we can create different principles of its ordering. There are three concepts, used very often in different multiobjective optimisation methods which have a relatively high practical importance: Optimality in Pareto sense:–f 1 is polyoptimal if  ∃–f 2 S, f 2i f 1i for each value of i {1, 2, …, k} and for at least one l, f 2l f 1l , l {1, 2, …, k}. L 1 1 L 2 ● Lexicographic order: f is polyoptimal if f f . The relationship is under– f1 f2 – – stood as the following: – in the ordinary sense, and –f 1 f 2 if such a j, – – 1 j k exists that f 1i f 2i (i 1, 2, …, j 1), f 1j f 2j for any relationship f 1i , f 2i for i j. ● Linear order: this relationship is used very often in the case of an approach with a scalar function (–f ()). The polyoptimal solution is the point–f 1 with the highest value of the scalar function (–f 1). In Figures 9.16–9.19, examples of the above order for the two-dimensional criteria space are shown. Most of the multiobjective optimisation methods are based on one of the orders described or their combinations. ●

09 25/7/03 09:54 Page 127

9 Intelligent Personal Assistant – Optimisation

127

Not comparable

Worse

Better

Not comparable

Both objectives maximised Figure 9.16 Attempt at objective space ordering.

There is no better point than this There is no better point than this

There is no better point than this

Both objectives maximised Figure 9.17 Selection of Pareto-optimal set.

Both objectives maximised Figure 9.18 Lexicographic order.

09 25/7/03 09:54 Page 128

128

IPA – Concepts and Applications in Engineering

Figure 9.19 Linear order with scalar function.

9.5 Relationships Between Different Concepts of Criteria Space Ordering In this section we explain the relationships between different concepts of criteria space ordering. These relationships are important for understanding the method of leading and related sub-problems. The following relationships are possible (Figure 9.20): ●

●

Relationship between a Pareto-optimal solution and optimality according to the linear ordering with a scalar function. This problem was analysed in detail by many authors. Here we do not intend to present the full spectrum of concepts and theorems.We will only concentrate on practical issues. If certain conditions are fulﬁlled we can ﬁnd for any Pareto-optimal solution a suitable linear function which is (then) a combination of a criteria function and a variant of a criteria function and produces the same result. It is illustrated in Figure 9.19. The opposite is equally true. Relationship between a Pareto-optimal solution and a lexicographic order [3, 6]. It is proved that under certain conditions a solution selected by a lexicographic order belongs to the set of Pareto-optimal solutions. Under certain conditions the reverse case is also true. Optimality in Pareto sense

Lexicographic order

Linear order with scalar function

Figure 9.20 Relationships between different concepts of criteria space ordering.

09 25/7/03 09:54 Page 129

9 Intelligent Personal Assistant – Optimisation ●

129

Relationship between a lexicographic order and optimality according to the linear order and scalar function. It is proved in [21] that it is not possible to ﬁnd a real function which reﬂects a lexicographic order.

9.6 A Survey of Selected Multiobjective Optimisation Methods This section presents a survey of selected multiobjective optimisation methods which are used in the approach recommended for large optimisation problems in machine design.

9.6.1 Methods Based on the Value Function Concept A value function is a concept of a real function which has to model the preferences of the decision maker [45]. It is a scalar function deﬁned in the criteria space. Its value is the function of a vector criteria function. It is deﬁned as follows: w(x) w( f (x)).

(9.15)

When we use a value function which reﬂects the preferences of the decision maker we can substitute our multiobjective problem for a single-criterion optimisation problem. However, the biggest difﬁculty is to ﬁnd the value function of a particular decision maker and a particular optimisation problem. There are many different models at our disposal enabling us to confront the difﬁculties. The most popular is the additive one. Methods for identifying the value function of a particular designer have already been developed and are presented here (Figures 9.21, 9.22).

The most preferred Pareto-optimal point

Isopreference curves

Figure 9.21 Approach based on value function concept.

09 25/7/03 09:54 Page 130

130

IPA – Concepts and Applications in Engineering a) testing if additive value function is acceptable b) assumption: value function has additive form (2 objectives): w() = λ1w1(f 1())+λ2w2(f 2()) c) interactive (interaction with decision maker) evaluation of value function no. 1 w1(f 1()) 1.0 0.5 0.0 f 1() Range of change of objective function

d) evaluation of value function no. 2. e) formula building Figure 9.22 Concept methods for value function estimation [45].

9.6.2 Methods of Interactive Multiobjective Optimisation There is a very speciﬁc group of methods of multiobjective optimisation [26]. They are based on interactive cooperation with the human decision maker during processing. The human – algorithm interaction can be based on different concepts. In practice this means that depending on the method used the decision maker has to give the respective kind of information. An example method follows. The method is called interactive goal programming [23]. It is based on the principles of goal programming: min d( f (x), b), x∈Fd

(9.16)

where the criteria function is –f (x), b the vector of the goal values deﬁned by the decision maker for all criteria, x is the decision variable vector, Fd feasible domain and d certain metrics. The method exploits the principle of the value function which is known to the decision maker implicitly. This means that the decision maker knows this function, has a feeling for it and can answer questions concerning it, but he does not know its usage. It is also likely that this implicit value function has an additive form. Then the decision maker, knowing this function implicitly, is supposed to answer questions which allow estimation of the local parameters of this function. If this w(–f ()) is a value function then it may be deﬁned as follows: fj – is a reference criterion,

09 25/7/03 09:54 Page 131

9 Intelligent Personal Assistant – Optimisation

131

If we change one unit of the criterion fj we have to estimate the equivalent changes of another criterion. For the decision maker both the following points should be equivalent: ( f1 , f 2 , K, f k ) and ( f1 , K, fi ∆fi , K, f j 1, K, f k ).

(9.17)

After that we calculate coefﬁcients in the following way: i

∂w( f ( )) / ∂fi ( ) 1 ∆fi ∂w( f ( )) / ∂f j ( )

for i 1, 2, K, k.

(9.18)

This step has to be taken in cooperation with the decision maker. The information from the decision maker gives the local evaluation of the value function in the particular point x Fd, for function–f (x). Later the process of optimisation according to that information is carried out by computer. The result of that z gives the vector in the decision variable space: d z x. (9.19) As a next step the decision maker, analysing carefully the results of the computer calculations, has to evaluate interactively to what extent his earlier evaluation was valid: w( f (x + td )); t , 0 t 1

(9.20)

and again he evaluates the coefﬁcients using Relation 9.18 and the whole procedure repeats itself. This procedure ﬁnishes when the decision maker notices that the results are not worth continuing. The approach presented above was one of the ﬁrst of its kind. It is based on the concept of building a partial preferential model (modelled as value function) of a particular decision maker.

9.6.3 Method of Constraints and Utopia Solution There is a method of multiobjective decision making which may be very useful for our large decision problem. It is called the constraint method (e.g., Lin [49]). We assume that there is a multiobjective programming problem: max f (x), x ∈ Fd , f ( f1 , f 2 , K, f k ).

(9.21)

This is solved in the following way. We select one, for instance the pth objective function, and formulate the following problem: max f p , x ∈ Fd , p

f ( x) ε , where p

f (x) ( f1 (x), ..., f p−1 (x), f p+1 (x), ..., f k (x)).

(9.22)

09 25/7/03 09:54 Page 132

132

IPA – Concepts and Applications in Engineering

f utopia (f1 max , f2 max ) max fp

f p(x) ε

Figure 9.23 Method of constraints and utopia solution.

is the parameter with the help of which we can control some bounds on objective functions. The problem is how to select the values of . Normally we estimate the ranges of particular objective functions by solving suitable single-objective problems: min fi fi min and max fi fi max for every ith objective. After that stage we can try to select the values of from the proper ranges and try to solve the above problem. Incidentally, this algorithm uses the concept of the utopia (or ideal solution) point. The utopia point is deﬁned as (in the case of maximisation of all objective functions): f

utopia

( f1 max , f 2 max , K, f k max ).

(9.23)

This point is rarely achieved, however, but it can be useful for measuring the distance to the solution already found (Figure 9.23).

9.6.4 Lexicographic Approach The lexicographic method [3] is used in practical cases for ﬁnding a polyoptimal solution according to the lexicographic order. The m-dimensional problem is substituted with a sequence of problems: Problem 1 max f1 (x) f1o , x ∈ Fd .

(9.24)

max f 2 (x) f 2o , x ∈ Fd ^ f1 (x) ≥ f1o .

(9.25)

Problem 2

…

09 25/7/03 09:54 Page 133

9 Intelligent Personal Assistant – Optimisation

133

Problem m max f m (x) f mo , x ∈ Fd ^ f1 (x) f1o , ^ f 2 (x) f 2o , K ^ f m−1 (x) f mo−1 .

(9.26)

The ordering criteria from 1 to m are shown as an example. This order deﬁnition shows the decision makers’ preferences. It can be of any hierarchy.

9.6.5 Characteristics of Multiobjective Optimisation Methods If we compare single-objective optimisation methods with multiobjective optimisation methods we notice that the multiobjective approach is less arbitrary. In case of single-objective optimisation we ﬁrst formulate an optimisation problem and later this problem is solved, more or less automatically with a particular optimisation method (we do not consider analysis with the goal of improving the ﬁnal result or analysing the ﬁnal solution sensitivity – so-called post-optimal analysis). In the case of the multiobjective approach the decision maker has to cooperate on the further stages with a multiobjective optimisation method which is not necessary with a single-objective optimisation. For instance, when he solves his problem in the Pareto-optimality sense and obtains a representation of the Pareto set he has to make his ﬁnal decision: i.e., to select one solution. In many other methods he has to express his preferences earlier, before he knows any points from the Pareto representation set. Most of the multiobjective optimisation methods are based on single-criterion optimisation. In the literature we meet various classiﬁcations of multiobjective optimisation methods [26, 40, 41]. Here we present only a very practical classiﬁcation [40, 41] which divides multiobjective methods into the following groups: 1. Methods with preferences articulated a priori. In these methods the decision maker expresses his preferences before starting the process of maximisation. The process of maximisation itself is done without the decision maker’s will as in a single-objective optimisation. In most cases we get one ﬁnal result. As examples we can list methods based on the concepts of utility and value functions, methods with a utopia point, goal programming and the lexicographic approach. 2. Methods with preferences articulated progressively (interactive methods). The decision making by the decision maker and the maximisation are done one after the other as a repeatable cycle. This group of methods is often classiﬁed in some detail according to the kind of information provided by the decision maker. The interactive goal programming method is an example of this kind of approach. 3. Methods with preferences articulated a posteriori. Hereby the whole problem is solved ﬁrst with the help of any multiobjective optimisation method which gives the set of Pareto-optimal solutions. Later the decision maker selects the best solution, according to his preferences.

09 25/7/03 09:54 Page 134

134

IPA – Concepts and Applications in Engineering

As we can see, methods (1)–(3) are classiﬁed according to the growing amount of information generated during problem solving. Accompanying this categorisation we have the growing costs of the calculations. Parallel to this, the role of decision maker in the optimisation process changes. Moving from (1) to (3), the methods become less demanding for the decision maker. These three aspects, acquired information, cost of calculation, and role of the decision maker, play key roles when deciding on selection of a multiobjective optimisation method for a certain practical case.

9.7 Additional Assumptions in the Formulation of Large Optimisation Problems in Machine Design In Section 9.2 we assumed that an optimisation problem in machine design was multiobjective and we depicted the multilevel structure of the whole problem there. The speciﬁc structure of the problem suggests to us that we conduct the overall optimisation in the following stages [70]: 1. Conﬂict resolution within local sub-problems. 2. Conﬂict resolution among local sub-problems. When we analyse different engineering problems in multiobjective optimisation we may come to the conclusion that engineering knowledge is well deﬁned, especially on the local level. It means that there are sub-problems where the optimisation of only one component or aspect is considered. On the higher level, however, the matter of knowledge is not that simple. Knowledge exists, but it is not clearly expressed. Often it is even used without a deeper understanding. Under these circumstances we should treat the concept of using different polyoptimality deﬁnitions in different sub-problems and in coordination problems with indifference. On the lower level, where we have knowledge about speciﬁc domain problems, it is recommended to use methods which cost less – those where the preferences are articulated a priori and those where the preferences are articulated progressively. On the coordination level we can use the method of an a posteriori articulation of preferences because mostly there is no knowledge from the decision maker at all or only knowledge which is difﬁcult to articulate. We also think that every large problem can be solved optimally in the Pareto optimality sense. We expect that the decision maker solving the global problem maximises his global value function wG( f()) which models his preferences. The – global value function wG( f()) can be known explicitly or implicitly. We assume – as well that there is only one decision maker. In the case of more decision makers they are supposed to discuss the matter and to come to one common conclusion. When applying a Pareto-optimality approach we suppose that any decision (selection of one Pareto-optimal solution) is based on the maximisation of a particular value function which exists, but is only known implicitly. We face a similar situation with methods of progressive articulation of preferences. There we mostly have a ﬁnal solution and a sequence of solutions leading to this ﬁnal solution. In this case we can also take for granted that the decision maker maximises his value function known implicitly, when making his decisions. Using methods with preferences articulated a priori we have from the beginning a value function or any other preference structure. As mentioned earlier, the

09 25/7/03 09:54 Page 135

9 Intelligent Personal Assistant – Optimisation wG (f ()) =

w L1 (f1()) =

135 r

Σ w Li (f i ())

i =1

k1

Σ w L1j (f j1()) j=1

w L2 (f 2()) =

k2

Σ w L2j (f j2()) j=1 f 2()

f 1()

Second optimisation sub-problem

First optimisation sub-problem

Figure 9.24 Structure of value functions for two sub-problems.

lexicographic order is an exception, as it does not have a real function reﬂecting its ordering. All these examples work on the assumption that the overall optimisation process leads to the ﬁnal optimisation of a global value function wG(–f()). In Section 9.2, we stated that the overall optimisation problem has a multilevel structure. Local optimisation problems (selection of local decision variables) are on the lower level and coordination problems (selection of coordination decision variables) are on the higher level. Conﬂicts may appear both within and among the local sub-problems. Conﬂicts of the ﬁrst kind can be solved within local sub-problems. Conﬂicts of the second kind can be solved by ﬁnding a compromise among local sub-problems. Our next assumption says that our global value function wG(–f()) can be decomposed into local value functions wLj() optimised in each local sub-problem (Geoffrion and Hogan [31], Keeney and Raiffa [45], Pokojski [70]). In the local subproblems we maximise the local value functions wLj(); on the coordination level we optimise the global value function wG( f()), wG(wL1(–f 1()), …, wLr(–f r())) (Figures – 9.24, 9.25). The next important idea is the possibility to use different optimality concepts in different local sub-problems and on the coordination level as well.As a consequence we have different multiobjective optimisation methods in different local sub-problems and on the coordination level. Furthermore, we assume that all local value functions and global value functions are additive and have the following forms: r

w G ( f ( )) ∑ w Li ( f ( )), i

i =1 ki

i w ( f ( )) ∑ w Li j ( f j ( )); Li

i

(9.27) i 1, 2, K, r ,

j =1

v ŒV = {v : go ( v ) ≥ 0 , ho ( v ) = 0 } v

...

m Œ Mvi = {m : g i ( v , m ) ≥ 0 , h i ( v , m ) = 0} i

i

i

i

Figure 9.25 Structure of feasible domains.

...

09 25/7/03 09:54 Page 136

136

IPA – Concepts and Applications in Engineering r

max( w G ( f ()) = S w Li ( f i ())) i =1

v Œ V = {v : go ( v ) ≥ 0 , ho ( v ) = 0 } i

w Li( f ())

v ki

max(w Li ( f ()) = S w jLi ( f ij())) i

...

j =1 i

m Œ Mvi = {m : gi ( v , m ) ≥ 0 , h i ( v , m ) = 0 } i

i

...

i

Figure 9.26 Procedure of decomposition and coordination with value functions.

so the whole problem can be solved according to the scheme presented in Figure 9.26 [31, 70]. We can easily imagine the structures of the problem presented in Figures 9.27 and 9.28. To explain a very important feature of the decomposed structures we want to consider the jth local sub-problem separately. It means we assume full freedom in selecting the coordination decision variables v (only constraints for the coordination decision variables are considered): j

j

max f (x ), j

, x ∈ Fdj ⊂ V Mvj V {v : g (v) 0, h o (v) 0,}

(9.28)

o

j

j

j

Mvj {m : g (v, m ) 0, h j (v, m ) 0,} j

. V ⊂ V ; Mvj ⊂ Mvj The above problem solution was developed without taking into account the connections with the rest of the local sub-problems. The whole procedure leads to maximisation according to a selected concept of optimality. There are three concepts of optimality to choose from: ●

In a Pareto sense, set of solutions PP. Solution in Pareto sense

Solution in Pareto sense

...

... Maximisation with scalar function

Figure 9.27 Different orderings in different sub-problems – ﬁrst example.

09 25/7/03 09:54 Page 137

9 Intelligent Personal Assistant – Optimisation

137

Solution in Pareto sense

... Maximisation with scalar function Figure 9.28 Different orderings in different sub-problems – second example.

● ●

As lexicographic order, solution PL. As maximisation of value function, solution PS.

We have as a condition that the sets PP, PL, PS are sets in the criteria space. Coordinating the procedure of solving our selected sub-problem with other sub-problems means additional constraints. Adding further constraints (to our problem) leads to results no better than those which we obtained when solving a sub-problem separately, or even to worse results. So solving any local sub-problem separately gives the best results when we think of coordination afterwards. Coordination is only likely to make these results worse. Consequently the results achieved separately in each local sub-problem give the utopia point for the coordination level; they are also a good reference solution for the coordination problem. The above presentation has focused on the main ideas and not on its mathematical details. A more complete description is presented in [70]. As shown before, it is possible to create various structures of the whole problem. However, one of them we regard especially useful. It is called the method of leading and related sub-problems and is explained in the next section.

9.8 Method of Leading and Related Sub-problems In Section 9.7, Figure 9.26 we proposed procedure of decomposition and coordination with value functions wG(–f()) and wLj(). If we try to use the two-level hierarchical model together with the two-level value function, the sub-problems can be optimisation problems of separate components, units and phenomena (e.g., vibrations, ﬂuid ﬂow, etc. – different nodes in the maze path). The coordination problem deﬁned on the value functions of sub-problems can be, for instance, the design process of a unit or a machine (two nodes or more in the maze). In the case of subproblems we suppose that there is some design knowledge which allows the direct control of the process of multicriteria decision making. On the coordination level it is more difﬁcult to compare local value functions with each other. Then if the global value function: w G ()

(9.29)

09 25/7/03 09:54 Page 138

138

IPA – Concepts and Applications in Engineering

and local value functions: 1

r

w G (w L1 ( f ()), …, w Lr ( f ()))

(9.30)

are formulated explicitly then the whole procedure looks directly like in the Figure 9.26. If they are known only implicitly we can try to use a more speciﬁc approach. The large number of multiobjective decision-making methods are based on substituting the primal multiobjective problem with a sequence of single-objective parametric problems. In this case the multiobjectivity is encapsulated in a “parametric” problem. One of the most popular forms of “parametric” problems is the use of the scalar function in the form of a linear combination of objective functions. We should remember that a function which is a linear combination of objective functions is a speciﬁc case of a value function. Therefore, we propose the use of different “parametric” multiobjective decisionmaking methods in each problem from Figure 9.26 (coordination problem and optimisation problems in sub-problems). We get the ﬁnal (global optimal) solution by solving a sequence of all possible combinations of parameters of parametric problems. For instance, when we have two sub-problems we can solve one of them with the help of the explicitly known (earlier identiﬁed) value function. For the second sub-problem we then can consider the linear combination of objective functions and try to ﬁnd the representation of Pareto-optimal solutions. The problem of coordination also can be solved with the help of the linear combination of the objective functions. The second sub-problem and the coordination problem are parametric. In the case of parametric problems the decision maker expresses his preferences by selecting the most preferred Pareto-optimal solutions according to his implicitly known value function. Of course, it is possible to create many similar structures on the basis of the known multiobjective decision-making methods and procedure from Figure 9.26. However, more important than that seems to be the methodology of creating the above structures. It is expensive to use multiobjective methods, especially for real practical, technical problems which deal with more complicated systems. On the other hand, there are a large number of different multiobjective decision-making methods with different claims on the problem and on the decision maker. When we use the above idea and create new structures on the basis of procedure from Figure 9.26 we can create our own (i.e., the most suitable) way of solving large decision problems. Let us brieﬂy repeat a method from Section 9.6.3 to make the following approach easier to understand. There we assumed that there is a multiobjective programming problem: max f (x), x ∈ Fd , f ( f1 , f 2 , K, f k ).

(9.31)

We select one, for instance pth objective function, and formulate the following problem: max f p , x ∈ Fd , p

f ( x ) ≥ ,

(9.32)

09 25/7/03 09:54 Page 139

9 Intelligent Personal Assistant – Optimisation

139

where p

f (x) ( f1 (x), K, f p−1 (x), f p+1 (x), K, f k (x)) and ε is the parameter with the help of which we can control some bounds on objective functions. Now we want to return to the algorithm from Figure 9.26 and the modiﬁcations proposed above. What would happen if we used an -constraint algorithm for solving the coordination problem? We can ﬁnd such algorithms in [70, 103], which were proposed independently. In Shimizu’s and Aiyoshi’s paper we ﬁnd a very detailed optimality analysis. Pokojski’s paper, however, concentrates more on the different structure variations, especially for the purposes of supporting design processes. Pokojski’s algorithm is known as the method of leading and related sub-problems. We assume that we can use the additive value function model for modelling preferences. The model of the additive value function is used for the sub-problem decision problems as well as for the coordination level. 1

r

2

w G ( ) w G ( f ( ), f ( ), K, f ( )), 1

r

2

w G ( ) w G (w L1 ( f ( )), w L2 ( f ( )), K, w Lr ( f ( )), r

w G ( ) ∑ w Lj ( f ( )), j

(9.33)

j =1 nj

w Lj ( ) ∑ wiLj ( fi j ( )), i =1

where wG() is the global value function, w Lj( f j()) the local value functions and wiLj () – value functions of single scalar objective functions. The proposed method consists of the following steps (Figure 9.29): Step 1. According to the deﬁnition used of a polyoptimal solution and the selected method of multiobjective optimisation, each of the sub-problems must be solved separately from other local sub-problems. j

j

max f (x ), j , x ∈ Fdj ⊂ V Mvj j

j

x j (v , m ), V {v : g (v) 0, h o (v) 0},

(9.34)

o

j

j

j

Mvj {m : g (v, m 0, h j (v, m ) 0}, j

, j 1, K,, r . V ⊂ V ; Mvj ⊂ Mvj The coordination decision variables v, at this stage of the procedure, are treated like local decision variables. This means that we can get results with different values of the coordination variables v j in each sub-problem. The global problem will not be coordinated.

09 25/7/03 09:54 Page 140

140

IPA – Concepts and Applications in Engineering Step 1 Problem j

– Each sub-problem solved separately max f j ( x j ) x j ∈ F d ⊂ V × Mvj j

x = ( v j, m j ) j

{ } {m j: g j (v, m j) ≥ 0 , h j ( v , m j ) = 0 }

V = v : go ( v ) ≥ 0 , h o ( v ) = 0 Mvj =

V ⊂ V ; M vj ⊂ M vj j = 1, ...., r Step 2 p

p

max f ( v , m ) v ∈V p

p

f ( v, m )

v

p

Information about fulfilling ε-constraint

v

p

j

j

w Lj( f ( v , m )) ≥ ε j j m ∈ Mvj

max f ( v , m ) p

m ∈ Mvp

Figure 9.29 Method of leading and related sub-problems.

The solutions which we get separately fulﬁl the roles of reference solutions (utopia point) at the stage of the coordination. The coordination can give results no better than those achieved from the separate optimisation of single sub-problems. Coordination for a single sub-problem is to add new coordination constraints. Step 2. We select one of the sub-problems as the leading one. The other problems are called related. For related problems the decision maker has to express his preferences a priori. The decision maker has to identify his own value function w Lj(f j()) with – the help of interactive routines. Every function w Lj(f j()) (except in the leading prob– lem) fulﬁls the role of constraints in a coordination problem. Starting from an j, which is worse in Pareto’s sense than the solution treated separately as the best, we can create series of the following problems: j

j

w Lj ( f (v, m )) ≥ j , j

m ∈ Mvj ,

(9.35)

For the ε j aspiration level of jth sub-problem we can connect the process of selecting coordination variables v to the selection of the local variables mp in the leading subproblem. This has the following form: p

p

max f (v, m ), p

v ∈V , m ∈ Mvp .

(9.36)

09 25/7/03 09:54 Page 141

9 Intelligent Personal Assistant – Optimisation

141

Table 9.1 Results of a car gear box optimisation with the method of leading and related sub-problems. Gear

aw 103 [m]

b 103 [m]

[rad]

z1

z2

mn x1

103 x2 [m]

x1

Q1i

Q2i 106 [m3]

Q i3 [km]

Q4i [km]

I

A B C D

67.753 66.741 66.941 68.000

14.83 15.28 15.28 19.7

0.485 0.456 0.456 0.471

18 18 18 15

41 41 41 33

2.0 2.0 2.0 2.5

0.555 0.536 0.646 0.275

0.553 0.535 0.535 0.362

1.24 1.27 1.25 1.27

13.42 13.44 13.53 18.28

124 11308 124219 6111718

118 151317 131103 7554389

II

A B C D

67.033 66.741 66.941 68.000

15.33 15.64 15.40 15.10

0.548 0.565 0.564 0.506

31 31 31 20

44 44 44 27

1.5 1.5 1.5 2.5

0.820 0.094 0.266 0.356

0.793 0.001 0.265 0.275

1.37 1.58 1.53 1.43

12.00 12.28 12.13 12.84

981499 477496 14459 17616732

7708964 13875694 12051404 1320472

III

A B C D

66.791 66.741 66.941 68.000

16.88 17.05 16.80 15.80

0.639 0.631 0.637 0.541

29 29 29 21

32 32 32 24

1.75 1.75 1.75 2.5

0.172 0.381 0.333 1.116

0.168 0.228 0.201 0.500

1.41 1.38 1.38 1.18

13.12 13.23 13.12 13.13

9029 449600 351 105269451

440657819 466762706 458590466 182935298

IV

A B C D

66.866 66.741 66.941 68.000

17.03 17.91 16.99 17.00

0.576 0.576 0.576 0.541

27 27 27 17

47 47 47 29

1.5 1.5 1.5 2.5

0.483 0.391 0.538 0.394

0.415 0.294 0.440 0.314

1.44 1.47 1.42 1.37

13.85 14.54 13.85 14.97

7752 11917353 7161 6159981499

287279727 422791888 287823899 32812971

Gear I – leading sub-problem; A – results of sub-problems solved separately; B – results of coordination with aspiration levels: 0.5, 0.5, 0.5; C – results of coordination with aspiration levels: 0.7, 0.9, 0.9; D – parameters of existing gear box.

Problem 1

Step 1 Solving problem 1 Step 2 Solving problems 1 and 2 with the help of method of leading and related sub-problems

Problem 1

Problem 2

Problem 1

Problem 2

Problem 3

Step 3 Solving problems 1, 2 and 3 with the help of method of leading and related sub-problems

Figure 9.30 Steps of global approach to optimisation problem in maze model.

09 25/7/03 09:54 Page 142

142

IPA – Concepts and Applications in Engineering

Database of variants in node i List of variants available in node i – initial state

Database of variants in node j List of variants available in node j – initial state

List of variants available in node j – state after decision making in i

Problem history tree

Sets of variants from stage selected in history tree

Figure 9.31 Example system: maze model integrated with multiattribute variant of method of leading and related sub-problems.

By changing the values εj in the related sub-problems the user can conduct the process of scanning compromises at the coordination level and solve the most important (leading) problem himself. The overall procedure can start with two subproblems, and later it can be increased to more sub-problems, but the coordination should always be conducted as the global problem. The value function used in the related sub-problems is a good and understandable quality measure for the designer/decision maker. The sets of solutions which are optimal in Pareto’s sense and which are separately calculated are also very understandable to the designer. It is the same with the problem of explaining the distance between the best solutions separately achieved and those solutions achieved during the coordination. These categories are easily imaginable without using the multiobjective decisionmaking nomenclature. In Figures 9.27 and 9.28 two different variants of the leading and related sub-problems method are shown. A variant from Figure 9.28 was used for the problem of car gear box optimisation. Partial results from this problem are presented in Table 9.1.

09 25/7/03 09:54 Page 143

9 Intelligent Personal Assistant – Optimisation

143

Up to now, the above idea (i.e., the integration of a maze model together with a multiobjective, multilevel and hierarchical optimisation method) has been implemented separately. The multiobjective optimisation method presented (leading and related sub-problems) was used for the optimisation of car gear boxes [63, 70] and some kinds of car dynamics problems [71, 72]. Several approaches which changed the structures of the problems were also considered. However, the process of the optimisation problem formulation was done by hand. The ﬁrst computer implementation of the above structure (integrated maze model together with multiobjective optimisation, Figure 9.30) was realised for a multiattribute optimisation [2] (Figure 9.31). It was written in MS C

and it can cooperate with relational databases where alternatives for particular sub-problems are stored.

09 25/7/03 09:54 Page 144

This page intentionally left blank

10 25/7/03 09:54 Page 145

10

Intelligent Personal Assistant – Implementation

The intelligent personal assistant to the designer is a concept of speciﬁc software which can be realised as a computer application in many different ways. The author and his cooperating team developed a few computer intelligent personal assistant implementations. They were always built with individually selected computer tools. The main goal of these projects was to verify, in reality, different ideas and to look for their common general issues. The backbone of each personal assistant layer in the developed design support environments was based on relational database technology [12, 91] (Figures 10.1, 10.2). The user’s interface for these applications was prepared in a database environment with the use of MS Visual Basic. It was assumed in the intelligent personal assistant concept presented that we have to integrate a multitude of designers’ personal knowledge sources. Each of these knowledge sources operates on certain data structures. In the previous chapters were presented different details of the functioning of the intelligent personal assistant; here we concentrate on its implementation. We start our presentation from the most general implementation and we ﬁnish it with very speciﬁc solutions.

User

Software agents

WWW

MS Windows tools

Expert system shell

Case-based reasoning module

Common database: – sub-processes – design variables – design process plans – knowledge and information

· · · · · Optional modules Figure 10.1 Scheme of computer system. 145

External CAD, CAE systems

10 25/7/03 09:54 Page 146

146

IPA – Concepts and Applications in Engineering

Common declaration

Specific data structure: project nodes

Structure-specific tasks

Specific data structure: expert system rules

Structure-specific tasks

Specific data structure: external applications

Structure-specific tasks

Specific data structure: user defined

Structure-specific tasks

Specific data structure:

Structure-specific tasks

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

Common links between all data items

Common index and search system

Common data presentation

World Wide Web Interface

Figure 10.2 Data structure of computer system.

In each case, ﬁrst we had to prepare storage space for the above-mentioned data structures.With the help of the following groups of data structures the whole problem was presented: ● ● ● ● ●

Structures modelling particular design activities – nodes in the maze model of the design process. Structures modelling groups of rules used in the expert system approach. Structures modelling lists of applications integrated with certain activity. Structures modelling data structures deﬁned by user/designer. Structures modelling specialised data structures.

The data structures enumerated above had the following, common components: ● ● ● ●

System of data structure interconnections. Indexing system. Graphical interface. World-wide web interface.

For the class of modelled design processes considered, a relational database was deﬁned. The logical structure of the deﬁned database is presented in Figure 10.3. Additionally a group of tables with particular data structures of a certain node was implemented: ● ● ● ●

Table with links to ﬁles. Table with links to applications. Table with links to internet addresses. Tables with data about stored associations.

10 25/7/03 09:54 Page 147

10 Intelligent Personal Assistant – Implementation ● ● ● ● ●

147

Table with associated rules. Table with associated descriptive information. Tables for storing information about user/designer sessions. Table with data about document placing. Tables with design variables.

Most of the above tables were connected to the basic node data table via a oneto-one relationship. An additional table of maze model internode and intranode connections was deﬁned. In Figure 10.3 a form with modelled data structures is shown.

Logical database structure

New modules definition

New links definition

External application connection

New notes definition

Figure 10.3 Example of system structure deﬁnition.

10 25/7/03 09:54 Page 148

148

IPA – Concepts and Applications in Engineering

Index structure Presentation of selected information

Editing of associations Form for data searching Figure 10.4 Example of searching for information.

A special module for data searching according to the predeﬁned concepts was developed (Figure 10.4). The structure of index data is shown in Figure 10.4. Figure 10.5 shows forms of an example node (sub-task). A navigation system was important for the functioning of the system. In Figure 10.6 we see two example solutions. An implemented personal assistant integrates: ● ● ● ●

Management of all kinds of data arising during the design analysis, including index and search systems. Extended connections between data. Project plan editor supporting the maze model of the design process. Artiﬁcial intelligence methods: – expert system used for supporting decisions, for managing tasks in the project node; – case-based reasoning used for comparing and re-using paths in the maze model.

One of the issues concerning a personal assistant was to integrate all kinds of data arising during the design process. As possible data formats we have considered: ● ● ● ●

Data stored in ﬁles saved on computer disks, which could be linked to a personal assistant or stored in it. Descriptions and placing of paper documents (books, articles, project-speciﬁc documents), or links to web documents. Speciﬁcations of project nodes including analyses based on expert systems. Various data types predeﬁned in a system or deﬁned by a user.

When the user focuses on a particular node, then a set of related data is presented to him and a small set of related expert system rules is loaded. Then he can use the data

10 25/7/03 09:54 Page 149

10 Intelligent Personal Assistant – Implementation

149

Design sub-task and its components

Design variables Figure 10.5 Sub-task and its components.

or perform tasks from a list.As a result he produces a new description of the problem in the form object–attribute–value. This is the basis on which rules can operate. In this way an expert system can suggest which tasks should be performed earlier, can show alternative paths in the maze model, or can suggest other possible solutions. New data arising during the interaction with the system can be stored in a personal assistant and can be linked with a speciﬁc node. The possible data types are expert system rules. The user can add new remarks in this form and run them later – all of them or only some sets from speciﬁc sessions. In this way he can reconstruct his own suggestions from the past. Nodes, and links between the nodes, are presented to the user in a maze editor: a sequence of completed nodes, the current node, and the next possible steps. The completed nodes are analysed to ﬁnd circular paths. The editor always focuses on the current node and presents the next possible nodes in the form of a tree. The nodes have a hierarchical order, so the problem can be considered on different levels – from the most general to the most detailed. Whenever we have a large number of data, a speciﬁc index system is necessary. It has to generalise and order information. Generalising helps to ﬁnd related data when we do not know exactly what we are looking for. In our program the index system consists of two sub-indexes. The ﬁrst one (base) includes a general dictionary with commonly used terms placed in a multilevel hierarchy. The second one, an additional index, includes different descriptions of terms from the base index. As an addition to browsing information related to nodes, we developed a search tool which is able to help the user to ﬁnd information on the basis of a full text

10 25/7/03 09:54 Page 150

150

IPA – Concepts and Applications in Engineering

Navigation – made in database

Navigation – made in VRML Figure 10.6 Navigation tools.

search. This tool allows the user to set a base (collection of data) and search it for all or some of the entered words. During the interaction with a system a sequence of nodes completed or visited by the user is recorded. These sequences and sets of design variables from different sessions can be compared.We can present a comparison of different coefﬁcients of similarity. The highest coefﬁcient of similarity means that the user visited the same nodes a second time. When we want to compare sequences less accurately we eliminate some nodes from the path or pass over circuit sequences, and compare them again. In this way we can ﬁnd out the best and most frequently used paths from the maze and suggest them in future sessions. We can also identify which sets of information are frequently used in a given task and the next time present them in advance. The developed implementation was used for building a few example environments. They were built for the following domain problems: ● ● ●

Examination of the stabilising moment of a car steering mechanism [12]. Estimation of car braking distance [46]. Supporting the design process of car braking systems [102].

10 25/7/03 09:54 Page 151

10 Intelligent Personal Assistant – Implementation ● ● ●

151

Supporting data analysis in experimental aircraft chassis testing [12, 46]. Supporting the process of aircraft tyre selection [66]. Supporting heating system design for small houses [12, 87–89].

The complete developed software was not implemented in each case. In these few examples, only limited versions of the proposed approach were used. Now we brieﬂy present some of these problems.

Example 10.1. Examination of the Stabilising Moment of a Car Steering Mechanism Examples 10.1. and 10.2 were based on the knowledge acquired from an academic expert with an industrial practice. An expert presented his concepts and plans to solve the problems during authorised interview sessions. The resulting maze model structure is presented in Chapter 2 (Figure 2.1). A Virtual Reality Modelling Language (VRML) visualisation of the process is presented in Figure 10.7.

Figure 10.7 Examination of the stabilising moment of car steering mechanism – VRML model.

Example 10.2.

Estimation of Car Braking Distance

The plan of the acquired process is presented in Figure 10.8 (VRML visualisation).

10 25/7/03 09:54 Page 152

152

IPA – Concepts and Applications in Engineering

Figure 10.8 Estimation of car braking distance – VRML model.

Example 10.3. Supporting the Design Process of Car Braking Systems In this domain two implementations were performed. The first was the support of a braking system design for mobile cranes. The developed application was built in cooperation with the Construction Equipment Research Institute, Kobylka, Poland. The design process plan is presented in Chapter 1 (Figure 1.2). VRML visualisation is shown in Figure 10.9.

Figure 10.9 Supporting design process of braking system of mobile crane – VRML model.

10 25/7/03 09:54 Page 153

10 Intelligent Personal Assistant – Implementation

Figure 10.10 Supporting design process of car braking system design.

The second deals with a personal assistant for the general case of car braking system design. In Figures 1.20 and 1.21, and Figure 10.10, the plan of the design process together with its computer implementation is shown.

Figure 10.11 System supporting data analysis in experimental aircraft chassis testing.

153

10 25/7/03 09:54 Page 154

154

IPA – Concepts and Applications in Engineering

Figure 10.12 System supporting data analysis in experimental aircraft chassis testing – VRML model.

Knowledge-based modules supporting process of simulation data selection

Sequence of simulation scenarios 2.5D editor • Geometrical 2.5D model of installation • Geometrical 2.5D simplified model of house

Generator of 3D geometrical model of house heating system

Knowledge-based generator of fluid flow dynamics model

Simulator

Graphic postprocessor Figure 10.13 Global scheme of application supporting heating system design for small houses.

10 25/7/03 09:54 Page 155

10 Intelligent Personal Assistant – Implementation

Example 10.4. Supporting Data Analysis in Experimental Aircraft Chassis Testing This example was performed in cooperation with the Institute of Aviation in Warsaw, Poland. The cooperation with one of its nodes is visible in Figure 10.11.VRML visualisation is presented in Figure 10.12.

Example 10.5. Supporting Heating System Design for Small Houses Figure 10.13 shows the global structure of the whole implementation.

155

10 25/7/03 09:54 Page 156

This page intentionally left blank

11 25/7/03 09:54 Page 157

11

Intelligent Personal Assistant – Unified Framework

In the overall intelligent personal assistant methodology, four groups of components should be considered: 1. The design process: the designer’s thinking, ideas, concepts, mental and nonmental modelling and problem solving, way of using supporting tools, and of integrating different sub-problems. 2. Computer tools which are available nowadays for supporting and solving different types of problems. 3. Available hardware, networks, world-wide web. 4. The economic background of the development of the intelligent personal assistant approach. Group (1) implies that the design process is realised by an individual designer in a speciﬁc way. We acquired a rough idea of a designer at work. We also have a certain idea of what the software supporting the design process should look like. This idea we share with the designers. If we ignore economic circumstances it would be possible to develop an intelligent personal assistant based on the concepts described in the previous chapters using computer technologies which are of high standards. Although theoretically it is possible, putting the plan into practice would confront us with difﬁculties. The biggest problem we are faced with is the multidiscipline of the project. To implement multidiscipline software we would have to consult people specialising in different domains,people with considerable knowledge. From the experience gained through our projects we can determine the following specialisations: programming languages, expert systems, knowledge management systems,ofﬁce software,databases,a multitude of integration technologies and tools, optimisation methods and tools, CAD and CAE systems with their customisation and integration tools,PDM software,and internet tools;often many elements were just discovered for our personal assistant projects.Moreover,such a project should be ﬁnished in a reasonable period of time. To develop our projects we had to organise the participating teams. In most cases one or two system developers were involved who cooperated with the designers and created the software. Their work was accompanied by intensive consultation. The consultation was not only restricted to software issues. Often it included good advice, either taken from theoretical literature or from practice engineering design, engineering software building or development. Only in one particular method of software selection did the knowledge of the economic circumstances play a key role. 157

11 25/7/03 09:54 Page 158

158

IPA – Concepts and Applications in Engineering

Looking back at the experiences with the development of a personal assistant in certain concepts, we notice that after the initial cooperation stage, the work was mostly carried out through the designers’ and developers’ imagination. Designers store their experiences, hypotheses and visions mentally. They maintain their original concepts, try to develop them and on this basis, evolve new ideas. To sum up, one can say that in many cases the model of a personal assistant is always present in the designers’ minds. The only problem is that the software which is available on the market does not meet at once the requirements of that model. We can make it ﬁt if we endeavour to follow the development of computer technologies and are creative enough to convert them into the software. Finally, we come to the conclusion that there is a demand for a tool which allows the designer to build a realistic model of his speciﬁc design process. The UML language may serve our needs. We have to consider how to model the issues of different intelligent personal assistants. Obviously we can think of building a modelling language approach. However, with this proposal we run the risk that the designers will not accept it. It is more advisable to exploit that which the users already know from existing software and what they are able to model with it. We may apply such prerequisites as tools for the identiﬁcation of a formal model. MS Ofﬁce applications are a good source of information about the way design processes are carried out.

12 25/7/03 11:57 Page 159

References

1. Aamodt A, Plaza E (1994) Case Based Reasoning, Foundational Issues, Methodological Variations, and System Approaches. AICom – Artiﬁcial Intelligence Communications (http://www.iiia.csic.es/People/enric/AICom.html), IOS Press, pp 39–59 2. Aleksandrowicz J, Siemiatkowski L (2000) Processor for decision support in machine design. Diploma, Institute of Machine Design Fundamentals, Warsaw University of Technology (in Polish) 3. Amelja n´ czyk A (1979) Multicriteria optimization. Lecture materials, PTC, Warsaw (in Polish) 4. Babala D (1989) A Brief Description of the Computer Program INES. AB ASEA-ATOM, Masteras, Sweden 5. Badke-Schaub P, Frankeberger E (1999) Analysis of design projects. Design Studies 20: 465–480 6. Ben-Tal A (1980) Characterization of Pareto and lexicographic optimal solutions. In: Multiple Criteria Decision Making, Theory and Application, Springer-Verlag, Berlin Heidelberg New York 7. Beyer N, Weber F (1999) Concepts and prototype for a practical communication environment for supporting and managing concurrent product development. In: Proceedings of International Conference on Engineering Design ICED99, Munich, Germany, pp 1431–1436 8. Blackboard Technology Group Inc. (1998) GBB manuals 9. Boulanger S, Gelle E, Smith I (1995) Taking advantage of design process models. In: IABSE Colloquium, Bergamo, pp 87–96 10. Boulanger S, Smith I (1994) Models of design process. In: Applications of Artiﬁcial Intelligence in Structural Engineering, Lausanne, pp 30–46 11. Carver N, Lesser V ( 1994) Evolution of blackboard control architectures. Expert Systems with Applications 7: 1–30 12. Cichocki P, Pokojski J (2001) Methodology of Design Knowledge Storage In Machine Design. Institute of Machine Design Fundamentals, Warsaw University of Technology, Warsaw (in Polish) 13. Clarkson PJ, Hamilton JR (1999) Signposting the design process. In: Proceedings of International Conference on Engineering Design ICED99, Munich, Germany, pp 107–112 14. Clarkson PJ, Hamilton JR (2000) “Signposting”, a parameter-driven taskbased model of the design process. Research in Engineering Design 12: 18–38 15. CLIPS (1995) Manual, version 6.0, Athens 16. Corkill D, Lander S (1998) Diversity in agent organizations. In: Blackboard Technology, http://www. bbtech.com, pp 1–23 159

12 25/7/03 11:57 Page 160

160

References

17. Court AW (1997) The relationship between information and personal knowledge in new product development. International Journal of Information Management 17(2): 123–138 18. Court AW (1998) Issues for integrating knowledge in new product development: reﬂections from an empirical study. Knowledge-Based Systems 11: 391–398 19. Court AW, Ullman DG, Culley SJ (1998) A comparison between the provision of information to engineering designers in the UK and the USA. International Journal of Information Management 18(6): 409–425 20. Craig J (1995) Blackboard Systems. Ablex Publishing Corporation, Norwood, NJ 21. Debreu G (1959) Theory of Value. Wiley, New York 22. Dorner D (1999) Approaching design thinking research. Design Studies 20: 407–415 23. Dyer J (1972) Interactive goal programming. Management Science 19(1): 62–70 24. Dreisbach RL (2001) Product simulation integration. Integrated Enterprise 2(1): 7–10 25. Dybala T, Tecuci G (1995) Shared expertise space – a learning-oriented model for computer aided engineering design. In: Proceedings of the IJCAI-95 Workshop on Machine Learning in Engineering, Montreal, pp 49–65 26. Ehrgott M, Gandibleux X (2002) Multiple Criteria Optimization, State of the Art Annotated Bibligraphic Surveys. Kluwer Academic Publishers, Boston Dodrecht London 27. Engelmore R, Morgan A (Eds) (1998) Blackboard Systems. Addison-Wesley 28. Fenves S (1998) Towards personalized structural engineering tools. In: Lecture Notes in Artiﬁcial Intelligence, V Workshop Application of Artiﬁcal Intelligence in Structural Engineering (I Smith, Ed), Ascona, Switzerland, Springer-Verlag, pp 86–91 29. Fenves SJ, Rivard H, Gomez N (2000) SEED-Conﬁg: a tool for conceptual structural design in a collaborative building design environment. Artiﬁcial Intelligence in Engineering 14: 233–247 30. Findeisen W (1974) Multi-level Control Systems. PWN, Warsaw (in Polish) 31. Geoffrion AM, Hogan W (1972) Coordination of two-level organizations with multiple objectives. In: Techniques of Optimization (A Balakrishnan, Ed), Academic Press, pp 455–466 32. Gero J (1992) Creativity, emergence and evolution in design. In: Second International Conference – Computational Models of Creative Design, 6–10 Dec, Heron Island, Queensland; University of Sydney, Heron Island, Queensland, pp 1–29 33. Gil M (2001) Computer Integration of Design Process Components in Machine Design. PhD Thesis, Warsaw University of Technology (in Polish) 34. Girratano J, Riley G (1994) Expert Systems Principles and Programming. PWS, Boston 35. Gunther J, Ehrenspiel K (1999) Comparing designers from practice and designers with systematic design education. Design Studies 20: 439–451 36. Hicks BJ, Culley SJ, Allen RD, Mullineux G (2002) A framework for the requirements of capturing, storing and reusing information and knowledge in engineering design. International Journal of Information Management 22: 263–280

12 25/7/03 11:57 Page 161

References

161

37. Hildre HP (1999) CAE from ﬁrst day designing complex machines. In: Proceedings of International Conference on Engineering Design ICED99, Munich, Germany, pp 715–720 38. Hong J, Toye G, Leifer LJ (1994) Personal Electronic Notebook with Sharing. Center for Design Research, Stanford University, http://wwwcdr.stanford.edu/people/ hong/papers/wetice/ 39. Hong J, Toye G, Leifer LJ (1996) Engineering design notebook for sharing and reuse. Computers in Industry 29: 27–35 40. Hwang Ch, Masud A (1979) Multiple Objectives Decision Making – Methods and Applications. Springer-Verlag 41. Hwang Ch, Yoon K (1981) Multiattribute Decision Making. Springer-Verlag 42. Jackson P (1998) Expert Systems. Addison-Wesley, New York 43. Ja´s kiewicz Z, Wasiewski A (1995) Tooth Gears. Design. Wydawnictwa Komunikacji i´ Laczno´s ci, Warsaw (in Polish) L, Warsaw (in 44. Ja´s kiewicz Z (1972) Calculations of Transmission Systems. WKi´ Polish) 45. Keeney R, Raiffa H (1976) Decision with Multiple Objectives, Preference and Trade-offs. Wiley . 46. Kowalski D, Zadrozny M (2000) Expert systems development for support of plane chassis testing and computer car simulation. Diploma, Institute of Machine Design Fundamentals, Warsaw University of Technology (in Polish) 47. Lander SE (1997) Issues in Multiagent Design Systems. IEEE Experts March–April: 18–26 48. Lander S, Corkill D, Staley S (1996) Designing integrated engineering environments: blackboard-based integration of design and analysis tools. Concurrent Engineering: Research and Applications 4(1): 59–70 49. Lin JG (1977) Proper inequality constraints and maximization of index vectors. Journal of Optimization Theory and Applications 21(4): 505–521 50. Ludcke R, Birkhofer H (2001) Leadership in the design process: First ﬁndings of an investigation in two industrial companies. In: Proceedings of International Conference on Engineering Design ICED 01, Glasgow 21–23 August (CD) 51. Ludcke R, Birkhofer H (2002) The inﬂuences of organization on leadership in the design process: results of an investigation in ﬁve industrial companies. In: Proceedings of International Design Conference – Design 2002, Dubrovnik 14–17 May (CD) 52. Macias M, de Souza M (2001) Integrated analysis architecture. Integrated Enterprise 2(1): 11–18 53. Maetz J (1990) Programm ISOM. Ein Programm zur Erstellung von Isometrien und Stucklisten. Manual Kerntechnik-Entwicklung-Dynamik, Rodenbach, Germany 54. Maher ML, Gomez A. (1996) Developing case-based reasoning for structural design. IEEE Experts June: 42–52 55. Mesarovic MD, Macko D, Takahara Y (1970) Theory of Hierarchical, Multilevel Systems. Academic Press, New York London 56. Miles JC (1995) Integrated innovative computer systems for conceptual bridge design. In: IABSE Colloquium, Bergamo, pp 97–106 57. Managing Engineering Knowledge, MOKA – project (2001). Professional Engineering Publishing Limited, London 58. Moran TP, Carroll JM (1996) Design rationale: concepts, techniques, and use. Lawrence Erlbaum Associates, Mahwah, NJ

12 25/7/03 11:57 Page 162

162

References

59. Nii HP (1994) Blackboard systems at the architecture level. Expert Systems with Applications 7: 43–54 60. Oculus Technologies Corp. (2002) www.oculustech.com 61. O’Leary D (1998) Using AI in knowledge management: knowledge bases and ontologies. IEEE Intelligent Systems May/June: 34–39 62. Osi´nski Z, Wróbel J (1995) Design Theory. PWN, Warsaw (in Polish) 63. Osi´nski Z, Pokojski J, Wróbel J (1983) Optimization of multi-level multi-criteria machine design problems. Foundations of Control Engineering 8(3–4): 175–182 64. Osi´nski Z, Pokojski J, Wróbel J (1984) Multi-criteria optimization of some decomposed problems in machine dynamics. In: Proceedings of Conference on Modeling in Dynamics, Szczyrk, pp 573–582 (in Polish) 65. Osi´nski Z, Wróbel J (1982) Design Theory in Machinery. PWN, Warsaw (in Polish) 66. Owczarczyk T, Rukszan W (2000) Development of personal assistant environment on the basis of: 1) process of plane tyres selection, 2) conﬁguration of stands. Diploma, Institute of Machine Design Fundamentals, Warsaw University of Technology (in Polish) 67. Pahl G, Badke-Schaub P, Frankeberger E (1999) Resume of 12 years interdisciplinary empirical studies of engineering design in Germany. Design Studies 20: 481–494 68. Pahl G, Beitz W (1984) Design Theory. WNT, Warsaw (in Polish) 69. Penoyer JA, Burnett G, Fawcett DJ, Liou S-Y (2000) Knowledge based product life cycle systems: principles of integration of KBE and C3P. Computer-Aided Design 32: 311–320 70. Pokojski J (1982) Multicriteria Optimization of Large Design Problems in Machine Design on the Basis of Car Gear-Box. PhD Thesis, Warsaw University of Technology (in Polish) 71. Pokojski J (1988) Computer aided decision making in vehicle dynamics. Modelling, Simulation and Control B 17: 1–11 72. Pokojski J (1990) Computer aided multi-criteria decision making in machine dynamics. In: Prace Naukowe Politechniki Warszawskiej, Seria Mechanika 134: 1–105 (in Polish) 73. Pokojski J (1990) System Rohrnetz. Raport, Kerntechnik-EntwicklungDynamik, Rodenbach, Germany 74. Pokojski J (1995) An integrated intelligent design environment on the basis of system for ﬂow dynamics analysis. In: Proceedings of International Conference on Engineering Design, Praga, pp 1333–1338 75. Pokojski J (1996) The integrated product and process model for the design of gear box. In: Proceedings of International Conference on CIM, Zakopane, pp 367–372 76. Pokojski J (1997) Expert system technology in machine design. In: Advances in Engineering, Proceedings of the IX German-Polish Seminar, Koln, pp 118–125 77. Pokojski J (1999) Product model transformations in maze model of design. In: Computer Integrated Manufacturing. Proceedings of International Conference CIM 99, Zakopane 9–12 March, WNT, Warsaw, pp 121–128 78. Pokojski J (1999) Knowledge based support of machine dynamic analysis. In: Advances in Concurrent Engineering CE99, Sixth ISPE International Conference on Concurrent Engineering, Bath, UK; Edited by: Dr Pravir K.

12 25/7/03 11:57 Page 163

References

79. 80. 81.

82.

83. 84. 85. 86.

87. 88.

89. 90.

91.

163

Chawdry, Department of Mechanical Engineering, University of Bath, Bath, United Kingdom; Professor Parisa Ghodous and Professor Denis Vandorpe, LIGIM, University of Lyon I, France. Series Editor: Biren Prasad, Ph.D., KBE Director, Unigraphics Solutions, KBE Business Unit, Electronic Data Systems (EDS), Troy, MI., http://www.ceteam.com/, pp 336–344 Pokojski J (1999) Blackboard integration of design tools. In: Computer Integrated Manufacturing. Proceedings of International Conference CIM 99, Zakopane 9–12 March, WNT, Warsaw, pp 112–120 Pokojski J (Ed) (2000) Intelligent Support of Design Environment Integration in Machine Design. WNT, Warsaw (in Polish) Pokojski J (2000) Processor for maze model of design process. In: Ghodous P., Vandorpe D. (Eds), and B. Prasad, Series Editor: Advances in Concurrent Engineering CE2000, Seventh ISPE International Conference on Concurrent Engineering: Research and Applications, Lyon, France 2000. Technomic Publishing Co. Inc., Lancaster, USA, pp 489–494 Pokojski J (2001) Towards personalised software in machine design – multicriteria optimisation aspect. In: Advances in Concurrent Engineering CE2001, Eighth ISPE International Conference on Concurrent Engineering: Research and Applications, Anaheim, USA, pp 261–271 Pokojski J (2002) Towards personalised software in machine design. Computer Assisted Mechanics and Engineering Science 9(1): 105–122 Pokojski J (2002) Computer aided design environment with case based reasoning module. In: Advances in Concurrent Engineering CE2002, AA Balkema, Rotterdam Brookﬁeld, pp 555–560 Pokojski J (2002) The history of one industrial application. In: Engineering Design in Integrated Product Development EDIPROD’ Proceedings,´ Lagów, pp 145–152 Pokojski J, Cichocki P (2001) Towards personalised software in machine design – comparative study. In: Advances in Concurrent Engineering CE2001, Eighth ISPE International Conference on Concurrent Engineering: Research and Applications, Anaheim, USA, pp 255–261 Pokojski J, Cichocki P, Gil M (1997) Integrated system for heating system design. In: IV Workshop Application of Artiﬁcal Intelligence in Structural Engineering, Lahti, pp 27–32 Pokojski J, Cichocki P, Gil M (1998) Heating system design support. In: Lecture Notes in Artiﬁcial Intelligence, V Workshop Application of Artiﬁcal Intelligence in Structural Engineering (I Smith, Ed), Ascona, Switzerland, Springer-Verlag, pp 60–68 Pokojski J, Cichocki P, Gil M (1999) Knowledge based heating system design support. In: Proceedings of International Conference on Engineering Design ICED99, Vol 3, Munich, Germany, pp 1901–1904 Pokojski J, Cichocki P, Gil M (1999) Intelligent personal assistant for machine dynamics problems. In: Artiﬁcial Intelligence in Structural Engineering, Proceedings of the 6th EG-SEA-AI Workshop, WNT, Wierzba, pp 159–164 Pokojski J, Cichocki P, Gil M (2000) Intelligent Personal/Team Assistant. In: Ghodous P., Vandorpe D. (Ed); and B. Prasad, Series Editor: Advances in Concurrent Engineering CE2000, Seventh ISPE International Conference on Concurrent Engineering: Research and Applications, Lyon, France 2000. Technomic Publishing Co. Inc., Lancaster, USA, pp 644–649

12 25/7/03 11:57 Page 164

164

References

92. Pokojski J, Okapiec M, Witkowski G (2002) Knowledge based engineering, design history storage, and case based reasoning on the basis of car gear box design. In: AI-Meth 2002, Gliwice, pp 337–340 93. Pokojski J, Ostapski W (1996) Concept of design plan editor for harmonic drive design. In: Applications of Artiﬁcial Intelligence in Structural Engineering, Proceedings of the 3rd Workshop of the EG-SEA-AI, Glasgow, UK, August 12–13, pp 33–38 94. Pokojski J, Ostapski W (1997) Plan editor for supporting dynamic analysis. In: Applications of Artiﬁcial Intelligence in Structural Engineering. Proceedings of the 4th Workshop of the EG-SEA-AI, Lahti, Finland, September 1–2, pp 159–164 95. Pokojski J, Ostapski W (1998) Intelligent environment for supporting analysis in machine dynamics on the basis of harmonic drives design. Machine Dynamics Problems 22: 105–113 96. Pokojski J, Strzelecki P, S´ ledziona´ L (2002) Modelling with features, design history storage, case based reasoning on the basis of machine shaft design. In: AI-Meth 2002, Gliwice, pp 341–344 97. Pokojski J, Wróbel J (1998) Optimization of damping in machine dynamics. In: Damping of Vibrations (Z Osi´nski, Ed), AA Balkema, Rotterdam Brookﬁeld, pp 477–487 98. Ramesh B, Tiwana A (1999) Supporting collaborative process knowledge management in new product development teams. Decision Support Systems 27: 213–235 99. Regli WC, Hu X, Atwood M, Sun W (2000) A survey of design rationale systems: approaches, representation, capture and retrieval. Engineering with Computers 16: 209–235 100. Romer A, Weisshahn G, Hacker W, Pache M, Lindemann U (2001) Effortsaving product representations in design – results of a questionnaire survey. Design Studies 22: 473–491 101. Roy R (Ed) (2001) Industrial Knowledge Management: A Micro-level Approach. Springer-Verlag, London Berlin Heidelberg 102. Róz. ycki A (2002) Conceptual design of car braking system. Diploma, Institute of Machine Design Fundamentals, Warsaw University of Technology (in Polish) 103. Shimizu K, Aiyoshi E (1981) Hierarchical multi-objective decision systems for general resource allocation problems. Journal of Optimization Theory and Applications 35(4): 517–533 104. Sriram R (1997) Intelligent Systems for Engineering. A Knowledge Based Approach. Springer-Verlag 105. Sriram R (2001) Standards for collaborative product development. In: Advances in Concurrent Engineering CE2001, Eighth ISPE International Conference on Concurrent Engineering: Research and Applications, Anaheim, USA, pp xxxvii–xlv 106. Stempﬂe J, Badke-Schaub P (2002) Thinking in design teams – an analysis of team communication. Design Studies 23: 473–496 107. Tiwana A (2002) The Knowledge Management Toolkit, 2nd Edn. Prentice Hall PTR, Upper Saddle River, NJ 108. Tiwana A, Ramesh B (2001) A design knowledge management system to support collaborative information product evolution. Decision Support Systems 31: 241–262

12 25/7/03 11:57 Page 165

References

165

109. Tong Ch, Sriram D (Eds) (1992) Artiﬁcial Intelligence in Engineering Design, Vols 1–3, Academic Press 110. Tong SS (2001) Driving optimized products through automated software collaboration. In: Advances in Concurrent Engineering CE2001, Eighth ISPE International Conference on Concurrent Engineering: Research and Applications, Anaheim, USA, pp xix–xxvi 111. Turkiyyah GM, Fenves SJ (1996) Knowledge-based assistance for ﬁnite-element modeling. IEEE Experts June: 23–48 112. Ullman DG (2001) Toward the ideal mechanical engineering design support system. Research in Engineering Design 13: 55–64 113. Ullman DG (2002) The Mechanical Design Process, 3rd Edn. McGraw-Hill 114. Werner H, Ahmed C (1999) Design with a model system using event triggered procedures. In: Proceedings of International Conference on Engineering Design ICED99, Munich, Germany, pp 1011–1014 115. Werner H, Weber C (1998) Ligo – an object-oriented modeling for integrated product development. In: Integrated Product Development Workshop, Magdeburg 116. Yang MC, Cutkosky MR (1999) Machine generation of thesauri: adapting to evolving vocabularies in design documentation. In: International Conference on Engineering Design ICED99, Munich, Germany, pp 143–148 117. Pokojski J, Ostapski W. Gawart E (1996) Model of harmonic drive design process. In: Proceedings of the International Conference on Computer Integrated Manufacturing, Zakopane 1996, pp 361–366 118. Pokojski J, Cichocki P (2001) Intelligent personal assistant for design. In: Proceedings of the International Conference on Computer Integrated Manufacturing, Zakopane 2001, pp 96–105 119. Pokojski J (2000) Intelligent personal/team assistant in machine design. In: Proceedings of the second International Seminar and Workshop held in Technical University of Zielona Góra, Vol. II, pp 55–62 120. Pokojski J (2001) Application of Case Based Reasoning in Machine Design. In Methods of artiﬁcial intelligence in mechanics and mechanical engineering AI-MECH 2001; Gliwice; pp 209–216 121. Pokojski J (2001) Intelligent Personal Assistant – Knowledge Repositories in Design. In Proceedings of X Sino-Polish Conference CAD in Machinery, Institute of Machine Design Fundamentals,Warsaw University of Technology, pp 83–89 122. Pokojski J, Studzi´nnski M (2000) Application of Case Based Reasoning Technology in Machine Design. Proceedings of 5th Polish–Slovak Scientiﬁc Conference on “Computer Simulation in Machine Design”, Institute of Machine Design Fundamentals, Warsaw University of Technology pp 131–136

12 25/7/03 11:57 Page 166

This page intentionally left blank

13 25/7/03 11:58 Page 167

Further Reading

Abecker A, Bernardi A, Hinkelmann K, Kuhn O, Sintek M (1998) Toward a technology for organizational memories. IEEE Intelligent Systems May/June: 40–48 Abramovici M, Gerhard D (1999) Flexible management of distributed engineering information resources with PDM. In: Proceedings of International Conference on Engineering Design ICED99, Munich, Germany, pp 1425–1430 Abramovici M, Langenberg L (1999) Enterprise-wide information repositories for product development support. In: Proceedings of International Conference on Engineering Design ICED99, Munich, Germany, pp 1437–1440 Brown DR, Leifer LJ (1991) The role of meta-level inference in problem-solving strategy for a knowledge-based dynamic analysis aid. Journal of Mechanical Design, Transactions of the ASME 113: 438–445 Chongsu K, O’Grady PJ (1996) A representation formalism for feature-based design. Computer-Aided Design 28(6/7): 451–460 Fruchter R (1998) Internet-based web-mediated collaborative design and learning environment. In: Lecture Notes in Artiﬁcial Intelligence, V Workshop Application of Artiﬁcial Intelligence in Structural Engineering (I Smith, Ed), Ascona, Switzerland, Springer-Verlag, pp 133–145 Fruchter R, Yen J, Leifer J (1999) Capture and analysis of concept generation and development in informal media. In: Proceedings of International Conference on Engineering Design ICED99, Munich, Germany, pp 769–774 Gao Y, Zeid I, Bardasz T (1998) Characteristics of an effective design plan system to support reuse in case-based mechanical design. Knowledge-Based Systems 10: 337–350 Liang T, Cannon DM, Leifer LJ (1998) Augmenting a design capture and reuse system based on direct observations of usage. In: Proceedings of DETC ’98, ASME Design Engineering Technical Conferences (CD) Liang T, Leifer LJ (2000) Learning from experience of peers: an empirical study of knowledge sharing in a product design community. In: Proceedings of DETC ’00, ASME 2000 Design Engineering Technical Conferences (CD) Liang T, Bell DG, Leifer LJ (2001) Mapping experience: learning from experience of peers through socio-technical interactions. In: Proceedings of International Conference on Engineering Design ICED 01, Glasgow 21–23 August (CD) Lloyd T, Leifer L (2001) Incorporating incentives into design documentation tools. In: Proceedings of International Conference on Engineering Design ICED 01, Glasgow 21–23 August (CD) Lowe A, McMahon C, Shah T, Culley S (2000) A method for the study of information use proﬁles for design engineers. In: Proceedings of the 2000 ASME Design Engineering Technical Conferences (CD) 167

13 25/7/03 11:58 Page 168

168

Further Reading

Lowe A, McMahon C, Shah T, Culley S (1999) An analysis of the content of technical information used by engineering designers. In: Proceedings of the 1999 ASME Design Engineering Technical Conferences (CD) Park H, Cutkosky MR (1999) Framework for modeling dependencies in collaborative engineering processes. Research in Engineering Design 11: 84–102 Pavkovic N, Marjanovic D, Dekovic D (2001) Object-oriented modelling of the design process. In: Proceedings of International Conference on Engineering design ICED 01, Glasgow 21–23 August (CD) Pinfold M, Chapman C (2001) The application of KBE techniques to the FE model creation of an automotive body structure. Computers in Industry 44: 1–10 Yen SJ, Fruchter R, Leifer LJ (1999) Facilitating tacit knowledge capture and reuse in conceptual design activities. Proceedings of the 1999 ASME Design Engineering Technical Conferences (CD)

14 25/7/03 10:02 Page 169

Index

A

Hogan 135 local decision variables 123, 139 local value functions 135, 138 method of leading and related subproblems 124, 137 Shimizu 139 structure of optimisation problem 119 descriptive 46, 147 descriptive knowledge 16, 44, 84, 93 design activities 6, 43, 57, 85, 146 design history 28, 104, 109 design of speed reducers 86 design ofﬁce 13 design process 1, 27, 40, 57, 73, 81, 99, 120, 145 design process modelling 81 design process of car braking systems 21, 150 design process of piping system 24, 61 design process of test stands 82 design process can be classiﬁed as routine innovative or creative, 2 design rationale 10, 40, 82, 88, 89, 97, 101, 106 design rationale information generation 89 design teams 7, 43 designer’s auto-censorship 7 designers’ knowledge 13 Dybala 51

activities 2, 38, 60, 76, 85 97, 117 activity knowledge 88

B blackboard architecture 13, 61, 74 control mechanism 74 knowledge sources 73 braking system design for a mobile crane 1

C CAD 7, 10, 27, 43, 45, 50, 79, 100, 145, 157 CAE 7, 10, 43, 53, 79, 100, 145, 157 case-based knowledge 16 case-based reasoning 15, 57, 72, 101, 105, 148 Clarkson 52 collaboration 93 communication 38, 42, 74, 91 computer tools 7, 10, 28, 44, 78, 87, 95, 99, 109 conﬂict resolution 134 control mechanism 74 cooperation 38, 98, 116 coordination 37, 91, 124, 134, 140 coordination decision variables 123, 136, 139 criteria space ordering 126, 128 Cutkosky 53

E

D

estimation of car braking distance 150 evaluations and associations 6 experimental aircraft chassis testing 151

data 6, 41 data structure 12, 53, 65, 74, 86, 107, 145 database 11, 13, 40, 62, 74, 86, 100, 143, 145 declarative 55 declarative knowledge 44, 84, 110, decomposition and coordination 136 coordination 124, 134, 140 coordination decision variables 123, 136, 139 Geoffrion 135 global value function 134, 137

F Fenves 54 formal knowledge model 42

G gear box 19, 46, 87, 96, 101, 118, 142 Geoffrion 135 169

14 25/7/03 10:02 Page 170

170

geometrical modelling 23, 43, 62, 73 global value function 134, 137

H Hamilton 52 heating system design 64, 151 Hildre 53 Hogan 135 Hong 53 HTML 43

I implementation 51, 91, 145 braking system design for a mobile crane 1 design of speed reducers 86 design process of car braking systems 21, 150 design process of piping system 24, 61 design process of test stands 82 estimating of car braking distance 150 experimental aircraft chassis testing 151 heating system design 64, 151 machine dynamics 13, 29 machine shaft design 76, 105 piping system 24, 47, 61 stabilising moment of a car steering mechanism 150 toothed wheels 19, 45, 86, 94, 104, 119 informal knowledge model 42 information and knowledge 41, 78, 84, 90 integration of different design aspects 116 interactive goal programming 130 IPA – survey of concepts Clarkson 52 Cutkosky 53 Dybala 51 Fenves 54 Hamilton 52 Hildre 53 Hong 53 Tecuci 51 Turkiyyah 54 Weber 54 Werner 54

K KBE 87 Keeney 135 knowledge acquisition 11, 51, 99 knowledge-based 1, 43, 50, 65, 73, 87, 101, 154 knowledge-based engineering 1, 43, 87, 97 knowledge management 42, 86, 90, 100, 157

Index

knowledge modelling 99 knowledge repositories 10 knowledge representations 39, 85 data 41 formal knowledge model 42 informal knowledge model 42 information and knowledge 41 long-term memory 43 object-oriented approach 49 rules 45 short-term memory 44 knowledge sources 14, 28, 39, 56, 63, 73, 85, 145 knowledge storage 12, 41, 84, 95

L lexicographic approach 132 local decision variables 123, 135 local value functions 135, 138 long-term memory 43, 98

M machine dynamics 13, 29 machine shaft design 76, 105 maze model 16, 30, 52, 57, 97, 113, 117, 122, 142, 146 method of constraints 131 method of leading and related subproblems 124, 137 methods with preferences articulated a posteriori 133 methods with preferences articulated a priori 133 methods with preferences articulated progressively 133 modelling of shaft 107 modelling with features 106 multiattribute methods 113 multicriteria optimisation 113 multicriteria optimisation layer 71 multiobjective optimisation 113, 122, 129 criteria space ordering 126, 128 interactive goal programming 130 lexicographic approach 132 method of constraints 131 methods with preferences articulated a posteriori 133 methods with preferences articulated a priori 133 methods with preferences articulated progressively 133 Pareto-optimal solutions 128, 133, 138 two-level optimisation method 125 utopia solution 131 value function 129, 130

14 25/7/03 10:02 Page 171

Index

N

171

object oriented approach 49, 84 ontology 56

stabilising moment of a car steering mechanism 150 structure of optimisation problem 37, 119 sub-task 8, 26, 36, 51, 74, 90, 95, 100, 149 sub-task evolution 108

P

T

paper notebooks 11, 86 parametric 24, 47, 101, 138 Pareto-optimal solutions 34, 128, 133, 138 personal knowledge 7, 56, 95 personal knowledge development 79, 85 piping system 24, 47, 61 Pokojski 139 procedural 22, 49, 52, 75, 84, 99, 105 procedural knowledge 40, 44, 84 product and process representation 2 product structure decomposition 116 project development 5, 76, 106

teams 1, 7, 11, 38, 52, 90, 98, 157 Tecuci 51 theoretical knowledge 13, 16, 30, 40 toothed wheels 19, 45, 86, 94, 104, 119 Turkiyyah 54 two-level optimisation method 125

node of the maze model 17, 71, 122

O

R Raiffa 135 relational database 146 rules 15, 21, 45, 49, 58, 77, 84, 87, 146

S Shimizu 139 short-term memory 44, 61 single activity knowledge 85

U uniﬁed framework 157 utopia solution 131

V value function 129, 130 VRML 150

W Weber 54 Werner 54

Y Yang 53